Free Practice Questions for Cisco 300-420 Exam

The IPv4 network 172.16.10.0/24 maps to 2001:db8:abcd::ac10:a00/120 when the IPv4 address is placed into the lowest significant bits of the IPv6 address. The calculation converts each IPv4 octet into hexadecimal: 172 is AC, 16 is 10, 10 is 0A, and 0 is 00. Combining those bytes gives AC10:0A00, displayed in IPv6 notation as ac10:a00. Because a /24 IPv4 network has 8 host bits, the mapped IPv6 network leaves the same 8 host bits, resulting in a /120 IPv6 prefix. Option B incorrectly places decimal IPv4 octets into separate IPv6 hextets and uses /96, which represents a much larger mapping block than the /24 network. Option C does not represent 172.16.10.0 in hexadecimal. Option D changes the higher-order IPv6 prefix and does not match the supplied address plan. The correct address therefore preserves the planned IPv6 prefix and embeds the IPv4 network in the low-order bits. Reference topics: IPv4-to-IPv6 address mapping, hexadecimal conversion, IPv6 prefix length, migration addressing plans.

The correct EIGRP design consideration is to prevent unnecessary neighborships from forming across switch virtual interfaces. In a data center or campus switching environment, many SVIs may exist for VLAN default gateways, but those VLANs do not necessarily need EIGRP adjacencies with attached hosts, firewalls, load balancers, or peer switches. Cisco EIGRP design commonly uses passive-interface behavior to advertise connected networks while suppressing EIGRP hello packets on interfaces where neighbor relationships are not required. This reduces control-plane noise, minimizes accidental adjacencies, and limits the failure domain. Manual summarization is useful at hierarchy boundaries, but performing summarization on all Layer 3 interfaces can create black holes or hide topology detail where it is still needed. Lowering hello and hold timers to minimum values can increase CPU load and is not the primary design recommendation. Multiple EIGRP autonomous systems may be used for specific segmentation designs, but they add redistribution and operational complexity. Therefore, preventing unnecessary EIGRP neighborships across SVIs is the best design practice from the choices.

Reverse Path Forwarding prevents multicast loops and duplicate packet forwarding. Multicast routing is source-oriented, so a router must verify that multicast traffic arrives on the interface it would use to reach the source or rendezvous point, depending on the tree state. If the packet arrives on the expected reverse-path interface, the RPF check succeeds and the router can forward the packet to the outgoing interface list. If it arrives on the wrong interface, the packet is dropped because accepting it could create a loop or duplicate stream. Cisco multicast designs rely on RPF checks with PIM to maintain loop-free distribution trees across redundant routed topologies. RPF does not notify upstream routers by itself, does not eliminate overlapping multicast group addresses, and is not simply a prune-generation mechanism. Prune behavior can occur as part of PIM tree maintenance, but the function asked here is loop prevention. Reference topics: multicast RPF check, PIM forwarding, source tree, shared tree, outgoing interface list, duplicate suppression.

If the RPF check is successful in PIM sparse mode, the multicast packet is forwarded according to the outgoing interface list. The Reverse Path Forwarding check verifies that the packet arrived on the interface the router would use to reach the source, or the RP in the case of shared-tree state. This prevents loops and duplicate multicast forwarding. After the check passes, the router consults the multicast forwarding entry and sends the packet only out interfaces in the OIL where downstream receivers or PIM neighbors require the traffic. It is not automatically forwarded out every PIM-enabled interface, and it is not forwarded back out the receiving interface. If the RPF check fails, the packet is dropped to protect the multicast distribution tree. The OIL therefore represents the correct controlled forwarding behavior after a successful RPF validation. Reference topics: PIM sparse mode, RPF check, outgoing interface list, multicast forwarding state, loop prevention.

For streaming multimedia over a WAN using DiffServ per-hop behavior, the best answer is CBWFQ with DSCP AF3. Cisco QoS design separates real-time interactive voice from streaming multimedia. Voice bearer traffic commonly uses EF and a strict priority queue because it is extremely sensitive to delay and jitter. Streaming multimedia, however, is usually buffered and bandwidth-intensive; it should receive assured bandwidth and controlled drop behavior rather than strict priority treatment. The Assured Forwarding classes are designed for this kind of preferential forwarding within DiffServ. AF3 is commonly associated with multimedia streaming in Cisco QoS baseline models, while CBWFQ provides bandwidth guarantees without allowing the class to starve other traffic. LLQ with EF is too aggressive for streaming multimedia and should be reserved for voice bearer traffic or similarly strict real-time flows. AF2 is more commonly used for transactional data or lower-priority assured service, depending on the model. The correct marking and queuing design is therefore CBWFQ with DSCP AF3. Reference topics: DiffServ, per-hop behavior, CBWFQ, DSCP AF classes, multimedia streaming QoS.

