Cisco SDA Deep Dive: How LISP, VXLAN, and TrustSec Work Together in the Fabric in 2026

Cisco Software-Defined Access (SDA) is a three-plane fabric architecture that replaces traditional campus designs — spanning tree, HSRP, manual VLAN trunking — with a fully automated, identity-aware overlay network. LISP handles the control plane, VXLAN handles the data plane, and TrustSec handles the policy plane, all orchestrated through Catalyst Center.

Key Takeaway: Understanding how LISP, VXLAN, and TrustSec interact at the packet level is what separates engineers who can troubleshoot SDA fabrics from those who just click buttons in Catalyst Center — and it’s exactly what the CCIE Enterprise Infrastructure lab tests.

What Problem Does SDA Solve That Traditional Campus Can’t?

Traditional campus networks built on spanning tree and HSRP have fundamental scaling and operational problems that no amount of optimization can fix.

In a traditional three-tier campus design (access → distribution → core), you’re managing:

• Spanning tree domains across every VLAN — blocking redundant paths, creating asymmetric forwarding, and failing unpredictably during topology changes
• HSRP/VRRP at every distribution pair — active/standby wastes 50% of your gateway capacity
• Manual VLAN trunking from access to distribution — extending Layer 2 domains across the campus creates broadcast storms and limits mobility
• Static ACLs for segmentation — thousands of lines, tied to IP addresses that change whenever endpoints move

According to Cisco’s Campus LAN Design Guide, SDA eliminates all of these by moving to a Layer 3 routed access model with an overlay fabric. The default gateway lives at the fabric edge (access switch), not the distribution layer. Every link is routed. Spanning tree is irrelevant because there are no Layer 2 loops in the underlay.

Here’s the comparison:

The operational difference is massive. As one Reddit user in r/Cisco put it: “The real value isn’t the protocols — it’s that a user can plug into any port on any floor and get the same policy, the same gateway, the same segmentation, without anyone touching the switch.”

How Does the LISP Control Plane Work in SDA?

LISP (Locator/ID Separation Protocol) is the overlay control plane that tracks where every endpoint is in the fabric. It separates the endpoint’s identity (its IP or MAC address) from its location (which fabric node it’s behind).

The EID-to-RLOC Model

In LISP terms:

• EID (Endpoint Identifier) — the endpoint’s IP address or MAC address
• RLOC (Routing Locator) — the loopback IP of the fabric node (edge switch) where the endpoint is connected

The Control Plane Node (CPN) runs the LISP Map-Server/Map-Resolver (MS/MR) role. It’s the central database that knows which EID is behind which RLOC. Think of it like DNS for your campus — instead of mapping hostnames to IPs, it maps endpoint addresses to switch locations.

LISP Registration Flow

When an endpoint connects to a fabric edge node:

1. Endpoint authenticates via 802.1X or MAB through ISE
2. Fabric edge sends LISP Map-Register to the control plane node, saying “EID 10.10.10.50 (SGT=5) is behind RLOC 172.16.1.10”
3. Control plane node stores the mapping and sends a Map-Notify acknowledgment
4. When another fabric node needs to reach that endpoint, it sends a Map-Request to the CPN
5. CPN responds with a Map-Reply containing the RLOC

! Verify LISP registrations on the control plane node
show lisp site
show lisp instance-id * ipv4 server
show lisp instance-id * ethernet server

! Verify LISP registration on the fabric edge
show lisp instance-id * ipv4 database
show lisp instance-id * ethernet database

The critical detail: LISP is off-path. The control plane node is NOT in the data forwarding path. After the initial map lookup, the fabric edge caches the RLOC and forwards directly via VXLAN. This is why LISP scales well — the CPN doesn’t become a traffic bottleneck.

Why IS-IS for the Underlay?

The SDA underlay — the physical routed network connecting all fabric nodes — runs IS-IS, not OSPF. According to Cisco’s SDA Solution Design Guide, IS-IS was chosen because:

• It runs directly over Layer 2 (not IP), avoiding recursive routing issues
• Better native support for multi-topology routing
• Simpler ECMP behavior for load balancing across parallel fabric links
• LAN Automation in Catalyst Center auto-provisions IS-IS adjacencies

You don’t manually configure IS-IS on each switch — Catalyst Center’s LAN Automation discovers new switches via CDP/LLDP and pushes IS-IS underlay config automatically.

How Does the VXLAN Data Plane Encapsulate Traffic?

