Free Practice Questions for Cisco 300-420 Exam

DiffServ is the correct technology because the customer wants distributed QoS based on packet marking and per-hop treatment. Cisco differentiated services designs classify and mark traffic at the network edge, normally using DSCP values, and each device along the path applies a locally defined per-hop behavior to that traffic class. This model scales well in enterprise WANs because routers do not need to maintain per-flow state across the entire network. CBWFQ and LLQ are queuing mechanisms that can implement DiffServ treatment, but they are not the overall QoS architecture requested by the question. IntServ uses RSVP and per-flow resource reservation, which provides stronger admission-style guarantees but does not scale as well for large distributed WAN environments. The question specifically mentions individual packet marking and forwarding based on hop-by-hop treatment, which is the language of DiffServ. A complete design should define trust boundaries, DSCP markings, class maps, queue policy, and provider handoff behavior. Reference topics: DiffServ, DSCP marking, per-hop behavior, distributed QoS, WAN QoS architecture.

Forward error correction and quality of service are the two listed techniques that directly improve application experience in a Cisco SD-WAN design. Forward error correction protects selected application traffic by sending recovery information so packet loss can be corrected without waiting for retransmission. That is especially useful for real-time voice and video traffic, where retransmission delay can degrade quality. QoS improves application treatment by classifying, marking, queuing, shaping, and prioritizing traffic according to business intent and application sensitivity. Cisco SD-WAN designs commonly combine application-aware routing, QoS, and loss-mitigation features to keep critical traffic on the best path and preserve service quality during congestion or impairment. A stateful firewall, AMP, and Cisco Umbrella improve security posture, but they do not primarily improve application experience in the forwarding-quality sense asked by the question. They may protect applications, but they do not directly address loss, delay, jitter, and congestion treatment. Therefore, FEC and QoS are the best answers. Reference topics: Cisco SD-WAN application experience, FEC, QoS, loss mitigation, real-time traffic handling.

NETCONF: SSH-based; built to support candidate configuration. RESTCONF: HTTPS-based; lacks support for two-phase commit transactions.

NETCONF and RESTCONF both use YANG data models, but they use different transport and transaction behaviors. NETCONF is traditionally SSH-based and was designed as a network configuration protocol with datastore concepts such as running, startup, and candidate configuration where supported. The candidate datastore enables staged configuration changes and a commit workflow, which is useful for transactional network changes. RESTCONF exposes YANG-modeled resources through an HTTP-based REST interface, typically protected with HTTPS. It is simpler for web-style application integration because it uses familiar HTTP methods, URIs, and payload encodings such as XML or JSON. However, RESTCONF does not provide the same full two-phase commit transaction model associated with NETCONF candidate configuration workflows. Therefore, the correct mapping is that NETCONF is SSH-based and built to support candidate configuration, while RESTCONF is HTTPS-based and lacks support for two-phase commit transactions. In Cisco programmability design, NETCONF is often selected for robust configuration transactions, whereas RESTCONF is often selected for simpler API-driven integration.

The scalable BGP design should use VPNv4 on the PE routers for L3VPN site routes and BGP IPv4 unicast on ABRs to connect multiple IGP/LDP domains. VPNv4 is the correct MP-BGP address family for carrying customer VPN routes across a provider MPLS Layer 3 VPN core because it combines route distinguishers and VPN labels with customer prefixes. This lets the provider scale many customer routes while maintaining separation between VPNs. When the provider network spans multiple IGP or LDP domains, BGP IPv4 unicast can be used at ABRs to carry infrastructure reachability and avoid trying to flood a single IGP domain across the entire provider backbone. Full-mesh iBGP among all routers in different IGP domains is not scalable and conflicts with the requirement that thousands of routes will be added. Redistributing all IGP routes into a single BGP IPv4 instance without VPNv4 does not preserve customer VPN separation. Filtering loopbacks everywhere is not the core scaling solution. Reference topics: MP-BGP VPNv4, MPLS L3VPN, ABR design, interdomain provider routing, route scale.

The multicast Reverse Path Forwarding check is a loop-prevention mechanism. Cisco multicast forwarding does not forward traffic merely because the packet arrived on any multicast-enabled interface. Instead, the router checks whether the packet arrived on the interface that would be used to route traffic back toward the multicast source or, in shared-tree cases, back toward the rendezvous point. If the packet arrives on the expected reverse path, it passes the RPF check and can be replicated to the outgoing interface list. If it arrives on the wrong interface, it is dropped to prevent loops and duplicate packets. This supports a loop-free multicast distribution tree from sources to receivers. Auto-RP mapping agents, bootstrap messages, and RP-set discovery are separate rendezvous point distribution mechanisms; they are not the function of the RPF check. In enterprise designs with redundant links, asymmetric routing, or multiple equal paths, multicast RPF behavior must be reviewed carefully because unicast routing choices directly influence whether multicast packets are accepted or discarded. Reference topics: multicast RPF, PIM forwarding, loop prevention, outgoing interface list.

