Skip to content
Log in Sign up My account

2.5 SD-Access Fabric Design for Wired and Wireless Access

Blueprint 2.5: SD-Access fabric design considerations for wired and wireless access

  • Overlay and fabric design
  • Control plane design
  • Border design
  • Segmentation and virtual networks
  • Scalability
  • Over the top and fabric for wireless
  • Multicast

2.4 described what the pieces are. This page is about how many of each, where to put them, and how to connect the fabric to everything else. The decisions here are the ones the exam turns into "which design meets this requirement" questions.

Fabric sites, domains and transits

A fabric site is a set of fabric nodes with its own control plane and borders. A fabric domain is the collection of sites managed by one Catalyst Center. Design starts with the question: one site or several?

Choose When
One large fabric site Single campus or metro area, one failure domain is acceptable, low-latency links among all buildings
Several fabric sites Geographically separate locations, a desire for independent failure domains, scale limits per site, or WAN-connected branches

Sites connect through a transit.

Transit What it carries Use
SD-Access transit VXLAN with VN and SGT intact end to end, uses a transit control plane Metro or campus links with high bandwidth, low latency and jumbo MTU. Policy follows traffic between sites
IP transit Plain IP, the VN and SGT are lost unless re-created WAN, internet, SD-WAN or any provider network. SGT must be carried another way (inline tagging or SXP) or mapped at the next hop 
graph LR
  subgraph "Site 1"
    S1["Edges and<br/>border 1"]
  end
  subgraph "Site 2"
    S2["Edges and<br/>border 2"]
  end
  S1 -- "SD-Access transit<br/>VXLAN, VN and SGT kept" --- S2
  S1 -- "IP transit<br/>VRF-Lite, SGT lost" --- WAN["WAN or SD-WAN"]
  WAN --- S2

Exam trap

SD-Access transit needs a network that behaves like a campus: high bandwidth, low latency, jumbo frames. A typical WAN does not qualify, so the answer for branch sites over a provider WAN is IP transit (or a separate fabric site with IP transit), and the SGT is carried by another method.

Control plane node design

Question Guidance
How many? At least two per site for redundancy. Edges register with every control plane node, so there is no active/standby election
Co-located or dedicated? Co-locate with the border in small and medium sites to save hardware. Use dedicated control plane nodes in large sites, where registration, lookup and roaming load are higher
Where? On stable, well-connected platforms in the core or distribution, away from the edge closets
What platform? Check the scale tables for the exact model. The limit is the number of endpoints (EIDs) it can hold
Underlay dependency Every edge and border needs reachability to the control plane node loopbacks, so protect those loopbacks

If the control plane node is lost, edges that already learned mappings keep forwarding for a while but new endpoints cannot register and unknown destinations cannot be resolved. That is why the redundant second node matters.

Border node design

The border is where most design mistakes appear. Pick the type first.

Border type Role Typical placement
Internal border Knows the internal prefixes outside the fabric (data centre, shared services) and registers them with the control plane Connects to the data centre or services block
External border Default exit for everything unknown. Traffic to unknown destinations goes there Connects to the WAN and internet
Anywhere border Does both Small sites with one exit pair

Border design points:

  • Two borders minimum for redundancy. Decide whether they are separate boxes in separate locations, and how the hand-off links connect.
  • Handoff method. Layer 3 handoff presents each VN as a VRF-Lite subinterface running a routing protocol (usually BGP) to a fusion router or firewall. Layer 2 handoff extends a fabric subnet to a traditional VLAN during migration.
  • Fusion device. It leaks routes between VNs and shared services, or applies firewall policy between them. It sits outside the fabric and has to be designed and managed separately.
  • Do not make the border a bottleneck. All traffic to anything outside the site passes through it. Size links and platform throughput for the sum of the site's external traffic. Traffic between fabric endpoints goes directly between edges, not through the border.
  • SGT outside the fabric. If policy must continue past the border, plan inline tagging or SXP.
graph TB
  F["Fabric site"] --> B1["Border 1"]
  F --> B2["Border 2"]
  B1 -- "VRF-Lite and BGP<br/>per VN" --> FU["Fusion router or firewall"]
  B2 -- "VRF-Lite and BGP<br/>per VN" --> FU
  FU --> SS["Shared services<br/>DHCP, DNS, ISE"]
  FU --> WAN["WAN and internet"]

Segmentation and virtual network design

  • Start with the fewest VNs that meet separation requirements. Typical VNs: corporate, guest, IoT or building systems, and a restricted VN for regulated systems. Each VN needs its own handoff and routing at the border.
  • Use SGTs for finer control inside a VN instead of creating many VNs.
  • Infrastructure VN. Fabric APs and extended nodes live in a special VN that lives in the global routing table. Its address pool must be reachable by Catalyst Center and the WLC.
  • IP pool planning. Pools belong to a VN and a site. Allocate per site in a way that is summarisable at the border, to keep the external routing table small.
  • Default policy. Decide whether the default between groups is permit or deny. A default-deny matrix is safer but needs a full contract list before enforcement.
Requirement Design
Two departments must not be able to route to each other at all Separate VNs
Two groups share a subnet or VN, but only some traffic is allowed Same VN, SGTs and SGACLs
Guests need internet only Guest VN, border sends it to the firewall and the internet, no route to the corporate VN
IoT sensors may talk only to their controller IoT SGT with SGACL, or a separate VN if the sensor vendor requires isolation

Wired and wireless access design

Wired

  • Edge switches terminate users, IP phones and APs. Use authentication templates (closed, open or low impact) matched to the rollout phase.
  • Extended nodes extend the fabric to compact switches in places such as warehouses or conference rooms. They connect to an edge over a trunk and have no fabric intelligence, so the edge does the work.
  • Anycast gateway per subnet gives mobility with no FHRP.

