SD-Access is Cisco's intent-based campus fabric, and it is where the two protocols from earlier in this cluster stop being academic. LISP is its control plane, VXLAN is its data plane, and Catalyst Center is the automation and policy layer that operates the whole thing so you never touch the underlying CLI. If you understand LISP and VXLAN, you already understand most of how SD-Access works; the rest is the policy model and the operational shift.
This article explains the SD-Access architecture, its roles, and how the pieces fit. It is a concept article by necessity (SD-Access cannot be built in a lab without Catalyst Center), and it extends the Network Virtualization cluster guide.
The Problem SD-Access Addresses
A traditional campus is a pile of VLANs, subnets, access lists, and manual per-switch configuration. Segmentation is done with VLANs and ACLs that must be maintained by hand on every device. Moving a user or a device between floors often means re-IPing. Applying a security policy consistently across a large campus is genuinely hard, and proving it was applied is harder.
SD-Access changes the model in three ways:
The Two Planes You Already Know
Strip away the branding and SD-Access is LISP plus VXLAN:
The one genuinely new ingredient is the policy plane: Scalable Group Tags (SGTs) from Cisco TrustSec, carried inside the VXLAN header, that let the fabric enforce group-based policy independent of IP addressing. That is the piece that makes "policy by group, not subnet" work.
The Fabric Roles
SD-Access defines a handful of node roles. Map them onto the LISP roles you already know and they stop being jargon:
An endpoint connects to a Fabric Edge, which registers it with the Control Plane node. When another endpoint wants to reach it, its edge queries the Control Plane node for the mapping (LISP map-request), gets the destination edge's RLOC, and VXLAN-encapsulates the traffic to it. This is the exact behaviour captured in the LISP lab, operating at campus scale under Catalyst Center's control.
Two Levels of Segmentation
SD-Access segments the network at two levels, and understanding the difference is key:
Macro-segmentation is the coarse cut (separate virtual networks, no leakage). Micro-segmentation is the fine cut (group policy inside a virtual network). Together they replace the sprawling VLAN-and-ACL model with something expressed in terms of identity and intent, and enforced consistently by the fabric rather than device by device.
Why This Is a Concept Article
Being honest about the boundary: SD-Access cannot be labbed without Catalyst Center, which is not available in a standard CML environment and is not something you configure by CLI. The fabric roles are provisioned by Catalyst Center; you do not hand-configure a Fabric Edge the way you configure a switch. That is the entire operational premise.
What you can lab, and what this cluster does lab, are the underlying protocols: LISP with real map-cache captures and VXLAN with a real byte-level encapsulation. Understanding those is understanding the fabric's mechanics. The Catalyst Center layer on top is an operational and API story, covered from the automation angle in the Network Automation cluster. No fabricated show fabric output appears here, because that output only exists on a Catalyst Center-provisioned fabric.
Is It Worth It?
SD-Access is a large commitment: Catalyst Center licensing, ISE for identity, capable hardware (Catalyst 9000), and a real operational shift from CLI to controller. It pays off for large campuses with strong segmentation and mobility requirements, particularly where group-based policy and consistent enforcement matter (healthcare, finance, large enterprise). For a small or mid-size network with modest segmentation needs, the traditional model, or a straightforward VXLAN-EVPN fabric without the full SD-Access stack, is often the better fit. The migration and interoperability article covers how to bridge the two worlds when you do adopt it.
FAQ
What is the control plane of SD-Access?
LISP. The Control Plane node is a LISP map-server/map-resolver, and Fabric Edge nodes are LISP xTRs. Endpoint mobility is the LISP EID-stays-put, RLOC-changes behaviour.
What is the data plane?
VXLAN, carrying both the segment (VNI) and the group tag (SGT) across the fabric.
What is an SGT?
A Scalable Group Tag: a group identifier (from TrustSec) carried in the VXLAN header, used to enforce policy between groups of users independent of their IP addresses. This is micro-segmentation.
Can I build SD-Access in CML?
No. It requires Catalyst Center to provision the fabric. You can lab the underlying LISP and VXLAN protocols, which is what this cluster does with real captures.
Do I still need ISE?
For the full identity-and-policy model (dynamic SGT assignment, group-based access control), yes. ISE is the identity engine that maps users to groups. Without it you have the fabric but not the intent-based policy.
Key Takeaways
- SD-Access is LISP (control plane) + VXLAN (data plane) + Catalyst Center (automation/policy). Learn LISP and VXLAN and you understand the mechanics.
- Roles map onto LISP: Fabric Edge = xTR, Control Plane node = map-server/resolver, Border = fabric exit, Catalyst Center = controller (not in the data path).
- Two segmentation levels: macro (Virtual Networks = VRFs = complete isolation) and micro (SGTs = group policy inside a VN, independent of IP).
- The value is location-independent identity, group-based policy, and automated consistent operation, replacing the VLAN-and-ACL sprawl.
- It cannot be labbed without Catalyst Center, so this is a concept article. The underlying LISP and VXLAN are labbed with real captures elsewhere in this cluster.
- It is a large commitment (Catalyst Center, ISE, Catalyst 9000). Worth it for large campuses with strong segmentation/mobility needs; overkill for small networks.
Next: SD-Access and the traditional campus, or the Network Virtualization cluster guide.
