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

The SD-Access control-plane node performs the LISP Map-Server and Map-Resolver functions. Cisco SD-Access uses LISP in the control plane to maintain mappings between endpoint identifiers and routing locators. Fabric edge nodes discover local endpoints and register them with the control-plane node. When a destination endpoint is not known locally, a fabric node queries the control-plane node, which resolves the endpoint location and returns the locator information needed for VXLAN forwarding through the fabric. This is why the control-plane node is the correct answer. A fabric edge node connects endpoints, provides the anycast gateway, encapsulates and decapsulates user traffic, and registers endpoints. A border node connects the fabric to external networks. An intermediate node simply transports routed underlay traffic between fabric nodes and does not hold endpoint mappings. In design terms, control-plane placement and redundancy are critical because endpoint mobility, fabric forwarding lookup, and location resolution depend on stable Map-Server and Map-Resolver services. Reference topics: Cisco SD-Access control plane, LISP Map-Server, LISP Map-Resolver, EID-to-RLOC mapping, fabric edge registration.

The correct action is to configure EIGRP stub behavior on R4. The DUAL-3-SIA message indicates a Stuck-in-Active condition, which occurs when EIGRP sends a query and does not receive a reply within the expected time. Cisco explains that EIGRP stub routing is used to improve stability and reduce resource usage by preventing unnecessary queries from being sent to remote or edge routers. In the described topology, R4 is connected over a limited 10 Mbps inter-router link and should not be treated as a transit router for the rest of the routing domain. Making R4 an EIGRP stub limits the query scope and reduces the chance of active routes waiting on a slow or constrained neighbor. Poison reverse and split-horizon changes address loop prevention and hub-and-spoke update behavior, but they do not directly solve the SIA instability. A summary on R2 may help scaling but does not identify the edge-router query boundary as precisely as EIGRP stub. Reference topics: EIGRP DUAL, Stuck-in-Active, EIGRP stub routing, query scoping, WAN edge stability.

Ethernet Local Management Interface is used between the customer edge and provider edge to communicate service status information for Ethernet services. Under MEF Ethernet service operations, E-LMI provides the CE with information about Ethernet Virtual Connection status, including whether a configured EVC is available or unavailable. This allows the customer device to react to a provider-side service condition without relying only on physical link state. The CE-to-PE link can remain physically up even while the provider EVC is down; E-LMI closes that operational visibility gap by reporting the EVC state to the customer edge. It is not a routing protocol and does not broadcast multicast routes from the CE to the PE. It also does not broadcast to all subnets when an EVC is added. The key function defined by the MEF process is notifying the CE of EVC availability state and related service information. Reference topics: Metro Ethernet, E-LMI, Ethernet Virtual Connection, CE-to-PE signaling, MEF service operations.

Rapid PVST+ and VTP address the stated redesign goals. Moving from IEEE 802.1D STP to Rapid PVST+ reduces the impact of topology changes because rapid spanning tree provides faster convergence through proposal/agreement behavior and faster port-role transitions. That improves availability compared with classic STP timers. VTP reduces administrative effort and manual configuration errors by centrally propagating VLAN information across switches in the same VTP domain. It can also support pruning so unused VLAN traffic is not unnecessarily carried across trunks. MST could reduce spanning-tree instance count, but the question emphasizes reducing topology-change impact and reducing manual VLAN configuration work; Rapid PVST+ plus VTP addresses both directly. Storm control helps limit broadcast and multicast traffic but does not solve STP convergence or VLAN administration. Dynamic Trunking Protocol negotiates trunk state; it does not propagate VLAN information and is often avoided in deterministic campus designs. In production, VTP should be used carefully with version control, domain/password discipline, and change governance because incorrect VTP configuration can have broad impact. Reference topics: Rapid PVST+, STP convergence, VTP, VLAN pruning, campus Layer 2 operations.

