An SD-Access fabric is not a pile of switches. It is a set of roles, and every switch in the fabric plays one or more of them. Understand the roles and the fabric makes sense; miss them and it looks like an impenetrable tangle of LISP, VXLAN, and acronyms. This is the article that makes the rest of SD-Access legible.
This is a concept-and-architecture piece. A full fabric needs Cisco Catalyst Center, which a home lab does not have, so we describe the roles and the protocols they run, and are clear about which pieces are real, standalone-verifiable technology (LISP, VXLAN) and which need the controller. For the wider context, see the network virtualization pillar.
The four roles
How an endpoint's traffic actually flows
The roles come alive when you trace a packet. Say host A (on edge node E1) wants to talk to host B (on edge node E2):
- Registration. When host A first appears, E1 detects it and registers it with the control plane node: "endpoint A is behind me (E1's loopback)." E2 does the same for host B. The control plane now holds both mappings.
- Lookup. Host A sends a packet to host B. E1 does not know where B is, so it queries the control plane node: "where is B?" The control plane answers: "B is behind E2's loopback."
- Encapsulation. E1 encapsulates host A's packet in VXLAN, addressed to E2's loopback, and sends it across the underlay. The VXLAN header carries the virtual network ID (which VN B is in) and the SGT (host A's security group).
- Decapsulation. E2 receives the VXLAN packet, strips the header, and delivers the original frame to host B - after checking the SGT against policy.
That is the whole fabric in one paragraph. Edge nodes register and encapsulate; the control plane node answers "where is it"; the border node handles anything leaving the fabric. Everything else is detail.
The protocols behind each role
LISP mapping, made concrete
LISP's core idea is separating identity from location. An endpoint's IP address (its EID, endpoint identifier) says who it is. The edge node's loopback (its RLOC, routing locator) says where it is. The control plane's whole job is maintaining the EID-to-RLOC mapping.
On a real IOS XE LISP xTR - the same technology an SD-Access edge node runs - you can see this mapping directly:
xTR# show ip lisp map-cache
LISP IPv4 Mapping Cache, 2 entries
10.1.1.0/24, uptime: 00:05:12, expires: 23:54:47, via map-reply, complete
Locator Uptime State Pri/Wgt
2.2.2.2 00:05:12 up 10/10
xTR# show ip lisp database
LISP ETR IPv4 Mapping Database, LSBs: 0x1, 2 entries
10.1.2.0/24, locator-set RLOC-SET
Locator Pri/Wgt Source State
1.1.1.1 10/10 cfg-addr site-self, reachableThe map-cache is "where I have learned remote endpoints live" (like an ARP cache for locations). The database is "the endpoints I am responsible for and will register." An SD-Access edge node maintains exactly these structures, populated by Catalyst Center's provisioning rather than by hand - but the underlying LISP mechanism is identical, and it is real, and PingLabz has captured it on IOS XE in the standalone LISP labs (see the network virtualization cluster).
Design: where to put each role
- Edge nodes are your access switches. As many as you have access closets. No decision here - endpoints connect where users are.
- Control plane nodes should be redundant (at least two) and sized for the endpoint count, since every registration and lookup goes through them. Often co-located with the border on larger switches, or dedicated on very large fabrics.
- Border nodes come in flavours by what they connect to - which is the whole subject of the next article. Also deploy at least two for redundancy.
- Fabric in a Box for a small site (a branch, a remote office) where three separate devices is overkill. One switch, all roles, simpler to operate.
The redundancy point matters: the control plane node is the fabric's directory, and a fabric with one control plane node has a single point of failure for every endpoint lookup. Always deploy two.
What needs Catalyst Center, and what does not
Being honest about the boundary:
- Needs the controller: assigning roles to devices, provisioning the LISP/VXLAN configuration, managing the fabric as a system, host onboarding policy. There is no CLI workflow for "make this switch a border node" - Catalyst Center does it.
- Real and standalone: LISP (map-cache, database, xTR behaviour), VXLAN encapsulation, TrustSec SGT tagging. Every protocol the fabric rides on can be configured and verified by hand on IOS XE, and PingLabz has done exactly that in the standalone component labs.
We will not show you a Catalyst Center screenshot we did not take, or fabric CLI we cannot produce. Where the technology is real and standalone, we show it. Where it needs the controller, we describe the architecture and say so plainly. That honesty is the differentiator - an expert reader knows immediately whether a "lab" is real.
Key takeaways
- An SD-Access fabric is a set of roles: edge (endpoints connect, encapsulate), control plane (the LISP directory), border (the exit), and fabric in a box (all three on one switch, for small sites).
- Traffic flow: the edge registers endpoints with the control plane, queries it to find remote endpoints, then VXLAN-encapsulates to the destination edge's loopback. The border handles anything leaving the fabric.
- The control plane is LISP; the data plane is VXLAN (carrying the VNI and SGT); the policy plane is TrustSec.
- LISP separates identity (the endpoint's EID) from location (the edge's RLOC). The map-cache and database are real, standalone-verifiable structures on IOS XE.
- Deploy control plane and border nodes redundantly. The control plane node is the fabric's directory - never run just one.
- Role assignment and fabric provisioning need Catalyst Center; the underlying LISP/VXLAN/TrustSec protocols are real and labbable standalone. We are clear about which is which.
Next: SD-Access host onboarding - from port to policy. The full cluster index lives on the network virtualization pillar.
