Arista SD-Branch Part 4: CloudVision Studios, Port Profiles and Change Control
CloudVision does not want you to log in to a switch and type. It wants you to describe intent in Studios, review the result, and push it through change control. This post covers that model for a campus or branch, drawn from Arista’s Test Drive campus guide. I have not run any of it.
The Studios
| Studio | What it holds |
|---|---|
| Inventory and Topology | Registered devices and how they connect |
| Campus Fabric | The fabric itself: campus, pods, spines, access pods, in-band management. L2 only, or L3 with EVPN and VXLAN |
| Campus Services (non-VXLAN) | VLANs, their pod assignments, IP virtual subnets, DHCP helper addresses |
| Static Configuration | CLI-style configlets in a container hierarchy of campus, pod and access pod |
| Access Interface Configuration | Port profiles that reference interface profiles, used to apply VLANs to host ports |
For a single branch with a few 710Ps, the L2 fabric type is the natural fit. The EVPN and VXLAN options matter when a campus has a routed core, and they are out of scope here.
One caution on currency. The Test Drive guide I used says the campus Studios needed the “Campus Beta Features” and “Additional Dashboards” toggles enabled in CloudVision settings. That guide is for a 2025 release. Check whether your CloudVision version still gates them.
The workflow
Every change follows the same four steps.
- Create a workspace and add your studio inputs. Changes stay staged and nothing reaches a device.
- Review the workspace. It must pass input validation, configlet compilation and config validation, and you can read the generated configuration for each leaf and spine.
- Submit the workspace. That creates a change control.
- Approve and execute the change control. An “execute immediately” option pushes it straight away, or you can schedule it.
The point of the workspace is that you see the compiled configuration before any switch does. Compare that with editing a running config over SSH, where review is whatever you remember to do.
Port profiles
In Arista’s lab, interface profiles for DATA, VOICE and GUEST live in Static Configuration, and the Access Interface Configuration studio wraps them into port profiles. Quick Actions then assigns a profile to a port, which sets the right VLANs without anyone writing interface config.
A DATA profile compiles to something like this standard EOS interface configuration. The VLAN IDs are examples.
interface Ethernet5
description DATA
switchport mode access
switchport access vlan 10
spanning-tree portfast
spanning-tree bpduguard enableA VOICE profile adds the phone VLAN:
interface Ethernet6
description VOICE
switchport mode access
switchport access vlan 10
switchport phone vlan 20
spanning-tree portfastThe exact configlet CloudVision generates depends on the studio inputs and your release, so read the compiled output in the workspace review instead of assuming it matches the block above.
Why this matters for access control
In Part 8 the port profile gains 802.1X and MAC-based authentication. Because the profile is the single place where that is defined, turning on port authentication for a whole branch is one workspace and one change control, not a CLI session per switch. A port profile with authentication enabled is also easy to audit afterwards, since it is a named object and not a pattern in running configs.
Static Configuration as the escape hatch
Studios cover the common cases. Anything they do not model goes into a configlet in Static Configuration, assigned at the container level that fits. In Part 7 the RadSec RADIUS server settings go in a configlet this way. The Test Drive lab uses a per-switch configlet for the same job, which defines the SSL profile, the RADIUS server, a server group and the 802.1X authentication and accounting methods.