VXLAN (Virtual Extensible LAN) provides the data plane encapsulation that carries endpoint traffic across the routed IS-IS underlay. In SDA, VXLAN has a specific implementation called VXLAN-GPO (Group Policy Option) that carries the SGT tag inside the VXLAN header.

Packet Walk: Wired Client to Server

Let’s trace a packet from a wired client on Floor 1 to a server in the data center:

1. Client (10.10.10.50, SGT=5) sends packet to Server (10.20.20.100)
2. Fabric Edge (Floor 1) receives the frame
3. Edge performs LISP Map-Request → CPN responds with RLOC of Border Node
4. Edge encapsulates in VXLAN:
   Outer IP: Src=172.16.1.10 (Edge RLOC) → Dst=172.16.1.1 (Border RLOC)
   VXLAN Header: VNI=8188 (L3 VN), SGT=5 (in GPO extension)
   Inner IP: Src=10.10.10.50 → Dst=10.20.20.100
5. Packet routes across IS-IS underlay to Border Node
6. Border Node decapsulates VXLAN, checks SGT against SGACL policy
7. Border forwards to external L3 network (data center)

The VNI (VXLAN Network Identifier) maps to a Virtual Network (VN), which maps to a VRF. SDA uses two VNI ranges:

• L2 VNI (per VLAN segment within a VN) — carries intra-subnet traffic
• L3 VNI (per VN/VRF) — carries inter-subnet traffic across the fabric

! Verify VXLAN tunnels on fabric edge
show vxlan tunnel
show vxlan vni

! Verify NVE interface
show nve peers
show nve vni

Anycast Gateway: The HSRP Killer

One of SDA’s most elegant features is the anycast gateway. Every fabric edge node advertises the same gateway IP and MAC address for each subnet. There’s no active/standby — every edge is the gateway simultaneously.

This means:

• No HSRP/VRRP/GLBP — 100% of uplinks carry traffic (no standby waste)
• Local switching — the nearest edge handles routing, no hair-pinning to a distribution pair
• Seamless mobility — endpoint moves between edge nodes and hits the same gateway instantly

! Anycast gateway on every fabric edge (auto-provisioned by Catalyst Center)
interface Vlan100
 ip address 10.10.10.1 255.255.255.0
 mac-address 0000.0c9f.f001    ← same on every edge node
 ip helper-address 10.1.1.50   ← DHCP relay
 lisp mobility dynamic

How Does the TrustSec Policy Plane Enforce Segmentation?

TrustSec is the policy plane that makes SDA a zero trust architecture. We covered TrustSec in depth in our Cisco ISE TrustSec SGT guide, but here’s how it integrates specifically with the SDA fabric.

SGT in VXLAN-GPO

In a standalone TrustSec deployment, SGTs are carried via CMD headers (inline tagging) or SXP. In SDA, the SGT rides inside the VXLAN-GPO (Group Policy Option) header extension. This means:

• No SXP needed — the SGT propagates automatically with every VXLAN-encapsulated frame
• No inline tagging hardware dependency — any switch that supports VXLAN can carry SGTs
• Consistent enforcement — the SGT is available at both the source and destination edge

Macro vs. Micro Segmentation

SDA provides two segmentation layers:

Macro-segmentation (Virtual Networks/VRFs):

• Separate VNs for corporate, IoT, guest traffic
• Full VRF isolation — traffic cannot cross VN boundaries without a fusion router or border extranet policy
• Equivalent to running separate physical networks

Micro-segmentation (SGTs within a VN):

• Within the corporate VN, further restrict traffic between user groups
• Finance users (SGT 20) can reach finance servers but not HR systems
• Contractors (SGT 10) can reach internet but not internal resources

! Verify SGT assignment after 802.1X auth
show cts role-based sgt-map all
show authentication sessions interface Gi1/0/5 details

! Verify SGACL enforcement
show cts role-based permissions
show cts role-based counters

Shared Services Across VNs

A common challenge: how do IoT devices in a separate VN reach shared services like DNS, DHCP, and NTP? SDA handles this via:

1. Fusion router — routes between VNs with firewall inspection (traditional approach)
2. Extranet policy on border node — selective route leaking between VNs configured in Catalyst Center
3. Shared services VN — dedicated VN that all other VNs can reach via controlled policy

The extranet approach is preferred in 2026 because Catalyst Center automates the configuration and maintains SGT enforcement across the VN boundary.

