Legit 300-420 Exam Download

The SD-Access overlay should reduce subnet sprawl and avoid overlapping IP subnets unless there is a specific operational requirement. Cisco SD-Access creates overlay virtual networks over an IP underlay and uses anycast gateway, VXLAN encapsulation, LISP control-plane mapping, and policy constructs to simplify endpoint mobility and segmentation. Reducing the number of subnets simplifies DHCP scope management, default-gateway placement, and operational troubleshooting. Avoiding overlapping address space across overlay networks is also a practical design recommendation because overlapping subnets complicate shared services, fusion routing, security logging, and policy troubleshooting. LAN automation and a dedicated IGP process are underlay deployment considerations, not overlay design choices. Layer 3 to the access design is also associated with routed underlay and campus fabric transport, not the overlay segmentation model. A clean overlay design should define virtual networks, scalable groups, IP pools, shared-services reachability, and external connectivity before deployment. Reference topics: Cisco SD-Access overlay design, anycast gateway, virtual networks, DHCP simplification, overlapping subnet avoidance.

The correct BGP design is to attach the well-known No-Export community to the prefixes that should not be advertised beyond the service provider boundary. Cisco BGP communities are policy attributes that allow routes to carry instructions or classifications across BGP peers. The No-Export community tells a receiving BGP speaker not to advertise the route outside its confederation or autonomous system. That behavior is exactly what is needed when branch prefixes may be exchanged with the provider but must not be propagated to the public Internet. The No-Advertise community is stronger: it prevents the route from being advertised to any BGP peer, which may block reachability even where the provider still needs to know the route. NOPEER is used for route-server or peering policy control and is not the clean answer for excluding branch prefixes from Internet propagation. Setting a generic “Internet community” is not a standard solution by itself. The architect should also ensure that outbound prefix filters and provider-side community support are documented in the service agreement. Reference topics: BGP communities, No-Export, No-Advertise, provider edge filtering, Internet route policy.

Route leaking on R13 and R9 is required so the Level 1 area can make a better exit decision toward the server. In an IS-IS hierarchy, Level 1 routers know detailed topology only inside their own area. For destinations outside the area, they normally follow the closest attached Level 1/Level 2 router, which can produce suboptimal latency when another exit has a better end-to-end path. Route leaking selectively injects more specific Level 2 reachability information into Level 1, allowing routers in the New Office area to evaluate a better path instead of blindly following the nearest attached-bit exit. Changing metric style on R8 alone does not import the external-area route information needed for better path selection. A static route could force a path but would not be a scalable dynamic IS-IS design. Making R8 Level 1/Level 2 does not solve the need to expose the relevant route through the correct area boundary. Reference topics: IS-IS Level 1 and Level 2, attached bit, route leaking, interarea optimization, latency-aware routing.

Loop guard should be used on SW2 to reduce the chance of Layer 2 forwarding loops caused by a unidirectional fiber failure. In spanning-tree operation, a root or alternate port expects to receive BPDUs from the designated bridge. If BPDUs stop arriving because the fiber becomes unidirectional, the port may incorrectly assume that the path is no longer receiving a superior BPDU and transition toward forwarding. Cisco loop guard prevents this by moving the port into a loop-inconsistent state when BPDUs are unexpectedly lost on a non-designated port. That behavior protects the topology from a port role change that could create a Layer 2 loop. BPDU filter is dangerous in this context because it can suppress BPDUs and hide the control-plane signal STP needs. BPDU guard is mainly for PortFast edge ports that should never receive BPDUs. Root guard prevents superior BPDUs from changing root placement, but it does not address unidirectional loss of expected BPDUs. Therefore, loop guard on SW2 is the proper design control. Reference topics: STP loop guard, unidirectional fiber failure, BPDU loss, loop-inconsistent state, Layer 2 resiliency.