Arista SD-Branch Part 10: Day-Two Operations, Upgrades and Automation

14 October 2026 CloudVisionAGNISD-BranchArista CampusOperationsAutomation

Standing the branch up is the easy half. This post covers the day-two work: upgrading without a service hit, finding faults, checking compliance, and automating the repetitive parts. It draws on Arista’s published lab material and datasheets, and I have not run any of it.

Upgrades without a branch outage

Arista’s Smart System Upgrade is aimed at upgrading the wired network without downtime. Two properties of this stack support that. The 710P supports continuous PoE, so powered devices keep running during a switch reload, and access points are the main thing you do not want to drop. The second is CloudVision’s change control, which lets you stage and sequence the upgrade across devices instead of running it by hand. The mechanics of SSU are in Arista’s documentation. Before relying on it, test it on a non-critical branch, because the behaviour depends on topology and release.

Finding faults

CloudVision brings the pieces together in a few places.

  • Endpoint Overview shows authentication state and traffic flows for a single endpoint, which is the first stop for a “my laptop will not connect” ticket.
  • Observability and alerting dashboards are where the Test Drive operations material points for monitoring a deployed campus.
  • Wireless troubleshooting in CV-CUE includes packet capture and client testing tools.
  • AGNI Sessions shows what the policy engine decided.

A working order for a port or SSID complaint is the one from Part 8: check the platform session, then the switch or AP, then the endpoint.

Compliance

For a fleet of branches, version drift is the quiet risk. CloudVision’s compliance dashboard lists devices by software version and flags those with known advisories. I used the same approach for the VeloCloud batch in Edge HA Part 2, where it saved checking Edge software versions one site at a time.

Automation options

OptionFits
CloudVision studios and change controlDay-to-day config in the GUI with review
CloudVision APIsReading inventory and state, or driving provisioning from your own tooling
AGNI OpenAPI 3.0Creating access devices, clients and certificates from scripts
Arista AVD (Ansible)Describing the whole network as data and rendering EOS config
Community rolesNarrow jobs such as the RadSec profile role from Part 7

AVD is worth a note for this series. Its RADIUS settings can describe the AGNI server as data:

aaa_settings:
  radius:
    servers:
      - host: radsec.beta.agni.arista.io
        vrf: MGMT
        groups: [ AAA-AGNI-GROUP ]
        tls:
          enabled: true
          ssl_profile: AGNI

A public AVD issue reported that tls.enabled was not appending the tls keyword to the server line in the rendered CLI. I do not know whether that has been fixed in your AVD version, so render the config and read it before pushing.

The AGNI API and credentials

AGNI exposes an OpenAPI 3.0 API, so anything you can do in the UI you can script. The community RadSec role authenticates with a key ID, key value and organisation ID. Keep those in a secrets manager or the environment, never in a repository, and rotate them if they have been logged. The pattern is the same as I described in Ansible Deep Dive Part 6.

A day-two checklist

  • Keep an inventory of AP and switch certificates and when they expire. RadSec stops when a certificate does.
  • Test an upgrade on one branch first.
  • Review AGNI segments every quarter for rules that no longer match anything.
  • Export the configuration of CloudVision containers and configlets so a loss of the tenant is recoverable.
  • Alert on RadSec sessions dropping, since that fails every authentication at once.

Sources