The selected IS-IS design must place the correct routers as Level 1/Level 2 boundary routers so that area failures stay local while traffic can still reach backbone application services. In a hierarchical IS-IS design, Level 1 routers exchange detailed topology only inside their own area. Level 2 routers form the backbone used for interarea connectivity. L1/L2 routers connect the local area to the backbone and advertise reachability between the two levels. Areas 20 and 30 are expected to double in size, and link flaps inside those areas must not impact the backbone. Therefore, the design should keep internal area routers at Level 1 and use only the boundary devices that connect those areas to the backbone as L1/L2. Option A matches that principle by selecting the appropriate boundary routers for interlevel connectivity while avoiding unnecessary L1/L2 adjacencies throughout the topology. The other options either place the wrong routers in Level 2 only or fail to provide a clean transition between local areas and the backbone. Reference topics: IS-IS hierarchy, L1/L2 boundary design, area containment, backbone stability, route leaking.

Single-topology IS-IS with the transition feature is the correct design when IPv6 is being added to an existing IPv4 IS-IS network and both topologies must match exactly. In single-topology mode, IS-IS calculates one topology and uses it for both IPv4 and IPv6, which fits the requirement that the IPv4 and IPv6 paths and router levels remain the same on each interface. Cisco documentation notes that single-topology IS-IS IPv6 requires routers to run the same set of address families for adjacency consistency; during migration, transition support allows the network to operate while IPv6 is introduced gradually. Multi-topology IS-IS is used when IPv4 and IPv6 should be allowed to follow different topologies or when not all routers support the same address families. The question explicitly says the topologies will match exactly, so multi-topology is unnecessary. Single topology without the transition feature is risky during phased migration because routers that do not yet run both address families may fail adjacency checks or create blackholing. Reference topics: IS-IS for IPv6, single-topology IS-IS, transition mode, address-family consistency, IPv6 migration.

Dedicated control-plane nodes are advisable when frequent endpoint roaming across fabric edge nodes is expected. In Cisco SD-Access, the control-plane node maintains the host tracking database and resolves endpoint identifiers to routing locators. When endpoints move between fabric edge nodes, the fabric must update endpoint-to-location mappings quickly and consistently. In smaller deployments, the control-plane function can sometimes be colocated with border nodes, but larger or more mobile environments benefit from dedicated control-plane nodes to improve scale, resilience, and operational separation. The decision is not because Cisco DNA Center is absent; DNA Center is the management and automation platform for SD-Access. It is also not because edge nodes are unable to provide control-plane functionality, since that is not their fabric role. Frequent roaming creates more mapping updates and lookup activity, so dedicated control-plane resources help maintain stable endpoint registration and resolution performance. Reference topics: Cisco SD-Access control-plane node, host tracking database, endpoint mobility, LISP map server, fabric scale.

Nonstop Routing is the correct solution when the upstream router does not understand graceful restart messaging. Cisco NSF and graceful restart depend on helper behavior from neighboring routers. During a supervisor switchover, the restarting device asks neighbors to preserve forwarding and adjacency state while the control plane recovers. If the neighbor does not support or understand the graceful restart signaling, NSF cannot deliver the intended benefit and route recomputation may still occur. NSR is different because it synchronizes routing protocol state between the active and standby supervisor internally, allowing the switch to preserve routing operation during stateful switchover without requiring graceful restart support from the neighbor. Remote LFA FRR protects against data-plane failures by precomputing repair paths, but it does not address supervisor switchover route recomputation. Aggressive IS-IS timers may make failure detection faster, but they increase control-plane churn and do not solve the lack of graceful-restart helper support. Therefore, the Catalyst switch should use NSR for this design. Reference topics: IS-IS high availability, NSR, NSF, graceful restart helper support, stateful switchover.

The EIGRP stub connected option is appropriate when the new circuit is intended to protect reachability to a connected subnet without turning the router into a broad transit point. EIGRP stub routing is used to limit the routes a router advertises to its neighbors and to constrain EIGRP query scope. A stub router can advertise connected routes, summary routes, redistributed routes, or combinations depending on the configured stub option. In this scenario, the new C-to-D circuit protects connectivity to 10.0.4.0/24 during a failure between B and D. Advertising the connected network through the stub behavior gives upstream routers a valid alternate route while still preventing unnecessary transit advertisements. Stub redistributed would be used for routes learned from another routing process, not for directly connected networks. Stub receive-only would prevent the router from advertising any routes, which would not protect reachability. Stub leak-map is used for controlled exceptions and is unnecessary if the required route is a connected subnet. Reference topics: EIGRP stub routing, connected route advertisement, query boundary design, DUAL stability.