What Are the Common SDA Deployment Gotchas?

Underlay Design Mistakes

The most common deployment failure is treating the underlay as an afterthought. The IS-IS underlay must be designed with:

• Point-to-point links between fabric nodes (no shared segments)
• Equal-cost paths for ECMP load balancing
• MTU of at least 9100 bytes — VXLAN adds 50-54 bytes of overhead to every frame
• Loopback interfaces for RLOC addressing — one per fabric node, advertised in IS-IS

If your underlay MTU is 1500, VXLAN encapsulated frames will be fragmented or dropped. This is the #1 troubleshooting issue in new SDA deployments.

VN-to-VRF Mapping Complexity

Each Virtual Network maps to a VRF on every fabric edge. With 5 VNs across 200 edge switches, you have 1,000 VRF instances. Catalyst Center handles provisioning, but the state management on each switch is real. Plan for:

• Memory and TCAM capacity on access switches (Catalyst 9300 vs 9500 limits)
• Route table size per VRF
• DHCP relay per VRF per subnet

Wireless Integration Nuances

In SDA, fabric-mode APs don’t tunnel data to the WLC. Instead, according to Cisco Live BRKEWN-3515 (2026), the AP switches client traffic directly to the local fabric edge via VXLAN. The WLC handles:

• CAPWAP control plane only
• Client authentication coordination with ISE
• LISP Map-Register on behalf of wireless clients to the CPN

This means wireless clients get the same SGT enforcement and anycast gateway experience as wired clients — true unified policy.

How Is SDA Tested on the CCIE Enterprise Infrastructure Lab?

The CCIE Enterprise Infrastructure v1.1 blueprint lists SD-Access as a major topic. Based on the published objectives and Cisco Live sessions from 2025-2026, expect:

• LISP verification — interpreting show lisp site output, understanding Map-Register/Notify/Request/Reply flows
• VXLAN troubleshooting — verifying NVE peers, VNI mappings, checking for MTU issues
• TrustSec matrix — configuring SGT assignments and SGACL enforcement, verifying with counters
• Catalyst Center tasks — provisioning fabric sites, adding devices to fabric roles, creating VNs and host pools
• Integration scenarios — SDA fabric connecting to external networks via border nodes, route leaking between VNs

The lab likely won’t ask you to build SDA from scratch via CLI — Catalyst Center handles provisioning. But you absolutely need to understand the underlying protocols to troubleshoot when something breaks.

If you’re building a lab environment, our SD-WAN lab guide for EVE-NG covers the virtualization approach — similar principles apply for SDA with Catalyst 9000v images.

Frequently Asked Questions

What are the three planes of Cisco SD-Access?

LISP provides the overlay control plane (EID-to-RLOC endpoint tracking), VXLAN provides the data plane (Layer 2/3 encapsulation across the routed underlay), and Cisco TrustSec provides the policy plane (SGT-based micro-segmentation). Catalyst Center manages all three as the management plane.

Why does Cisco SDA use IS-IS instead of OSPF for the underlay?

IS-IS is protocol-agnostic (runs directly over Layer 2, not IP), which avoids recursive routing issues when the underlay carries LISP traffic. It also provides better multi-topology support and simpler ECMP behavior for fabric deployments.

Can you run TrustSec without full SDA?

Yes. TrustSec SGTs can be deployed standalone with ISE on Catalyst switches using manual 802.1X and SGACL configuration. SDA automates the provisioning through Catalyst Center, but the underlying TrustSec technology works independently.

How does SDA handle wireless clients differently than traditional WLC?

In SDA, fabric-mode APs tunnel client traffic directly to the local fabric edge node (not the WLC). The WLC only handles control plane functions — CAPWAP control, client authentication, and LISP registration with the control plane node. This eliminates the WLC as a traffic bottleneck.

What Catalyst switches support SDA fabric roles?

Catalyst 9300, 9400, 9500, and 9600 series support fabric edge and border node roles. The control plane node role typically runs on Catalyst 9500 or 9600. Older Catalyst 3850 and 4500 can participate as extended nodes but not full fabric roles.

SDA is the future of enterprise campus networking — and understanding its three-plane architecture at the protocol level is what makes CCIE-caliber engineers indispensable. Whether you’re deploying SDA in production or preparing for the CCIE EI lab, this deep architectural knowledge is your competitive advantage.

Ready to fast-track your CCIE journey? Contact us on Telegram @phil66xx for a free assessment.