Pass the Cisco CCNP Enterprise 300-420 Questions and answers with Dumpstech

When eBGP neighbors share the same autonomous system number, normal BGP loop-prevention behavior can block route acceptance because the receiving router sees its own AS in the AS_PATH. Two BGP features address this design condition. The allow-as-in feature permits a BGP router to accept routes even when its own AS appears in the AS_PATH a configured number of times. This is often used in dual-homed or migration designs where the same customer AS appears at multiple sites. The as-override feature is typically used by a provider edge router to replace the customer AS in the AS_PATH with the provider AS before advertising the route to another customer site that uses the same AS. Together, these features allow successful route exchange in same-AS eBGP scenarios while preserving loop-prevention intent through controlled policy. Advertise-best-external influences advertisement of best external paths and does not solve same-AS rejection. Bestpath as-path ignore affects path selection, not route acceptance. Client-to-client reflection is an iBGP route-reflector behavior, not an eBGP same-AS solution.

Enabling EIGRP stub routing on the spokes decreases convergence time in a hub-and-spoke design by reducing unnecessary queries and preventing spokes from being treated as transit routers. EIGRP convergence can be delayed when a router loses a route and must query many neighbors to determine whether an alternate path exists. In remote-site or spoke designs, a spoke normally has no useful alternate path for networks beyond itself, so querying it wastes time and can contribute to stuck-in-active conditions. Cisco EIGRP stub routing allows the spoke to advertise only permitted route types and informs upstream routers not to query the spoke for routes outside its scope. This creates a cleaner query boundary and accelerates convergence after link or route failures. Subsecond timers can detect neighbor loss more quickly, but they do not address the broader EIGRP query behavior shown in the design. Increasing hold or dead timers would slow detection, not improve convergence. Therefore, in the displayed hub-and-spoke EIGRP design, enabling stub routing on the spokes is the correct solution to decrease convergence time.

Cisco SD-WAN edge routers use a queuing model based on LLQ and WFQ concepts. Low Latency Queuing provides strict priority treatment for delay-sensitive traffic such as voice and real-time media, while Weighted Fair Queuing gives proportional service to other traffic classes based on bandwidth allocation. This combination aligns with SD-WAN requirements where business-critical and real-time traffic must be protected without starving normal data applications. FIFO is not appropriate for a multi-class WAN design because it does not distinguish application priority during congestion. A pure priority queue would risk starving lower-priority traffic if it were not controlled by policing or bandwidth limits. Hardware-specific campus queuing models such as 1P-4Q-2T describe certain switch egress queue structures, not the generic SD-WAN edge queuing architecture. In a professional SD-WAN QoS design, traffic is classified, marked, mapped to forwarding classes, and then scheduled using priority and weighted queues according to business intent. Reference topics: Cisco SD-WAN QoS, LLQ, WFQ, forwarding classes, application-aware WAN policy.

MSDP is the correct solution for multicast across different autonomous systems when RPs must discover active sources outside their local domain. In PIM Sparse Mode, each multicast domain can have its own rendezvous point. Without a mechanism to exchange source information, receivers in one domain may not know about active sources registered with an RP in another domain. Multicast Source Discovery Protocol solves that problem by allowing RPs to establish peer relationships and exchange Source-Active information. Cisco multicast design uses MSDP with PIM-SM when separate domains need to share multicast source reachability while relying on the unicast routing table for connectivity between RPs. SSM does not use an RP and depends on receivers joining a specific source and group. PIM-SM by itself works inside a domain but does not provide interdomain source discovery between RPs. PIM-DM is flood-and-prune and is not suitable for this sparse, interdomain design. Therefore, the organization should deploy MSDP between the RP devices or RP domains. Reference topics: MSDP, PIM-SM, interdomain multicast, Source-Active messages, RP-to-RP source discovery.

AS-path prepending is the correct inbound path-control tool for this design. The objective is for traffic entering AS100 to use link 1 during normal operation and link 2 only after a failure. In BGP, the AS_PATH attribute is a primary path-selection attribute used by external autonomous systems; a shorter AS path is normally preferred over a longer path. By prepending AS100 multiple times on advertisements sent from R4 across link 2, AS100 makes the backup path look less attractive to upstream networks while leaving it available for failover. Modifying next-hop on R3 or R4 does not influence how external networks choose between two entry points into AS100. Prepending on R3 would make the preferred link less attractive, which is the opposite of the requirement. The design should also document provider policy because some providers local-preference routes before AS path, but within the choices, prepending on R4 is the appropriate inbound traffic-engineering method. Reference topics: BGP AS_PATH, inbound path control, multihoming, backup Internet edge design.

