Free Practice Questions for Cisco 300-420 Exam

BGP Multipath Load Sharing is the feature used when a single router has two parallel BGP paths to the same ISP and the design goal is to install more than one eligible BGP path in the routing table. By default, BGP selects a single best path after evaluating path attributes such as weight, local preference, AS path, origin, MED, eBGP over iBGP, IGP metric to next hop, and tie breakers. When the competing paths are sufficiently equivalent and BGP multipath is enabled, Cisco IOS can install multiple BGP next hops for the same prefix and allow the forwarding plane to load share across both links. Multihop is used to establish BGP sessions to non-directly connected neighbors, not to load balance. Next-Hop Address Tracking improves convergence by tracking next-hop reachability, but it does not itself create load sharing. AS-path prepending intentionally makes a path less preferred for inbound traffic engineering. Therefore, the correct BGP feature for balancing outbound traffic across two links to the same ISP is Multipath Load Sharing.

PIM BSR is the best final design action because the source uses group 239.1.1.1, which is an administratively scoped ASM multicast group, and dense mode is not allowed. In PIM sparse mode, ASM groups require a rendezvous point so receivers can join the shared tree and sources can register. PIM SSM is not the right match for 239.1.1.1 because SSM normally uses the 232.0.0.0/8 group range and requires receivers to know the source address. Auto-RP can distribute RP information, but traditional Auto-RP discovery relies on multicast groups that often require sparse-dense behavior, which conflicts with the requirement that dense mode is not allowed. BSR is the standards-based PIM mechanism for dynamic RP discovery in sparse-mode networks and avoids static RP configuration on every router. Anycast RP is an RP redundancy design but still requires RP discovery or static RP configuration. Reference topics: PIM sparse mode, Bootstrap Router, ASM, RP discovery, administratively scoped multicast.

IPv6 overlay tunnels should be treated as a transition mechanism, not as the final desired enterprise architecture. Cisco IPv6 migration guidance describes tunneling as a way to connect IPv6 islands across an IPv4 infrastructure or to carry one protocol over another while the network is being migrated. This is useful when parts of the infrastructure cannot yet run IPv6 natively, but it also adds encapsulation overhead, additional MTU considerations, troubleshooting complexity, and operational dependency on the underlay transport. A permanent IPv6 architecture should eventually support IPv6 natively, or support both IPv4 and IPv6 through dual stack where required. The statement that overlay tunnels are a final IPv6 architecture is therefore incorrect. Overlay tunnels are not limited only to border devices in every design, and they do not require only the IPv6 stack; they commonly encapsulate IPv6 traffic over IPv4 infrastructure. The option stating that IPv4 packets are encapsulated in IPv6 packets also reverses the common IPv6-over-IPv4 migration use case. Therefore, overlay tunneling should be designed as a temporary transition technique.

The design combines Dual-Stack Lite from the devices toward the core MPLS network and NAT44/64 from the MPLS network toward the Internet gateway router. The requirements describe IPv6-facing clients that still need access to IPv4 services and DNS behavior that allows the same service name to be reached during migration. Dual-Stack Lite carries IPv4 customer traffic across an IPv6 access or provider network by tunneling IPv4 packets over IPv6 toward a provider translation point. NAT44/64 services then provide translation or address-family interworking for IPv4-only resources. This combination is used when customer-facing access moves to IPv6 while legacy IPv4 services remain reachable during transition. A simple IPv6 tunnel from devices to the MPLS core does not provide the required IPv4 service translation. Using only NAT44/64 from end devices also shifts complexity to clients rather than placing translation at the network edge. The selected choices match the staged migration model: IPv6 transport with encapsulation in the access/core side and translation at the provider or gateway boundary. Reference topics: IPv6 transition, DS-Lite, NAT64, DNS64, IPv4-over-IPv6 tunneling.

The border node provides connectivity between the SD-Access fabric and networks external to the fabric. In Cisco SD-Access, fabric edge nodes connect endpoints, intermediate nodes provide underlay transport, and control-plane nodes maintain endpoint-to-location mappings. Border nodes sit at the boundary of the fabric and connect the overlay to external Layer 3 networks such as WAN, data center, Internet edge, shared services, or other fabrics. They de-encapsulate VXLAN traffic leaving the fabric and advertise or import reachability using VRFs and routing protocols. A border can be internal, external, or anywhere border depending on whether it connects to shared services, outside networks, or both. Intermediate nodes do not provide external fabric exit; they only transport traffic within the underlay. Edge nodes connect endpoints but are not normally the external gateway for the whole fabric. Control-plane nodes provide mapping services, not external connectivity. Reference topics: SD-Access border node, fabric exit, VRF mapping, external connectivity, overlay-to-underlay boundary.

