Free Practice Questions for Cisco 300-420 Exam

Bootstrap Router is the standards-based mechanism for dynamic Rendezvous Point discovery in PIM Sparse Mode. Cisco supports several RP discovery methods, but they are not equivalent from a standards perspective. Auto-RP is Cisco-developed and widely used in Cisco environments, but it is not the standards-based choice. Static RP configuration is simple and deterministic, but it does not provide dynamic discovery and requires every router to be configured consistently. Anycast RP is a redundancy and load-sharing design in which multiple RPs share the same RP address, usually with MSDP or another synchronization method, but it is not the RP discovery mechanism itself. BSR allows candidate RPs and candidate BSRs to advertise RP-set information through the PIM domain so routers can learn RP mappings dynamically. This makes BSR suitable for large PIM domains where manual static RP configuration becomes operationally risky. In design, the architect should also protect BSR/RP placement, scope group ranges, and validate convergence behavior during RP or BSR failure. Reference topics: PIM-SM, Bootstrap Router, RP discovery, Auto-RP comparison, multicast control-plane design.

The new BGP route-reflector design reduces the iBGP peerings by 27. A full-mesh iBGP design with 9 routers requires n times n minus 1 divided by 2 peerings, which equals 9 times 8 divided by 2, or 36 sessions. Route reflectors are used specifically to reduce this scaling burden. In the redesigned topology, each of the three clusters has one route reflector and two clients, which requires two client-to-reflector sessions per cluster, or six sessions total. The three route reflectors must still maintain iBGP sessions with one another as nonclient peers, which adds three more sessions. The redesigned total is therefore nine sessions. The reduction is 36 minus 9, which equals 27. This reflects the core scaling benefit of route reflectors: clients no longer need a full iBGP mesh with every other client in the autonomous system. Reference topics: BGP route reflectors, iBGP scaling, full-mesh formula, route-reflector clients, nonclient peering.

BIDIR-PIM is the correct multicast solution for interactive many-to-many communication with many sources when source trees must not be used. Bidirectional PIM is specifically designed for applications where receivers can also be senders and where the number of sources can grow without creating per-source multicast state throughout the network. Instead of building shortest-path trees for each source, BIDIR-PIM uses a shared tree rooted at the rendezvous point and forwards traffic bidirectionally along that tree. This reduces multicast routing-table growth and control-plane churn in environments with many active sources. PIM dense mode is not appropriate because it floods and prunes traffic and is inefficient at scale. Any-source multicast with PIM-SM may create source trees, which violates the requirement. MSDP is used to exchange source information between PIM-SM domains and is not itself the forwarding mode for this campus or WAN multicast design. Reference topics: BIDIR-PIM, many-to-many multicast, shared tree, multicast source scaling, PIM design.

Bidirectional PIM is the multicast protocol mode designed for many-to-many applications where many receivers may also act as sources. In traditional PIM Sparse Mode, multicast forwarding can use shared trees through an RP and source-specific shortest-path trees. As the number of sources grows, maintaining source-specific state can increase routing table and control-plane scale requirements. BIDIR-PIM avoids source trees by using a shared bidirectional tree rooted at the rendezvous point address. Traffic from sources and traffic toward receivers uses the shared tree, which allows the multicast group to scale to a large number of sources without creating per-source state in the network. This aligns directly with the requirement that most multicast sources also receive multicast traffic and that source trees must not be used. PIM-SSM explicitly uses source-specific forwarding and requires receivers to know the source. PIM-SM may switch to source trees depending on behavior and policy. MSDP is used to exchange source information between PIM-SM domains, not to replace source trees inside one domain. Therefore, BIDIR-PIM is the correct design choice.

A routed access topology is the underlay design that removes the normal need for first-hop redundancy protocols. In a traditional Layer 2 access design, end hosts usually rely on HSRP, VRRP, or GLBP at the distribution layer because the default gateway is shared across redundant distribution switches. In a routed access design, the Layer 3 boundary is pushed down to the access layer. The access switch routes toward the distribution layer using point-to-point routed links, so uplink failures are handled by the routing protocol instead of spanning tree and first-hop redundancy. Cisco campus design guidance highlights routed access as a way to improve convergence, avoid Layer 2 loop exposure across uplinks, and simplify resiliency by using equal-cost routed paths. Virtualized topology is too broad and does not inherently remove FHRP. A Layer 2 topology normally increases dependence on STP and gateway redundancy. A logical fabric topology is not the generic underlay topology described by the question. The correct choice is therefore routed access. Reference topics: routed access campus, Layer 3 access, FHRP elimination, routed underlay resiliency.

