Cisco Software-Defined Access changes campus design by separating the physical transport network from the virtual networks and identity policy experienced by endpoints. Catalyst Center orchestrates the fabric, Cisco ISE supplies identity and group-based policy context, and the fabric uses an underlay plus an overlay to provide reachability, mobility, and segmentation. The architecture is easier to understand when each plane is treated as a distinct responsibility rather than when SD-Access is described simply as \u201cautomated campus networking.\u201d<\/p>\n
The current 350-401 ENCOR<\/a> v1.2 blueprint includes virtualization and Cisco SD-Access concepts within enterprise architecture. Cisco’s current deployment guidance also emphasizes day-zero design, day-n operations, Catalyst Center and ISE integration, virtual networks, anycast gateways, and fabric roles. A robust deployment begins with a stable routed underlay and a clear segmentation model; automation cannot compensate for an underlay or policy design that was never made explicit.<\/p>\n The underlay provides IP reachability between fabric nodes. It should be highly available, easy to troubleshoot, and free from dependencies on endpoint-specific policy. Loopbacks, point-to-point routed links, predictable addressing, and an IGP are commonly used to make every fabric node reachable. The exact implementation can vary, but the design goal is stable transport for control-plane and overlay traffic.<\/p>\n Keep the underlay operationally boring. If a fabric edge loses reachability to a control-plane node because of an IGP or MTU problem, overlay symptoms can appear unrelated to the real cause. Monitor underlay adjacency, latency, loss, and routing changes independently from endpoint policy. A clean failure boundary lets operations prove whether the problem exists in transport, fabric control, or endpoint authorization.<\/p>\n Catalyst Center can automate underlay provisioning, but automated configuration still needs a deliberate IP plan, device roles, and reachability to services such as DNS, DHCP, NTP, AAA, and software repositories. Validate those dependencies before enabling fabric roles. If management reachability and time synchronization are unreliable, every later troubleshooting task becomes harder because controller inventory, certificates, event timestamps, and device state may disagree.<\/p>\n SD-Access uses VXLAN encapsulation to carry endpoint traffic across the routed fabric. VXLAN creates an overlay over the IP underlay, allowing logical segments to extend where policy requires them without making the physical topology one large Layer 2 domain. This gives the campus many of the scaling and failure-isolation advantages of routed infrastructure while preserving endpoint mobility within the fabric.<\/p>\n The distinction between traditional VLAN extension and VLAN versus VXLAN<\/a> is important. A VLAN is still used locally at the access edge, but the fabric does not depend on spanning the same Layer 2 segment hop by hop through the campus. The VTEP function on fabric nodes adds and removes VXLAN headers so packets can cross the underlay according to overlay identifiers.<\/p>\n Overlay MTU must be included in the underlay design because VXLAN adds encapsulation overhead. A fabric can pass small control traffic while dropping larger application packets if one routed link has a smaller MTU. Standardize interface MTU where the validated design requires it and include large-packet tests during acceptance. Intermittent MTU faults are difficult to diagnose because authentication and basic pings may succeed while file transfers or tunneled applications fail.<\/p>\n Fabric control-plane nodes maintain endpoint reachability information so that edge and border devices know where endpoints are attached. The fabric uses a map-and-resolve model rather than flooding every endpoint MAC and IP location throughout the campus. This separates identity and location: an endpoint can move, while the control plane updates where that endpoint is currently reachable.<\/p>\n Control-plane redundancy and reachability matter because edge nodes depend on those mappings for efficient forwarding. Plan node placement and scale according to Cisco’s validated guidance for the platform and release in use. During troubleshooting, verify whether an endpoint is correctly registered and resolved before assuming that the access switch or security policy is dropping packets.<\/p>\n SD-Access commonly uses LISP-derived control-plane functions to register endpoint identifiers and resolve where those endpoints are located in the fabric. Operators do not need to treat every LISP message as an exam mnemonic, but they should understand registration and resolution behavior. When a host moves, stale or missing location information can produce forwarding symptoms even though the endpoint’s local switch port and IP configuration appear correct.<\/p>\n Fabric edge nodes connect endpoints and apply the fabric’s logical policy at the access layer. Border nodes connect the fabric to external networks such as data centers, WANs, Internet services, or nonfabric campus areas. Some deployments combine roles, but the functional distinction remains useful: edge nodes represent endpoint attachment, while borders represent reachability exchange between the fabric and outside routing domains.<\/p>\n Choose border placement based on where external services exist and how resilient those exits must be. A single border can become a traffic and failure concentration even if every access layer is redundant. Define how default routes, shared services, and external prefixes enter each virtual network, and test what happens when one border or transit path fails. Fabric automation should make those relationships repeatable, not obscure them.<\/p>\n Transit design determines how one fabric reaches another fabric or external routing domain. IP transit, SD-Access transit, and other supported patterns have different policy and operational implications. Avoid choosing a transit method only because it is easiest to provision. Consider route scale, segmentation preservation, shared-services access, migration constraints, and whether group-based policy must extend beyond one fabric site.<\/p>\n External connectivity should also define route summarization and failure behavior. Borders may advertise fabric prefixes into a core or WAN and learn external routes back into selected virtual networks. Avoid leaking every endpoint route when a stable aggregate is sufficient, and make sure redundant borders advertise consistent policy. The fabric should remain reachable when one border is removed without causing unnecessary route churn across the rest of the enterprise.<\/p>\n A fabric site still has to exchange traffic with services that live outside the fabric. Fusion or border designs therefore need an explicit policy for which virtual networks can reach shared services, data centers, Internet exits, partner networks, and legacy campus segments. Do not allow the external routing boundary to collapse all segmentation into one undifferentiated table. Preserve VRF or policy context as far as the surrounding architecture supports it, and document where route leaking is intentionally performed. DNS, DHCP, identity services, monitoring, and management systems often become the first shared-service exceptions, so their reachability should be designed before user groups are migrated into the fabric.<\/p>\n Site boundaries also influence resiliency. A border node should not become a single attachment point for every virtual network, and control-plane or edge-node placement should reflect physical failure domains. Test what happens when a border path, fabric edge, wireless controller integration, or identity dependency fails. The expected result is more specific than ‘the fabric stays up’: critical endpoints should retain the intended policy and an alternate path to required services, while unauthorized cross-segment access should remain blocked. This is where SD-Access architecture and operational testing meet.<\/p>\n A virtual network gives SD-Access a large routing and policy boundary comparable to a VRF. Different virtual networks can carry separate address spaces and routing tables for populations such as corporate users, building systems, laboratories, or contractors. This is macro-segmentation: traffic between VNs is not automatically permitted simply because endpoints share the same physical campus infrastructure.<\/p>\n Do not create a virtual network for every organizational label. Each VN adds routing, service, and operational considerations. Start with trust boundaries that require separate routing or service policy. The broader idea of network segmentation<\/a> still applies: segmentation is useful when it expresses a security or operational boundary and when the organization can manage the traffic that legitimately needs to cross it.<\/p>\n Virtual-network boundaries should also align with operational ownership. If two business units require separate change windows, incident response, and security controls, a shared VN may create unnecessary coupling. If two teams need constant any-to-any access, separate VNs followed by extensive route leaking may create complexity without risk reduction. Macro-segmentation should make policy clearer, not merely multiply routing tables.<\/p>\n Security Group Tags provide identity-based policy inside or across permitted fabric contexts. Rather than building large access-control lists from IP addresses, an endpoint can be assigned a security group based on identity or role, and policy can define which groups may communicate. This decouples authorization from the endpoint’s specific address and supports mobility without requiring ACL rewrites every time a device moves.<\/p>\nBuild a simple routed underlay before adding fabric services<\/h3>\n
Use VXLAN as the data-plane overlay rather than stretching campus VLANs<\/h3>\n
Use control-plane nodes to map endpoint identity to location<\/h3>\n
Design fabric edge and border roles around traffic entry and exit<\/h3>\n
Use virtual networks for macro-segmentation<\/h3>\n
Use scalable group policy for micro-segmentation within a virtual network<\/h3>\n