DiffServ is the correct scalable QoS architecture for classifying traffic according to business requirements and using DSCP values as the priority descriptor. Cisco QoS design distinguishes DiffServ from IntServ. IntServ uses per-flow signaling with RSVP and can reserve resources, but that model is not operationally scalable across large enterprise networks. DiffServ is class-based. Traffic is classified and marked at the network edge, then each device applies per-hop behavior to those classes using local QoS policy. DSCP provides a six-bit field in the IP header, which supports more than ten classification values and allows standardized treatment classes such as EF, AF, class selector, and default. Best effort provides no differentiated treatment, and RSVP is a signaling mechanism associated with IntServ rather than the requested scalable class-based architecture. “Interserv” is not the correct Cisco QoS model term. Therefore, the engineer should design around DiffServ, with a clear trust boundary, marking policy, queuing model, and consistent treatment across WAN and campus boundaries. Reference topics: DiffServ, DSCP, per-hop behavior, class-based QoS, scalable QoS architecture.

Stateful NAT64 is the correct design because IPv6-only hosts must communicate with legacy IPv4 devices and only a small pool of IPv4 addresses is available for concurrent sessions. NAT64 translates IPv6 client traffic into IPv4 traffic, allowing IPv6-only endpoints to reach IPv4-only resources. A stateful implementation maintains translation state and can use a pool of IPv4 addresses for multiple IPv6 clients, which fits the requirement for up to 10 concurrent IPv6 hosts using 10 reserved IPv4 addresses. Static NAT- PT would require fixed one-to-one mappings and is less suitable for a pool-based concurrent access model. NAT66 translates between IPv6 prefixes and does not solve access to IPv4-only devices. Dynamic NAT-PT is an older transition mechanism and is not the preferred modern answer when NAT64 is available. The design should also include DNS64 when clients access IPv4-only services by name. Reference topics: IPv6 transition, stateful NAT64, DNS64, IPv6-only hosts, IPv4 legacy reachability.

The load balancers should be co-located in area 0 because the design is using the same /32 application address from multiple OSPF-enabled devices. This is an anycast-style design: several load balancers advertise the same host route, and the routing protocol sends clients to the topologically best available instance. In OSPF, route preference is strongly affected by route type. Intra-area routes are preferred over interarea routes, and interarea summarization can also hide useful path details. If identical anycast host routes are originated from different nonbackbone areas, hosts may not always select the closest or most resilient load balancer, and failure behavior can become inconsistent. Placing the load-balancer anycast advertisements in area 0 keeps the routing decision consistent and avoids unnecessary interarea preference complications. Configuring X, Y, and Z as different areas would make the problem worse, and placing only one load balancer in area 0 does not provide uniform resilience. Reference topics: OSPF area design, anycast host routes, intra-area preference, backbone area, application load-balancer resilience.

The required resource is the organization name. During manual WAN Edge onboarding, the device needs local system identity information and transport reachability so it can authenticate into the Cisco Catalyst SD-WAN overlay. Cisco onboarding workflows identify system parameters such as system IP, site ID, organization name, and vBond information as required configuration elements. The organization name must match the value configured across the SD-WAN controllers; otherwise, certificate validation and control connection establishment fail. After the WAN Edge authenticates with vBond, vBond helps it discover the vSmart controllers and vManage. That is why the vSmart hostname is not the first required onboarding resource in this question. NAT may exist in the path and vBond can assist traversal, but NAT itself is not the configuration identity item. A generic domain name is not the same as the SD-WAN organization name. Reference topics: Cisco SD-WAN onboarding, vBond orchestrator, organization-name, control connections, WAN Edge manual configuration.

The primary advantage of an out-of-band management network is that devices remain reachable for administration even when the production data network is impaired or unavailable. In an out-of-band design, management access uses a separate physical or logical path, often through dedicated management interfaces, console servers, terminal servers, or isolated management switches. This separation is valuable during routing failures, control-plane problems, misconfigurations, or security incidents affecting the production network. It also improves security because access control, authentication, logging, and monitoring can be concentrated on a management plane that is not directly exposed to ordinary user traffic. The statement that there is no separation from production traffic describes in-band management, not out-of-band management. An out-of-band network should not be treated as a general backup data path for production applications because that would defeat the isolation goal. It is also not necessarily less expensive; dedicated circuits, management switches, console servers, and operational processes can increase cost. Therefore, the correct benefit is continued manageability during a production network outage.