The BGP maximum-paths feature should be included when the design goal is to install multiple eligible BGP paths in the routing table and use them for load sharing. By default, BGP selects a single best path after comparing attributes such as weight, local preference, AS path, origin, MED, eBGP over iBGP, IGP metric to next hop, and other tie breakers. If two links between autonomous systems should both carry traffic, the router must be allowed to retain more than one equal or eligible path for forwarding. The maximum-paths command enables BGP multipath installation so the data plane can load share across the available links. Update-source is used to source a BGP session from a loopback or specific interface, not to perform load sharing. Next-hop-self influences recursive reachability and next-hop handling but does not install multiple paths by itself. eBGP multihop changes TTL behavior for non-directly connected eBGP neighbors and is unrelated to load sharing over the two links. Reference topics: BGP multipath, maximum-paths, eBGP load sharing, BGP path selection, route installation.

NETCONF supports event notifications through a subscription model. The operation used to establish a notification subscription is create-subscription. When a client sends this operation, it can specify the stream and optional filters that determine which notifications are delivered to that NETCONF session. This is why create-subscription is the operation associated with session-specific notification filtering. The commit operation is used with the candidate configuration datastore to apply configuration changes to the running datastore; it does not create a telemetry or event subscription. The notification element is the message sent by the server after a subscription exists, not the operation used to create one. Logging is not a NETCONF operation in the protocol operation set. In Cisco model-driven management designs, NETCONF provides structured configuration and operational access using YANG data models, while notifications allow the management station to consume specific events without relying on repeated screen scraping or broad polling. Therefore, the correct operation for creating filtering specific to session notifications is create-subscription.

Running BFD between EIGRP neighbors is the appropriate design when the problem is traffic loss during link failure and the requirement is to reduce the impact of the failure. EIGRP can detect neighbor loss through its hello and hold timers, but those timers may not be fast enough for applications sensitive to packet loss. Bidirectional Forwarding Detection provides rapid failure detection independent of the routing protocol’s normal timer expiration. When BFD detects a failed forwarding path, it notifies EIGRP so the routing process can converge without waiting for the EIGRP hold timer. Summarization is still a valuable scaling technique, but it primarily reduces route table size and query scope; it does not directly accelerate failure detection on an individual inter-router link. Reducing EIGRP hello and hold timers can improve detection, but it increases control-plane load and is less efficient than BFD. The question emphasizes data loss when any one link fails, so fast failure detection is the best corrective design. Reference topics: EIGRP convergence, BFD, failure detection, hello and hold timers, routed-link resiliency.

The drag-and-drop mapping identifies which elements belong to each model-driven protocol or data-modeling mechanism. Cisco programmability designs distinguish the data model, the encoding, and the transport protocol. YANG defines the structure of configuration and operational data. NETCONF commonly uses XML encoding and provides transactional operations such as get-config, edit-config, lock, and commit-like workflow depending on platform support. RESTCONF exposes YANG-modeled data through HTTP methods and typically uses URI-based resources with XML or JSON encoding. gRPC and gNMI are commonly used for efficient telemetry or operational data streaming, with protocol buffers often used for serialization. The selected mapping follows those protocol boundaries rather than mixing model structure with transport behavior. In design work, this matters because the same network feature can be represented by a YANG model but accessed through different protocols, each with different capabilities, security requirements, and operational semantics. Correctly matching elements to protocols avoids invalid payloads and broken automation workflows. Reference topics: YANG, NETCONF, RESTCONF, gRPC, gNMI, XML and JSON encoding, model-driven telemetry.

The correct answer is bidirectional PIM. Cisco describes bidirectional PIM as a multicast mode designed for many-to-many applications where traffic is forwarded only along a shared tree rooted at the rendezvous point. Unlike traditional PIM Sparse Mode, BIDIR-PIM does not build source-specific shortest-path trees for each active source. That design reduces multicast state in the network because routers maintain group state rather than separate source and group state for every sender. PIM Sparse Mode initially uses a shared tree through the RP, but it can switch to source trees after receivers and routers learn the active source. Dense mode floods and prunes and is not a shared-tree-only model. Source-specific multicast explicitly uses source-specific joins and does not use an RP-based shared tree. The wording “shared tree only” is the key distinction: BIDIR-PIM is built for scalable many-to-many multicast, accepts some non-shortest-path forwarding tradeoff, and avoids per-source state growth. Therefore, the stored answer must be corrected to bidirectional. Reference topics: BIDIR-PIM, shared trees, rendezvous points, many-to-many multicast scaling, PIM-SM source-tree behavior.