Skip to content
Log in Sign up My account

2.4 SD-Access Architecture

Blueprint 2.4: SD-Access architecture

  • Underlay and overlay
  • Control plane and data plane
  • Automation
  • Wireless
  • Security

ENCOR introduced the SD-Access roles and the LISP, VXLAN and TrustSec split. ENSLD expects you to use that knowledge to decide how the fabric should be built and what each choice costs. Read ENCOR SD-Access and LISP and VXLAN first. This page summarises what is needed and spends its words on architecture-level choices. Fabric sizing, border and multicast decisions follow on the next page, 2.5 SD-Access fabric design.

Architecture in one picture

graph TB
  CC["Catalyst Center<br/>automation and assurance"]
  ISE["ISE<br/>identity and policy"]
  CC <--> ISE
  subgraph "Fabric site"
    CP["Control plane node<br/>LISP map server"]
    B["Border node"]
    E1["Edge node"]
    E2["Edge node"]
    I["Intermediate node"]
    WLC["Fabric WLC"]
    AP["Fabric AP"]
    CP -.- E1
    CP -.- E2
    CP -.- B
    E1 --- I
    E2 --- I
    I --- B
    E1 --- AP
    WLC -.- E1
  end
  CC -.-> CP
  CC -.-> B
  CC -.-> E1
  B --- EXT["Fusion device,<br/>WAN, data centre"]

The underlay

The underlay is the routed network that provides loopback-to-loopback IP reachability between fabric nodes. It carries VXLAN-encapsulated overlay traffic as ordinary IP.

Design choice Options Guidance
How it is built LAN Automation, or manual / existing network LAN Automation configures routed links and IS-IS for new switches. Use manual underlay in brownfield campuses that already route well
Routing protocol IS-IS (LAN Automation), or any IGP such as OSPF Keep it simple and fast. The underlay should have no policy and few routes (loopbacks and links)
Topology Routed access, point-to-point links, ECMP No spanning tree between fabric nodes, no VLANs trunked between them
MTU Jumbo frames throughout VXLAN adds overhead. Set at least 1550 on the underlay, 9100 is common practice
Redundancy Dual uplinks from edges, redundant borders and control plane nodes Same principles as 2.1 and 2.3

The underlay should be built and proven before the overlay. A weak underlay shows up as every overlay problem.

Exam trap

The underlay does not know about virtual networks, SGTs or endpoints. It only moves IP between RLOCs (the loopbacks). If a question asks where the endpoint-to-location mapping lives, the answer is the control plane node (LISP), not the underlay routing table.

The overlay: control plane, data plane, policy

Plane Technology Role Design consequence
Control LISP Endpoint ID to location (RLOC) database on the control plane node Edges register and query. No flooding to learn hosts. Small, fast lookups. Newer releases use LISP publish/subscribe between nodes so borders and edges receive updates from the control plane node as they happen
Data VXLAN with Group Policy Option Carries the VN identifier and the SGT inside every packet The encapsulated frame carries Layer 2 or Layer 3 semantics over the routed underlay
Policy TrustSec (SGT, SGACL) Group-based policy based on identity, not IP Policy follows the user across the campus

Two forwarding styles exist for the overlay and they matter for design:

  • Layer 3 overlay (the default). Each edge routes between subnets and acts as the anycast default gateway. Traffic is routed, ARP is local, broadcast is not flooded across the fabric. This is the scalable choice.
  • Layer 2 overlay / Layer 2 flooding. Used for specific needs such as applications that depend on broadcast or silent hosts. It uses underlay multicast to flood in the VLAN. Enable it only where required.

Anycast gateway

Every edge in a VN uses the same gateway IP and MAC for a subnet. A host that moves between edges needs no change of gateway, and wireless roaming inside the fabric keeps its IP address. That is why no FHRP is used in the fabric.

Fabric roles recap and placement

Role Architectural note
Edge node Authenticates endpoints, assigns VN and SGT, registers with the control plane. Usually the access switch.
Control plane node LISP map server and resolver. Run at least two for redundancy. Can be co-located with a border or dedicated
Border node The only fabric exit. Internal, external or anywhere type. Redundant pair is the norm
Intermediate node Underlay routing only, a core or distribution switch that does nothing fabric-specific
Extended node Small switch connected to an edge, extends the fabric to places edges cannot go. Gets VLAN and policy from the edge
Fabric WLC and APs Integrate wireless into the same segmentation model

A fabric in a box collapses border, control plane and edge onto one switch (or stack) for a small site. It is simple and cheap and gives up redundancy and scale.

Automation

Catalyst Center is the automation brain of SD-Access.

Capability What it does for the design
Design and policy Sites, IP pools, virtual networks, SGTs and contracts are modelled once
LAN Automation Discovers and configures new switches into the underlay
Provisioning Pushes fabric configuration to nodes, so edges are configured consistently
Templates Add device-specific configuration the model does not cover
Assurance Health scores, path trace and issue detection for wired and wireless
ISE integration Shares group and policy information (typically over pxGrid)

The design consequence is operational. The fabric is managed by intent, so configuring nodes by hand at the CLI causes drift and can be overwritten at the next provisioning. Catalyst Center availability affects changes and visibility, not forwarding. If Catalyst Center is down, the fabric keeps forwarding on the existing control plane, but new provisioning and some assurance stop.