Wireless: fabric versus over the top

Factor Fabric-enabled wireless Over-the-top (OTT)
Policy consistency with wired Same VNs and SGTs Separate, applied on the controller
Forwarding Distributed to the edge Centralised through the WLC
Roaming Same subnet and gateway everywhere in the fabric, seamless Controller handles roaming, with the usual tunnel design
Controller requirement Fabric-capable WLC (Catalyst 9800 family) and fabric-capable APs Any WLC, existing deployment
Fits New builds, desire for one policy plane Migration, mixed estates, sites not yet in the fabric
Scale concern Control plane node registrations from wireless clients count toward its endpoint limit WLC throughput for all client traffic

Wireless endpoints roam constantly, so wireless client count and roaming rate drive control plane node sizing more than wired ports.

Exam trap

OTT wireless does not give wireless users the fabric's segmentation. The traffic rides CAPWAP across the fabric as ordinary IP to the WLC. If a requirement says Wi-Fi and wired users must have the same SGT policy, the answer is fabric-enabled wireless.

Scalability

Scalability in SD-Access is about limits per role and per site, so the design uses sites to scale out.

Dimension What limits it Design response
Endpoints per site Control plane node EID capacity and edge host table size Dedicated control plane nodes with larger platforms, or more sites
Number of VNs and routes Border and fusion capacity, per-VN handoff Few VNs, summarised pools
Edge nodes per site Platform and software scale tables Split into sites
Wireless WLC and AP counts per controller, fabric WLC per site Multiple WLCs, HA pair per site
Catalyst Center Devices and clients per cluster Larger appliance, or a cluster, or multiple instances for very large networks

Treat the published scale tables as the source of truth. Do not memorise numbers for the exam, but know which element's limit applies to which symptom.

Multicast in the fabric

Two methods deliver multicast across the fabric, and both are selectable per fabric site.

Head-end replication Native multicast
How The ingress node copies each packet as unicast to every edge with receivers The underlay runs multicast (PIM SSM) and replicates in the network
Underlay requirement None Underlay multicast routing on every fabric node
Efficiency Costly on the ingress node for many receivers Efficient and scalable
Operational load Low More configuration and troubleshooting skill
Fits Small sites and little multicast Large sites, video distribution, many receivers

The overlay multicast RP (rendezvous point) can be inside the fabric (often on the border) or external, for example in the data centre. Multicast sources and receivers in different VNs need design attention, since VNs are separate routing domains. For PIM mechanics see ENCOR multicast.

Exam trap

Native multicast in the fabric requires multicast in the underlay, usually PIM SSM between fabric nodes. Head-end replication needs nothing from the underlay but scales poorly with many receivers. If the question mentions heavy multicast video and large receiver counts, native multicast is the intended answer.

Design exercise

Scenario. A retail company has a head-office campus with 3,000 wired users and 1,500 Wi-Fi clients, plus 120 branch stores connected over an MPLS WAN. Requirements: head-office users and Wi-Fi share one policy, a point-of-sale (POS) group must reach only the payment servers, store traffic must not require an SD-Access transit, head office streams internal video to many viewers, and the head-office fabric must tolerate loss of one border or control plane node.

Model answer

Sites: one fabric site for head office. Treat branches as non-fabric sites reached over the WAN, or as small fabric sites with IP transit if they later need the fabric. A provider WAN cannot support SD-Access transit.

Control plane and border: two dedicated control plane nodes at head office, because wireless roaming and 4,500 endpoints raise registration load. Two borders (anywhere or internal plus external, depending on the data centre layout), each connected by VRF-Lite and BGP to a fusion firewall that also provides the internet and WAN path.

Segmentation: corporate and guest VNs. Inside corporate, SGTs for POS, staff, servers and payment servers, with SGACLs permitting POS only to payment servers. Carry SGTs to the WAN edge with inline tagging if the WAN supports it, or SXP if not.

Wireless: fabric-enabled, so Wi-Fi uses the same SGT policy and anycast gateway.

Multicast: native multicast with PIM SSM in the underlay, and an RP at the border or data centre for the overlay, so video is replicated in the network.

Rejected alternatives:

  • SD-Access transit to the stores. The MPLS WAN does not meet the bandwidth, latency and MTU needs.
  • Co-located control plane on the borders. It works at small scale, but with this endpoint and roaming load dedicated nodes are safer.
  • OTT wireless. It would break the shared-policy requirement.
  • Head-end replication. It would burden the ingress node with many viewers.
  • A VN per user group. It adds borders, routing and fusion work for what SGTs can do.

Quick check

Why can an SD-Access transit not run over a typical provider WAN?

It carries VXLAN with the VN and SGT end to end and needs high bandwidth, low latency and jumbo MTU like a campus or metro network. A provider WAN is better served by IP transit.

What must exist in the underlay for native multicast in the fabric?

Multicast routing in the underlay, normally PIM SSM, enabled on every fabric node. Head-end replication does not need it.

A company needs wired and wireless users to share one SGT policy. Which wireless model, and why?

Fabric-enabled wireless, because APs tunnel to the edge in VXLAN and the edge applies VN and SGT, the same as for wired users. OTT wireless bypasses the fabric's policy plane.

References

  • Cisco Software-Defined Access Solution Design Guide (CVD) and SD-Access Segmentation Design Guide: search on cisco.com
  • Cisco Catalyst Center scale and compatibility documents: search "Cisco Catalyst Center data sheet" and "SD-Access scale" on cisco.com
  • Cisco Catalyst 9800 wireless controller configuration guides: search on cisco.com
  • Cisco Live On-Demand Library: search "SD-Access design" and "SD-Access multicast"