Cisco SD-Access Fabric: Roles, Underlay and LISP-VXLAN

Software-Defined Access separates a campus network into four planes, and understanding which plane does what is the difference between operating a fabric and fighting one. The management plane is Catalyst Center, the control plane is LISP, the data plane is VXLAN, and the policy plane is TrustSec. This guide walks those planes, the device roles that implement them, the underlay prerequisites that are easy to underestimate, and the forwarding behaviour that explains most "the packet goes somewhere strange" tickets.

The four planes

• Management plane — Catalyst Center. Discovers devices, provisions fabric roles, automates underlay deployment and hosts the fabric's intent.
• Control plane — LISP. Endpoint identifiers (who) are separated from locators (where). Edge nodes register endpoint identities with the control plane node; other nodes query to find the current location.
• Data plane — VXLAN. Traffic between fabric nodes is encapsulated in VXLAN, with the VNI identifying the overlay network and additional header attributes carrying policy information.
• Policy plane — TrustSec. Group-Based Access Control replaces address-based rules with logical groupings; the Security Group Tag travels inside the VXLAN header so policy can be enforced anywhere in the fabric, not just at the first hop.

Device roles

Control plane node

The fabric's map server and map resolver. It holds the endpoint-to-location database and answers queries from edge nodes trying to reach an endpoint elsewhere in the fabric. Deploy at least two, and keep them where the underlay can reach them with predictable latency.

Fabric edge node

Where endpoints attach. The edge node is an anycast Layer 3 gateway — an SVI with a hard-coded anycast MAC identical across all edge nodes in the fabric site — and it both encapsulates traffic from local endpoints and decapsulates traffic destined for them. Because the gateway MAC and IP are identical everywhere, an endpoint that moves between floors keeps its address and its default gateway.

Fabric border node

The gate between the fabric and everything outside it. Three flavours:

• Internal border — connects to known, registered destinations such as the data centre, shared services or another fabric site. It advertises fabric endpoints outward and imports external routes inward.
• External border — behaves like a default gateway for destinations unknown to the control plane database, typically toward the internet.
• Internal + external border — a single device providing both, which is common in smaller sites.

Intermediate nodes

Ordinary Layer 3 switches that interconnect fabric-role devices. They route and transport IP, they do not encapsulate, and they do not need fabric awareness — but they do need to meet the underlay's routing and MTU requirements.

Fabric in a box

One device performing control plane, border and edge roles. Useful for small sites and labs; check the platform support matrix before designing around it.

Forwarding behaviour worth internalising

When an edge node needs to reach an endpoint it has not seen, it queries the control plane node and caches the answer in the LISP map cache, which is merged with the CEF table and installed in hardware. If the control plane cannot resolve the destination at all, traffic is sent to the default fabric border node. That single sentence explains a whole class of incidents: traffic that should have stayed inside the fabric egresses toward the internet because registration failed or was never learned.

Registration failures usually trace to one of three things — the endpoint was not onboarded through the correct edge node, DHCP or ARP snooping is not configured on the edge so the binding was never learned, or the endpoint's VRF association is wrong.

Underlay prerequisites people underestimate

1. MTU. VXLAN adds 50 bytes of encapsulation to frames sourced by endpoints. Every switch in the path — edge, border, control plane and intermediate — should support jumbo frames; an MTU of 9100 is the usual recommendation. Silent fragmentation on the underlay produces symptoms that look like application bugs.
2. Routing consistency. The underlay must provide reachability for every fabric node's loopback, which is the VXLAN tunnel source and the LISP locator. Contradictory IGPs or summarisation that black-holes loopbacks break encapsulation while pings to physical interfaces still work.
3. Time. Synchronised clocks everywhere; certificates and telemetry depend on them.
4. Role placement. Control plane nodes should not be on the same failure domain as the only border node.

Deployment path

Underlay first, using LAN automation so devices are discovered and configured consistently rather than hand-built. That automation relies on the Plug and Play workflow described in Cisco Catalyst Center Plug and Play onboarding. Then fabric role assignment, then overlay virtual networks, then policy.

The overlay itself is provisioned as VRF instances that separate routing tables, and Layer 2 and Layer 3 connectivity across the fabric is extended through LISP and VXLAN services. If you are comparing fabric designs, the data-centre equivalent in BGP in EVPN data centre fabric design uses BGP EVPN as its control plane instead of LISP, with a different set of trade-offs around multisite and interoperability.

原文链接：https://www.cisco.com/c/en/us/td/docs/solutions/CVD/Campus/cisco-sda-design-guide.html