Option A is the best addressing design because it gives each site enough capacity while avoiding excessive address waste and supporting summarization. A campus requiring 12,000 devices needs at least 14 host bits because 2^13 minus two is only 8190 usable addresses, while a /18 provides 16,382 usable addresses. That leaves room for growth without assigning an unnecessarily huge block. Each branch requiring 1,000 devices needs at least 10 host bits; a /22 provides 1,022 usable addresses, but /21 provides 2,046 usable addresses and additional growth capacity. The selected branch blocks, 10.0.192.0/21 and 10.0.200.0/21, are contiguous on valid /21 boundaries and can be summarized cleanly where appropriate. Option D fails because a /20 supports only 4094 usable addresses and cannot accommodate the 12,000-device campus. Option B overallocates a /16 to the campus and /20s to branches, wasting resources. Option C is grossly oversized and operationally poor. Reference topics: hierarchical IPv4 addressing, route summarization, VLSM, host-capacity planning, convergence containment.

The correct solution is a management VRF with SSH keys for device access. A management VRF creates a separate routing and forwarding table for management traffic, keeping administrative reachability isolated from production and overlay routes. That directly satisfies the requirement that the overlay network must not cause routing issues and makes troubleshooting easier for operations teams because management reachability can be validated independently. Cisco VRF design uses separate routing tables to isolate traffic and can support overlapping addresses or independent routing policy. For secure device access, SSH with key-based authentication provides encrypted administrative sessions and stronger authentication than clear-text or password-only methods. Private VLANs and ordinary VLANs provide Layer 2 separation but do not create independent routing tables. TACACS+ and RADIUS are AAA systems; they are useful but do not define the management transport architecture. Separate physical interfaces can be useful out-of-band, but the best match for overlay isolation and operational simplicity is management VRF plus SSH keys. Reference topics: management VRF, secure device access, SSH public-key authentication, routing-table isolation, enterprise management design.

The primary HSRP device should use the preempt delay feature. When a failed primary distribution switch returns, HSRP preemption allows it to reclaim the active gateway role because it has the higher priority. However, routing protocols, trunks, line cards, FIB programming, or upstream convergence may not be fully ready at the instant HSRP becomes active again. If the device preempts too quickly, hosts forward traffic to a gateway that is not yet ready to forward all flows, causing temporary packet loss. Cisco HSRP preempt delay prevents immediate takeover by delaying preemption after reload or interface recovery, giving the switch time to rebuild control-plane and forwarding-plane state. Increasing hello timers slows failure detection and does not solve the premature takeover problem. Applying preempt delay to the backup device is not the issue because the returning primary is the device that reclaims active state. MAC refresh timers are not the primary mechanism for this condition. Therefore, the design should configure preempt delay on the primary HSRP device. Reference topics: HSRP preemption, preempt delay, gateway recovery, campus high availability, convergence coordination.

The No-Export community is the appropriate filtering mechanism when a design must prevent an autonomous system from becoming an unintended transit path. In a multihomed BGP design, a customer AS can accidentally advertise routes learned from one provider to another provider. If that happens, external traffic may cross the customer network to reach destinations beyond it, making the customer a transit AS. Applying No-Export to the appropriate learned or advertised routes instructs the receiving AS not to advertise those routes outside its own AS boundary. This helps contain route propagation and prevents third parties from learning paths through AS64512. Maximum-prefix protects a router from receiving too many routes; it is not a transit-prevention policy. No-advertise is more restrictive and prevents advertisement to all peers, which may break required internal or provider reachability. Next-hop is a path attribute used for reachability and path selection, not a route-leak prevention mechanism. In production, No-Export should be combined with explicit prefix filters so policy does not depend on community handling alone. Reference topics: BGP No-Export, transit AS prevention, route-leak control, BGP communities, multihoming.

A single VPLS instance is the correct Layer 2 VPN design because the customer requires service-provider transparency and direct communication between CE routers attached to the same VLAN. Virtual Private LAN Service provides a multipoint Ethernet LAN service across a provider MPLS or IP backbone. To the customer, the provider network behaves like a transparent Layer 2 switching domain, allowing CE devices in the same VLAN to communicate directly at Layer 2. VPWS is point-to-point, so multiple VPWS circuits would be required to approximate multipoint connectivity, and the design would not provide the same transparent shared LAN behavior. Multiple VPLS instances are unnecessary when the requirement is a single VLAN or single broadcast domain. VPLS also hides provider devices from the customer Layer 2 service view while allowing MAC learning and forwarding across the provider edge. Reference topics: VPLS, Layer 2 VPN, multipoint Ethernet service, CE transparency, VLAN extension, service provider WAN design.