Arista SD-Branch Part 3: Onboarding Switches to CloudVision with ZTP and TerminAttr

14 October 2026 CloudVisionAGNISD-BranchArista CampusZTPTerminAttr

A switch that CloudVision cannot see is just a switch. Onboarding is the step that puts every later part of this series on a working footing, so it is worth getting the order right. This post follows Arista’s CloudVision as a Service onboarding material. Nothing here was run on hardware.

Two ways in

MethodWhen it fits
Zero touch provisioningNew switches shipped to a branch with nobody on site who knows EOS
Token onboardingSwitches that are already running and need to join CloudVision

The 710P datasheet lists ZTP support, and CloudVision CUE provides ZTP for edge management. In both methods the end state is the same: the switch runs TerminAttr, the CloudVision agent that streams state to the platform and receives configuration from it.

CloudVision as a Service setup

Before any device joins, the CloudVision instance needs a way to authenticate people. The CVaaS guide describes the sequence:

  1. Turn on OAuth Providers under Features in Settings.
  2. Add a provider under Access Control. Google and Microsoft are shared providers and need no extra details. Others need account-specific credentials.
  3. Add the admin user and confirm the login works before the invitation link expires.
  4. Under Devices, Inventory, choose Add Devices, then Onboard Devices, and create a token.

The dialog that creates the token also generates the commands to paste on the switch. Use those rather than writing the TerminAttr line by hand, because the cluster address and authentication arguments are specific to your instance.

What TerminAttr needs to know

I am deliberately not giving a full TerminAttr command line, because the exact flags come from your token dialog. The arguments you will see cover the CloudVision address, the authentication method and token file, and the VRF to use for the connection. The documented points that bite are these:

  • One token covers many switches. CloudVision identifies each device by serial number, so you do not need a token per device.
  • RADIUS-authenticated EOS needs --disableaaa. If the switch uses RADIUS for its own login, the guide says to add that argument to TerminAttr.
  • TACACS+ needs the account to exist first. The user that CloudVision provisions with must already exist on the TACACS+ server.
  • OAuth needs a matching local user. Before provisioning, create an account on the device that matches the username in the OAuth email address.

That last pair is where first deployments stall. The switch appears in inventory but provisioning fails because an account the platform expects is not there.

Confirming it worked

On the switch, the running configuration shows what the onboarding commands created:

show running-config | section TerminAttr

In CloudVision, the device should appear under the Devices tab. From the device’s wrench icon, open the Device Overview tab and choose Provision Device.

Inventory and Topology

Provisioning is not the end. The Inventory and Topology studio is where onboarded devices are registered so the other studios can manage them. In Arista’s Test Drive campus guide, nothing is configured until devices exist in that studio. It is also where you describe how the devices connect, which feeds the topology view.

Credentials and RADIUS

If you are heading toward AGNI, think about this now. The --disableaaa note exists because moving EOS login to RADIUS changes how CloudVision authenticates to the switch. In Part 7 the switch starts talking RadSec to AGNI for user access. Keep management-plane authentication and port-based network access as separate problems, and decide on purpose which one uses AGNI.

Sources