Wireless in the fabric

There are two ways to integrate wireless and they are an architecture decision.

Fabric-enabled wireless Over-the-top (OTT) wireless
Data path The AP uses VXLAN to the edge node. Traffic enters the fabric at the edge The AP builds a CAPWAP tunnel to the WLC, which sits outside or beside the fabric. The fabric just carries IP
Control WLC controls the AP and registers wireless endpoints with the fabric control plane Standard controller operation
Policy Same VN and SGT model as wired, applied at the edge Policy is applied by the controller or other point, not by the fabric
Distributed forwarding Yes, traffic goes straight to the edge No, traffic is hairpinned through the WLC
Best for New deployments that want one policy model and distributed forwarding Migration, wireless in non-fabric parts, or existing WLCs that cannot join the fabric

APs connect to edge nodes in a dedicated VN (commonly the infrastructure VN) that reaches the WLC. In both models the fabric WLC is a Catalyst 9800 family controller.

Security architecture

SD-Access has two levels of segmentation and a policy model built on identity.

Level Mechanism Granularity Enforcement
Macro-segmentation Virtual Networks (VRFs) Whole groups of endpoints, complete isolation Separate routing tables. Crossing VNs needs the fusion device or border
Micro-segmentation SGTs and SGACLs Per group inside a VN (and across VNs with policy) Enforced at the edge or border, based on SGT

How a host gets its identity:

  1. The endpoint authenticates with 802.1X, MAB or WebAuth through ISE, or a static assignment is used.
  2. ISE returns a VN or VLAN and an SGT.
  3. The edge node maps the endpoint to the VN and tags traffic with the SGT.
  4. The destination edge (or border) enforces the SGACL downloaded from ISE.

Design points:

  • Use ISE for dynamic assignment where users move. Static port assignment is fine for fixed devices such as printers.
  • Plan the SGT scheme early. Too many tags becomes unmanageable. Group by business role, not by every application.
  • Carry the SGT where policy must continue: inside the fabric it travels in VXLAN. Outside it needs inline tagging on supported links, or SXP between devices that cannot tag.
  • Start in monitor mode (open authentication) during rollout, then move toward closed mode as policy matures. Moving to enforcement too early blocks endpoints that were never profiled.

Exam trap

VNs and SGTs are not interchangeable. A VN isolates at Layer 3 with a separate routing table, and a request that two groups must never be able to route to each other points to separate VNs. A request that groups share a subnet or VN but get different permissions points to SGTs.

Design exercise

Scenario. A hospital group wants to adopt SD-Access in a new tower and later extend it to older buildings. Requirements: clinical devices, guest Wi-Fi and building systems must be isolated; medical devices must be permitted to reach only their servers; staff move between floors and expect the same IP address and gateway on Wi-Fi and wired; the old buildings have a working OSPF core that must remain until a later phase; Catalyst Center must not be required for the network to keep forwarding.

Model answer

Segmentation: three virtual networks (clinical, guest, building systems) for macro-segmentation. Inside the clinical VN use SGTs such as nurse, physician, medical device and clinical server, with SGACLs that let medical devices reach only their servers. ISE assigns SGTs using 802.1X, MAB and profiling.

Underlay and roles: build the tower underlay with LAN Automation (IS-IS), routed access, jumbo MTU. Two control plane nodes and two borders. Edges in each closet, intermediate nodes for the building distribution.

Wireless: fabric-enabled wireless with a Catalyst 9800 fabric WLC, so Wi-Fi uses the same VN and SGT model, and roaming keeps the address thanks to the anycast gateway.

Old buildings: an external or anywhere border hands off each VN to the existing OSPF core, with a fusion device doing route leaking for shared services. Migrate old buildings later.

Operations: Catalyst Center manages provisioning, but forwarding continues if it is unreachable.

Rejected alternatives:

  • Over-the-top wireless. It would work, but guest and clinical Wi-Fi would not share the wired policy model, which contradicts the single-policy requirement.
  • VLAN-based segmentation with FHRP. It cannot give the roaming and anycast behaviour and brings back STP.
  • One VN with only SGTs. The requirement for isolation of guest and building systems is a routing-level isolation request, which VNs satisfy and SGTs alone do not.
  • Fabric in a box. It has no redundancy and does not scale to a tower.

Quick check

Where is the mapping between an endpoint and the switch it sits behind stored in SD-Access?

In the LISP map-server database on the control plane node. Edges register endpoints there and query it to find destinations.

What is the main design reason SD-Access needs no FHRP?

Every edge node acts as the anycast default gateway with the same IP and MAC for a subnet, so there is no single gateway to fail and a moving host keeps its gateway.

Catalyst Center becomes unreachable. What happens to the existing fabric?

Forwarding and the LISP control plane keep working. New provisioning, changes and some assurance functions are unavailable until it returns.

References

  • Cisco Software-Defined Access Solution Design Guide (CVD): search "SD-Access Solution Design Guide" on cisco.com
  • Cisco Catalyst Center user guide: search "Cisco Catalyst Center user guide" on cisco.com
  • Cisco ISE and TrustSec documentation: search "TrustSec" on cisco.com
  • RFC 9300 and RFC 9301 (LISP), RFC 7348 (VXLAN) at rfc-editor.org
  • Cisco Live On-Demand Library: search "SD-Access" and "SD-Access design"