Cisco 300-420 - Designing Cisco Enterprise Networks (ENSLD) v1.1

OSPF requires all nonbackbone areas to connect logically to Area 0. In the original design, HQ is Area 0 and the existing branch is Area 1, which is valid because Area 1 has connectivity to the backbone. The newly acquired branch is assigned Area 2 but is temporarily connected through the existing branch instead of directly to HQ. That means Area 2 does not have a direct logical connection to Area 0, violating the OSPF backbone requirement. The proper OSPF design mechanism for this temporary topology is a virtual link. An OSPF virtual link is configured through a transit area to logically connect a disconnected area or ABR back to the backbone. Making the existing branch a stub area does not solve the lack of Area 0 connectivity. A sham link is used in MPLS VPN OSPF designs to prefer backdoor links or preserve intra-area behavior across the provider core, not for this generic backbone disconnection. Making Area 2 a stub area also does not establish backbone reachability. Therefore, a virtual link between the new branch and HQ is required.

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.

The standards-based mechanism for dynamic rendezvous point distribution in a large PIM domain is Bootstrap Router. BSR allows candidate RPs and candidate BSRs to participate in a standards-based election and advertisement process so PIM routers can learn the RP set dynamically. This avoids configuring every router manually with static RP information and avoids depending on a Cisco-proprietary mechanism. Auto-RP can also distribute RP information dynamically, but Auto-RP is Cisco proprietary and therefore does not meet the nonproprietary requirement. Embedded RP is associated with IPv6 multicast group addressing and is not the general-purpose answer for automating RP discovery in a large IPv4 PIM domain. Static RP configuration is simple and deterministic, but it does not automate RP distribution and becomes operationally fragile as the multicast domain grows. In Cisco multicast design, BSR is the correct choice when the network requires dynamic RP discovery, vendor-neutral behavior, and scalable PIM-SM operation across a large domain.

For a standards-driven YANG model in a multivendor environment, the engineer should choose IETF models. IETF YANG models are produced through the Internet Engineering Task Force standards process and define vendor-neutral data structures for common network functions. This makes them the best answer when the requirement emphasizes standards-based operation across multiple vendors. OpenConfig models are also vendor-neutral and widely used for operational consistency, but OpenConfig is an operator-driven model set rather than an IETF standards body output. Cisco native models expose platform-specific Cisco IOS XE, NX-OS, or IOS XR features and often provide the most complete coverage for Cisco-specific capabilities, but they are not intended as the primary multivendor standard model. IEEE NETCONF is not the correct model category; NETCONF is a protocol, and IEEE is not the YANG model set normally selected for general device configuration in this context. In Cisco automation design, the model choice should match the use case: IETF for standards-driven multivendor workflows, OpenConfig for operator-neutral abstractions, and native models for vendor-specific feature completeness.

Easy Virtual Network is the best fit when a campus needs many Layer 3 virtual networks with separate addressing and routing tables but wants lower operational overhead than manually configuring VRF-Lite everywhere. EVN builds on VRF concepts and simplifies virtualization across a hop-by-hop campus design by reducing repetitive configuration and enabling consistent virtual network transport across participating devices. Each virtual network maintains its own routing context, which supports overlapping addressing and segmentation. Hop-by-hop VRF-Lite can provide similar forwarding separation, but it becomes operationally heavy as the number of VRFs grows because each trunk, routing process, and interface association must be configured and maintained manually. Multihop MPLS can scale, but it introduces provider-style complexity and may require features or skills beyond a typical campus requirement. Multihop IPsec tunneling is not an efficient campus segmentation solution for hundreds of virtual networks. Therefore, EVN is the recommended design for scalable Layer 3 virtualization with simpler configuration and management. Reference topics: campus virtualization, Easy Virtual Network, VRF separation, scalable virtual networks, route isolation.

The IPv4-compatible method is the closest match when the exhibit requires IPv6 connectivity between servers across an IPv4 portion of the network without using 6to4, 6rd, or ISATAP. IPv4-compatible IPv6 addressing represents an IPv4 address inside an IPv6 address format and was historically used for automatic IPv6-over-IPv4 tunneling between dual-stack nodes. Although this technique is now considered legacy and is not preferred for new designs, it matches the answer choice that directly embeds IPv4 reachability for host-to-host connectivity. ISATAP is normally used inside an enterprise IPv4 network to connect IPv6 hosts over an IPv4 intranet. 6to4 and 6rd are provider or site transition mechanisms that use specific IPv6 prefix behavior and are not simply a direct method between the depicted mail servers. For modern Cisco design, dual-stack or manually engineered tunnels would normally be preferred, but given these choices, IPv4-compatible addressing is the method aligned to the exhibit requirement. Reference topics: IPv6 transition mechanisms, IPv4-compatible addressing, tunneling, dual-stack migration, host connectivity.

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.

The requirements point to a Layer 2 multipoint WAN service. VPLS provides an emulated Ethernet LAN across a provider network, allowing multiple sites to appear as if they are connected to the same Layer 2 domain. This supports full-mesh Layer 2 connectivity and preserves customer control over higher-layer services such as IPv6, multicast, routing protocols, and QoS markings. Because the provider delivers an Ethernet multipoint service, the enterprise can retain protocol independence rather than depending on the service provider to participate in IPv6 routing or multicast routing. CoS marking is also a Layer 2 QoS mechanism, so a Layer 2 VPN service is better aligned to the stated QoS requirement. VPWS is point-to-point rather than full-mesh multipoint, so it does not meet the topology requirement by itself. MPLS Layer 3 VPN is a provider-routed service and does not give the customer full Layer 2 mesh behavior. DMVPN is an overlay routed VPN and does not provide a native Layer 2 full-mesh service. Therefore, VPLS is the correct WAN connectivity option.

Wake on LAN commonly relies on a magic packet that must reach a sleeping endpoint on its local subnet. When the WoL server is in a different subnet from the sleeping clients, a unicast packet cannot always be delivered directly because the sleeping host may not have an active ARP entry or IP stack behavior suitable for normal unicast forwarding. Cisco campus designs therefore use IP directed broadcast on the Layer 3 interface for the target VLAN or subnet so a routed packet can be delivered to the subnet and then converted into a Layer 2 broadcast. This must be implemented carefully, with access control, because directed broadcasts can be abused if left unrestricted. Dynamic ARP Inspection and DHCP snooping are Layer 2 security controls; they do not provide the Layer 3 directed broadcast function required for WoL. Proxy ARP allows a router to answer ARP requests on behalf of another host, but it does not solve cross-subnet delivery of WoL magic packets. Therefore, the design must include directed broadcasts on the relevant Layer 3 devices.

The main purpose of the Cisco SD-Access overlay design is to enable the virtualized fabric services that run over the physical underlay. Cisco describes the overlay as the logical network created on top of the routed underlay, using virtual networks to provide segmentation and policy separation. SD-Access uses LISP for endpoint-to-location mapping and VXLAN for data-plane encapsulation, allowing Layer 2 and Layer 3 services to be delivered across a stable Layer 3 transport. Option C is the best available answer because the overlay exists to integrate and carry SD-Access services such as virtual networks, endpoint mobility, macrosegmentation, and security group policy. Simplified troubleshooting and visibility are management and assurance outcomes, not the overlay’s main technical purpose. High availability depends on the underlay topology, node redundancy, and control-plane design, but it is not the primary definition of overlay design. Reference topics: SD-Access overlay, virtual networks, LISP, VXLAN, segmentation, fabric services.