The correct model is a 4-class QoS strategy with DiffServ. The traffic classes listed in the question are explicitly DiffServ per-hop behaviors: Expedited Forwarding for conversational traffic, Assured Forwarding class 2 for streaming, and Assured Forwarding class 3 for web or interactive traffic. Cisco QoS guidance uses DiffServ to classify and mark traffic with DSCP values, then apply per-hop behavior at each node along the path. This gives scalable end-to-end treatment across a provider backbone without maintaining per-flow reservations. The four service treatments implied are conversational, streaming, interactive/web, and background or best effort, which matches the stated service categories without unnecessary class expansion. IntServ is not appropriate for an ISP backbone because it uses RSVP-style per-flow signaling and state, which scales poorly compared with DiffServ PHB handling. The 8-class and 12-class options add complexity beyond the stated mappings. Reference topics: DiffServ, DSCP, EF, AF2, AF3, per-hop behavior, provider QoS design.

The design should use a scavenger queue for excessive or suspicious traffic and apply queuing on the access-to-distribution uplinks where congestion can occur. Cisco QoS campus design commonly uses a less-than-best-effort scavenger class to constrain traffic associated with worms, peer-to-peer applications, bulk background flows, or other nonbusiness traffic. Placing this traffic in a scavenger queue minimizes the bandwidth it can consume during congestion without harming real-time applications. Real-time voice or video traffic should be placed in a strict-priority queue so it receives low delay and low jitter treatment when links are congested. Applying queuing on access-to-distribution links is important because those uplinks are common campus congestion points, especially during bursts or abnormal traffic events. A shaping policy is not the right tool for campus LAN uplinks, and indiscriminate policing of real-time traffic can cause drops that damage voice and video quality. Reference topics: campus QoS, scavenger class, strict-priority queue, access uplink queuing, congestion management, worm mitigation.

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.

Bandwidth percentage with policing is the correct QoS approach. The requirement has two separate parts: each subnet must receive a minimum share during congestion, and no subnet should introduce delay into download traffic. Bandwidth percentage is used to allocate a minimum bandwidth guarantee among classes during congestion while still allowing a class to use unused bandwidth when other classes are idle. Policing enforces a rate by dropping or remarking excess traffic rather than buffering it. That behavior is important because the question explicitly says download traffic must never experience delay. Shaping would be wrong because shaping buffers excess packets and transmits them later, which intentionally adds delay. Rate- limiting is a broad term, but when the design choice offers policing explicitly, policing is the precise mechanism that matches the no-delay requirement. A parent or class policy can reserve 25 percent per subnet on a 40 Mbps service, giving each subnet 10 Mbps during congestion while unused bandwidth remains available. Reference topics: CBWFQ bandwidth percent, traffic policing, shaping versus policing, Internet edge QoS, congestion management.

WAN Edge: traffic forwarding, security, encryption, QoS, and routing protocols; vSmart: distributes routes and policy information via OMP; vManage: centralized provisioning and simplified network changes; vBond: communication for devices behind NAT.

The Cisco SD-WAN component mapping follows the normal separation of management, control, orchestration, and data-plane roles. WAN Edge routers are the data-plane devices at branches, data centers, campuses, or cloud edges. They forward user traffic and apply routing, QoS, encryption, segmentation, and security services. vSmart controllers provide the centralized control plane and distribute reachability and policy information with OMP, including prefixes, TLOCs, and service routes. vManage is the management-plane system; it supplies centralized provisioning, device templates, policy configuration, software lifecycle functions, monitoring, and operational visibility. vBond operates as the orchestration-plane component, authenticating devices during onboarding and helping devices behind NAT discover and establish the correct secure control connections. This separation is critical in enterprise design because each component has different redundancy, reachability, and scale requirements. The architect should not blur vManage and vSmart roles: vManage configures and monitors, while vSmart computes and distributes control policy. Reference topics: Cisco Catalyst SD-WAN architecture, WAN Edge data plane, vSmart OMP, vManage management plane, vBond orchestration.

is responsible for traffic forwarding, security, encryption, QoS,and routing protocols

distributes routes and policy information via OMP

enables centralized provisioning and simplifies network changes

enables the communication of devices that sit behind NAT