Arista SD-Branch Part 1: The Product Map for CloudVision, AGNI and the 710P
I spent two days in an Arista CloudVision and AGNI workshop, and it changed how I think about the branch. This series turns that into a written walkthrough of managing 710P-16P switches and Arista access points as one system, from first boot to wired and wireless access policy.
How this series is sourced
There is no lab behind these posts. Every configuration block comes from Arista’s public documentation, datasheets, product pages and Test Drive guides, and I have not run any of it. Where I could not find a command in a public source I say so instead of guessing at the syntax. Some Arista knowledge base articles sit behind a login, and those are the places where you should check the EOS command reference for your release before pasting anything.
That is a different standard from my packet-capture and lab series, so treat these as a reading guide with config examples, not as verified output.
What “SD-Branch” means here
Arista’s SD-WAN product is VeloCloud, which I have covered in the Arista / VMware SD-WAN Deep Dive and the Edge HA and CVE posts. This series is about the other half of a branch: the switches, the access points, and the network access control that sits across both. Arista positions this as its cognitive campus stack. I use “SD-Branch” as the label because that is how most people shopping for a Fortinet or Cisco equivalent will search for it.
The pieces
| Piece | What it is | Role in the branch |
|---|---|---|
| EOS | Arista’s single-binary network OS | Runs on the 710P switches; same OS family as the data centre line |
| 710P-16P | 16-port PoE access switch with two SFP+ uplinks | Wired access and AP power |
| Wi-Fi 7 APs | C-460, C-430, C-400 indoor; O-435, O-405 outdoor | Wireless access |
| CloudVision | Management platform, available as CVaaS or on-prem | Inventory, configuration studios, change control, telemetry |
| CV-CUE | CloudVision Cognitive Unified Edge | Wireless and edge management, SaaS delivered |
| AGNI | Cloud network access control | 802.1X, MAC bypass, UPSK, guest access, built-in PKI |
How they connect
Three relationships matter, and the rest of the series follows them.
- Switches stream to CloudVision. Each EOS device runs TerminAttr, which streams state to CloudVision and lets CloudVision push configuration through studios and change control.
- APs are managed through CV-CUE. SSIDs, roles and RF settings live there, and the APs report into it.
- Switches and APs both authenticate users against AGNI. They connect to it over RadSec, which is RADIUS carried inside TLS on port 2083, using certificates on both ends.
That third link is the one that makes this more than a pile of products. AGNI holds the policy, and the switch or AP only enforces it.
What AGNI adds
From the datasheet, AGNI covers 802.1X onboarding with a built-in PKI that supports SCEP and EST, MAC Bypass Authentication, unique pre-shared keys, guest access with portals and SMS, and device profiling from DHCP fingerprints, user agents and LLDP. It also works with external PKI and MDM tools such as Jamf and Intune, and federates with identity providers over OAuth 2.0 and OIDC. It is sold as a subscription priced on the average number of concurrently active devices over a seven-day period, in tiers from 100 to 10,000 devices.
In my Five Minutes and an Empty Port vendor comparison I called Arista’s NAC story the least mature of the four. AGNI is the product that answers that, and Part 11 revisits the comparison.
The series
The next parts cover the 710P hardware, device onboarding, CloudVision studios and change control, the wireless side, AGNI’s object model, the RadSec link, wired and wireless access policy, day-two operations, and a closing comparison against Fortinet, Cisco and Juniper.