GET VPN is the correct private WAN encryption technology when traffic must always be encrypted, multicast must be supported, forwarding overhead must be reduced, and security management must be centralized. Cisco Group Encrypted Transport VPN protects traffic over a private WAN without building traditional point-to-point or multipoint tunnel overlays. Because it preserves the original IP header, the provider or enterprise routing core can still make normal forwarding decisions, and multicast, QoS, and routing behavior are easier to preserve than with heavy tunnel overlays. GET VPN uses a key server model to centralize group policy and distribute encryption keys to group members. This reduces the operational burden of maintaining many permanent tunnels. DMVPN supports multicast through GRE and provides dynamic tunnels, but it adds tunnel encapsulation overhead and does not meet the reduced-overhead private WAN requirement as cleanly. Plain mGRE lacks the full centralized group encryption model. Reference topics: GET VPN, group encryption, private WAN security, multicast support, key server, tunnel-less IPsec.

Before troubleshooting IPsec in a DMVPN deployment, the administrator should verify the GRE tunnel operation. DMVPN is built from multipoint GRE, NHRP, routing, and usually IPsec encryption. IPsec protects the tunnel traffic, but the logical tunnel and overlay reachability must be valid first. If the tunnel interface is down, incorrectly addressed, or unable to carry GRE traffic, troubleshooting crypto maps or ISAKMP will waste time because encryption cannot fix a broken overlay. After the GRE tunnel state is validated, the administrator can confirm NHRP registration and resolution, routing adjacencies, and then IPsec security associations. ISAKMP and crypto map troubleshooting are relevant only after basic tunnel operation is known to be correct. NHRP is also critical in DMVPN, but the question asks what to do before troubleshooting IPsec configuration; the first prerequisite is to verify that the GRE tunnel itself is functioning. This layered troubleshooting order follows Cisco operational practice: confirm transport reachability, then tunnel interface behavior, then NHRP and routing, and finally cryptographic protection.

StackWise Virtual is the correct technology for Cisco Catalyst 9500 aggregation switches when the design requires nonblocking Layer 2 multichassis EtherChannel from aggregation to access. The question specifically describes Catalyst 9500 switches located on different floors for availability, with access switches dual-homed through a Layer 2 MEC design. Traditional VSS was used on older Catalyst platforms such as Catalyst 4500 and 6500 families. For Catalyst 9000 platforms, Cisco uses StackWise Virtual to virtualize two physical switches into a single logical switching system. This enables multichassis EtherChannel, removes the need for STP to block one uplink, improves convergence, and provides device-level redundancy. vPC is a Nexus data-center technology, not a Catalyst campus aggregation technology. StackWise-180 refers to physical stack bandwidth behavior on specific access platforms and does not provide the same distributed campus aggregation function. Therefore, the design should use StackWise Virtual on the Catalyst 9500 aggregation pair. Reference topics: Catalyst 9500, StackWise Virtual, multichassis EtherChannel, campus aggregation, Layer 2 resiliency.

A full-mesh topology best satisfies the requirement that devices make informed forwarding decisions, backup paths always exist, and suboptimal paths are used only after a failure. In a full mesh, each site or WAN node has direct connectivity to every other relevant node. This gives the routing protocol complete path visibility and allows traffic to use direct optimal paths under normal conditions. If a direct link fails, alternate paths remain available through other nodes, so the network can reroute without depending on a single hub. A hub-and-spoke design is simpler and less expensive, but spoke-to-spoke traffic must traverse the hub, which is suboptimal even during normal operation. A partial mesh can reduce cost but may still force some traffic over indirect paths when no direct connection exists. Clos is a data center fabric topology concept and is not the typical WAN topology answer here. The full mesh is the most resource-intensive design, but it best matches the stated forwarding and backup requirements. Reference topics: WAN topology, full mesh, path optimality, backup paths, routing convergence.

DMVPN is the correct design because it satisfies all of the stated branch requirements without requiring manually built static tunnels for every store. Cisco DMVPN uses multipoint GRE with NHRP and IPsec to create a scalable hub-and-spoke overlay, and later phases allow dynamic spoke-to-spoke tunnels when branch-to-branch traffic is required. GRE supports multicast and dynamic routing protocols, while IPsec supplies encryption across the lower-cost WAN transport. This fits the requirement to deliver multicast training, use dynamic routing, preserve QoS markings and policy behavior, and simplify future branch additions because new spokes can register dynamically with the hub. VPLS would provide Layer 2 multipoint service, but it is typically a provider-delivered service and does not meet the secure dynamic VPN requirement as directly. GET VPN is efficient for private MPLS environments, but it does not create dynamic GRE tunnels from the hub for new stores. Static IPsec is secure but operationally poor at scale and does not natively carry multicast without an overlay. Therefore, the design should include DMVPN. Reference topics: DMVPN, mGRE, NHRP, IPsec protection, multicast over VPN.