{"id":3197,"date":"2026-10-08T12:09:44","date_gmt":"2026-10-08T12:09:44","guid":{"rendered":"https:\/\/www.examtopics.biz\/blog\/cisco-300-420-sd-access-fabric-design\/"},"modified":"2026-10-21T11:48:39","modified_gmt":"2026-10-21T11:48:39","slug":"cisco-300-420-sd-access-fabric-design","status":"publish","type":"post","link":"https:\/\/www.examtopics.biz\/blog\/cisco-300-420-sd-access-fabric-design\/","title":{"rendered":"Cisco 300-420: SD-Access Fabric Design"},"content":{"rendered":"

Cisco Software-Defined Access changes campus design by separating endpoint identity and segmentation from the physical underlay that transports packets. A fabric site combines edge nodes, control-plane nodes, border nodes, and usually wireless and identity services under Cisco Catalyst Center orchestration. The current 300-420 ENSLD<\/a> v1.1 exam explicitly includes Software-Defined Access, and Cisco’s 2026 design guidance continues to define these fabric roles as the core of the architecture.<\/p>\n

The design goal is not to eliminate routing. SD-Access depends on a stable Layer 3 underlay, then builds a LISP-based control plane and VXLAN data plane over it. When engineers understand those layers separately, site boundaries and failure behavior become much easier to reason about.<\/p>\n

Build the underlay for simple IP reachability<\/h2>\n

The underlay connects fabric nodes and provides the IP reachability required by the overlay. Intermediate nodes do not need to understand endpoint identity; they must forward the encapsulated traffic reliably and support the required MTU for VXLAN overhead.<\/p>\n

Keep underlay addressing, routing, and redundancy simple. The fabric overlay should not depend on a fragile chain of static routes or ambiguous Layer 2 paths. Cisco Catalyst Center can automate underlay deployment in supported designs, but automation does not remove the need to understand what routing relationships are created.<\/p>\n

Monitor underlay loss, latency, MTU, and route convergence independently from fabric endpoint behavior. If fabric control traffic cannot reach another node because the underlay is broken, troubleshooting LISP registrations first wastes time.<\/p>\n

Place fabric edge nodes where endpoints attach<\/h2>\n

Fabric edge nodes are the access-layer connection point for users, devices, phones, and access points. They detect connected endpoints, provide the anycast Layer 3 gateway, map endpoints into virtual networks, and register endpoint location with the control plane.<\/p>\n

Edge capacity planning therefore includes ordinary access concerns plus fabric state: endpoint scale, virtual networks, policy enforcement, uplinks, and wireless integration where applicable. A switch may support the role technically while still being the wrong choice for the required endpoint or policy scale.<\/p>\n

Site design should also define which access switches remain outside the fabric and how those traditional segments connect. Migration often produces mixed environments for a period of time.<\/p>\n

Make control-plane nodes resilient and reachable<\/h2>\n

The SD-Access control plane uses LISP<\/a> Map-Server and Map-Resolver functions to associate endpoint identifiers with routing locators. Edge and border nodes register and query this information so traffic can be encapsulated toward the correct destination location.<\/p>\n

Cisco recommends resilient control-plane placement because endpoint lookup is a core fabric dependency. Place control-plane nodes on platforms and failure domains that match the site’s size and availability target. Do not hide both logical control-plane roles inside one physical failure domain merely because the topology diagram shows two icons.<\/p>\n

Monitor registrations and lookup health. An endpoint can be physically connected and authenticated while traffic fails because its registration is stale or absent.<\/p>\n

Use border nodes as explicit fabric exit points<\/h2>\n

Border nodes connect the fabric site to networks outside the fabric. They advertise aggregate endpoint space externally, attract traffic destined for fabric endpoints, and extend segmentation using VRF-aware mechanisms where required. They are therefore both routing boundaries and policy boundaries.<\/p>\n

Design the number and type of border nodes around external connectivity. Internal borders, external borders, and other supported border roles solve different reachability problems. Minimize unnecessary border complexity because every additional exit can complicate route advertisement and troubleshooting.<\/p>\n

At the border, the routing fundamentals represented in 350-401 ENCOR<\/a> still apply: BGP or IGP policy, resilient links, and predictable next-hop reachability must be correct even when Catalyst Center automates the fabric configuration.<\/p>\n

Use virtual networks and SGTs for different kinds of segmentation<\/h2>\n

Virtual networks provide macro-segmentation by creating separate routing domains, similar in purpose to VRFs. Security Group Tags provide identity-based policy inside or across those virtualized spaces. Treat them as different tools: one separates routing tables, while the other expresses group-based access policy.<\/p>\n

Do not create a new virtual network for every small policy distinction. Excessive VNs increase routing and operational complexity. Conversely, do not force unrelated trust zones into one VN simply because SGT policy can technically filter them.<\/p>\n

Design naming and policy ownership before deployment. Identity-based policy becomes difficult to operate when group meanings are unclear or when several teams can create overlapping tags without governance.<\/p>\n

Define fabric site boundaries around latency and operations<\/h2>\n

A fabric site is a logical unit with its own fabric roles. Site boundaries should reflect geography, failure domains, operational ownership, and control-plane requirements. Extending one site too broadly can couple distant locations that would be easier to operate independently.<\/p>\n

Multi-site designs need a transit strategy between borders. Cisco supports several transit patterns depending on the architecture. The transit should preserve only the segmentation and reachability that must cross site boundaries rather than turning every site into one giant shared failure domain.<\/p>\n

For small locations, Fabric in a Box can combine border, control plane, and edge roles on one device or resilient system. Cisco positions that model for smaller endpoint counts, but the consolidated roles also consolidate failure impact, so the availability requirement still matters.<\/p>\n

Design wireless as part of the fabric, not an afterthought<\/h3>\n

Fabric-enabled wireless integrates wireless endpoints into the same policy and segmentation architecture. Wireless LAN controllers, access points, edge nodes, and control-plane nodes must be placed and sized as a system. Roaming and site-local behavior depend on the exact wireless design.<\/p>\n

Keep wireless transport, controller reachability, and fabric role dependencies visible in the design documentation. A wireless user problem may originate in RF, controller state, authentication, fabric registration, or underlay transport; the troubleshooting workflow should distinguish them.<\/p>\n

Consistent virtual-network and SGT policy across wired and wireless access is one of the architectural benefits, but consistency requires coordinated identity and policy design.<\/p>\n

Validate fabric readiness before assigning roles<\/h2>\n

Cisco Catalyst Center performs readiness checks, but a design review should independently verify supported platforms, software versions, licensing, MTU, routed reachability, IP addressing, and role scale. Cisco’s compatibility matrices change over time, so a platform that supported one role in an older release may have different recommendations later.<\/p>\n

After provisioning, verify each layer separately: underlay adjacency and reachability, LISP control-plane registrations, VXLAN forwarding, border advertisements, endpoint authentication, and policy enforcement. Catalyst Center assurance can help correlate these views, but it should complement protocol-level evidence.<\/p>\n

SD-Access works best when automation sits on top of a comprehensible design. A clean underlay, deliberate fabric roles, bounded sites, and governed segmentation make the fabric easier to scale and far easier to troubleshoot than an architecture that treats Catalyst Center as a black box.<\/p>\n

Plan migration and troubleshooting across fabric and nonfabric networks<\/h2>\n

Most SD-Access deployments coexist with traditional campus networks during migration. Define where endpoint subnets move into the fabric, how old VLANs reach new virtual networks, and which border advertises each set of prefixes. Duplicate or overlapping advertisement during migration can attract traffic to the wrong site even when both environments are individually healthy.<\/p>\n

Troubleshooting should identify the layer before changing policy. If an endpoint is missing from the control-plane database, investigate onboarding and LISP registration. If the endpoint is registered but unreachable from outside the site, inspect border advertisement and external routing. If routing is correct but access is denied, then examine SGT or policy behavior. This prevents teams from changing identity policy to fix an underlay problem.<\/p>\n

Keep a small set of deterministic tests for every fabric site: underlay reachability between fabric nodes, control-plane registration for a test endpoint, VXLAN forwarding inside a VN, external reachability through the border, and policy enforcement between known security groups. Run them after upgrades and significant provisioning changes.<\/p>\n

Migration plans should also include rollback. If a subnet is moved into the fabric and a critical application fails, the team needs to know how to restore its previous gateway and routing advertisement without creating two active locations for the same prefix. Fabric automation accelerates changes, so rollback discipline becomes more important rather than less.<\/p>\n

Address planning should support border summarization and site autonomy. Endpoint pools that align cleanly with fabric sites allow borders to advertise coarse aggregates externally while keeping individual endpoint location inside the LISP control plane. Random overlapping allocations make external routing more complex and reduce one of the fabric’s scale benefits.<\/p>\n

Identity dependencies need redundancy too. Cisco ISE policy services, directory integrations, certificates, and time synchronization can affect endpoint authorization even when the fabric forwarding plane is healthy. Design authentication failure modes explicitly: which endpoints can use critical access, what happens when identity services are unreachable, and how quickly policy recovers.<\/p>\n

Software lifecycle planning is especially important because Catalyst Center, ISE, switch software, wireless software, and fabric compatibility are interdependent. Validate supported combinations before upgrading one component. A new feature is not useful if adopting it moves the deployment outside a tested compatibility matrix.<\/p>\n

Finally, keep the source of truth clear. Catalyst Center should represent the intended fabric design, while manual CLI changes on managed fabric nodes can create drift or be overwritten. Emergency procedures should state when direct device changes are allowed and how they are reconciled back into the controller-managed configuration afterward.<\/p>\n

Policy scale should be tested with realistic endpoint movement. Users and devices can roam between edges, move between wired and wireless access, or reconnect after sleep. The control plane must update endpoint location quickly enough that stale mappings do not send traffic toward the previous edge. Assurance data should make those registration transitions visible during validation.<\/p>\n

External services such as firewalls, data centers, and WANs also need a deliberate segmentation handoff. If the fabric carries several VNs to a border, the upstream network must preserve or intentionally collapse that separation. VRF-Lite, firewalls, or other service insertion can extend the trust boundary, but every handoff should state which VN maps to which external routing and security context.<\/p>\n","protected":false},"excerpt":{"rendered":"

Cisco Software-Defined Access changes campus design by separating endpoint identity and segmentation from the physical underlay that transports packets. A fabric site combines edge nodes, […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[101,29,48,32],"tags":[],"class_list":["post-3197","post","type-post","status-publish","format-standard","hentry","category-exam-300-420","category-certifications","category-cisco-certifications","category-networking"],"_links":{"self":[{"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/posts\/3197","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/comments?post=3197"}],"version-history":[{"count":2,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/posts\/3197\/revisions"}],"predecessor-version":[{"id":5666,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/posts\/3197\/revisions\/5666"}],"wp:attachment":[{"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/media?parent=3197"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/categories?post=3197"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/tags?post=3197"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}