Cisco SD-Access separates the campus fabric into roles so endpoint attachment, endpoint location, underlay transport, and external connectivity do not all depend on the same function. A fabric site normally uses control-plane nodes, border nodes, and edge nodes, with intermediate nodes carrying the IP underlay. Understanding those roles is the fastest way to reason about both design and troubleshooting.<\/p>\n
The topic belongs in Enterprise Network Engineering<\/a> because SD-Access is still a network architecture: the overlay depends on a resilient underlay, routing boundaries still matter, and policy must survive failures. Current Cisco Catalyst Center documentation continues to describe control-plane, border, and edge roles, including colocated roles and fabric-in-a-box patterns for smaller deployments.<\/p>\n The most useful question is not \u201cwhich box is the controller?\u201d but \u201cwhich role owns this function?\u201d That prevents a client-authentication issue, a LISP mapping problem, and an external-routing problem from being investigated as if they were the same failure.<\/p>\n The SD-Access overlay rides on an IP underlay that must provide predictable reachability between fabric nodes. Intermediate nodes are part of that underlay but are not fabric roles. Their job is to forward encapsulated traffic and support the MTU required for the fabric, not to register endpoints or enforce the fabric control plane.<\/p>\n Routing resilience<\/a> matters because an overlay cannot compensate for an unstable underlay. Equal-cost paths, IGP convergence, link design, MTU, and failure domains should be validated before fabric policy is blamed.<\/p>\n Operationally, separate underlay health from overlay health. Ping and routing-table checks between fabric nodes answer different questions from LISP endpoint mappings or virtual-network policy.<\/p>\n Fabric edge nodes are the access layer of the fabric. They connect endpoints, provide the anycast Layer 3 gateway, register endpoint information with the control-plane node, and can enforce segmentation policy. This makes edge nodes the first place to inspect when a client fails to join the intended virtual network.<\/p>\n VLAN design<\/a> remains conceptually useful even though SD-Access abstracts much of the traditional VLAN sprawl. Endpoints still attach to physical ports and wireless networks, and the access edge still needs a clear mapping from onboarding context to the correct network and policy.<\/p>\n Do not overload edge nodes with unnecessary roles simply because the platform supports colocation. Role combinations should follow scale, failure, and operational requirements rather than feature density.<\/p>\n The fabric control plane uses LISP map-server and map-resolver functions to track where endpoints live. Edge nodes register endpoints, and other fabric nodes query the control plane to locate a destination. This decouples endpoint identity from a single physical path through the campus.<\/p>\n A control-plane problem often appears as inability to resolve or reach an endpoint even though the underlay between fabric nodes is healthy. Troubleshooting should check registrations, map resolution, and role health before changing VLAN or routing configuration.<\/p>\n Network diagnostics<\/a> is a useful discipline here: establish which database or control plane made the forwarding decision before touching the data plane.<\/p>\n Fabric border nodes are the gateways between the SD-Access site and external networks. They import and export reachability, preserve segmentation where required, and handle the point where fabric virtual networks meet data centers, WANs, internet exits, or nonfabric campus domains.<\/p>\n VRF design<\/a> becomes important because virtual networks are often represented by VRFs at the border. External route exchange needs to preserve the intended segmentation rather than collapsing every virtual network into a shared table.<\/p>\n Route redistribution<\/a> may appear at this boundary when the fabric and external domain use different routing protocols. The same loop-prevention and route-scope rules apply even when Catalyst Center automates part of the configuration.<\/p>\n Cisco supports several colocated patterns, including border plus control plane and fabric-in-a-box designs that combine border, control plane, and edge functions. Colocation can simplify a branch or small site, but it couples failure domains and capacity planning.<\/p>\n A site that depends on one physical stack for multiple roles should have an explicit resilience model. Hardware redundancy, software maintenance, control-plane load, endpoint scale, and external-routing load all converge on the same platform when roles are combined.<\/p>\n Large campuses often benefit from keeping roles more distinct because scaling and maintenance requirements differ. The architecture should choose colocation because it fits the site, not because it reduces the number of icons in a diagram.<\/p>\n Cisco ISE provides the identity and policy context used by SD-Access. ISE policy design<\/a> determines how endpoints authenticate and which authorization result they receive. Edge nodes relay authentication and enforce the resulting access context.<\/p>\n TrustSec segmentation<\/a> helps carry group-based policy across the fabric so access intent does not depend entirely on IP addressing. The network still needs a clear group taxonomy and enforcement model.<\/p>\n When access policy is wrong, inspect the authentication and authorization evidence before changing fabric routing. An endpoint placed into the wrong virtual network or security group can look like a network reachability problem even when the fabric is forwarding correctly.<\/p>\n Border redundancy should cover both fabric availability and external route behavior. If one border fails, the remaining border must have the routes, virtual-network mappings, and upstream capacity to carry the traffic. A redundant device without equivalent external reachability is not a redundant service.<\/p>\n Internal borders, external borders, and anywhere-border designs reflect different connectivity requirements. The design should make clear which destinations are reachable through each border role and how default routes or shared services are injected.<\/p>\n BGP policy<\/a> can still be relevant outside the fabric. SD-Access does not remove enterprise routing policy; it changes where that policy connects to endpoint identity and segmentation.<\/p>\n A structured incident flow asks whether the endpoint attached, authenticated, registered, resolved, traversed the underlay, crossed the correct border, and passed policy. Each question maps to a fabric role or adjacent system. That is much faster than logging into switches at random.<\/p>\nBuild a reliable underlay first<\/h3>\n
Edge nodes attach endpoints<\/h3>\n
Control-plane nodes map identity to location<\/h3>\n
Border nodes connect the fabric outward<\/h3>\n
Use role colocation intentionally<\/h3>\n
Connect ISE policy to fabric roles<\/h3>\n
Design borders for external-path failure<\/h3>\n
Troubleshoot by role instead of by device<\/h3>\n