300-420 Designing Cisco Enterprise Networks (ENSLD) Questions and Answers

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.

Gateway Load Balancing Protocol is the first-hop redundancy protocol that provides load balancing while presenting a single default gateway IP address to hosts. Cisco’s GLBP documentation states that GLBP “provides load balancing over multiple routers using a single virtual IP address and multiple virtual MAC addresses.” That wording directly matches the requirement in the question. In a GLBP group, the active virtual gateway answers ARP requests for the virtual IP address and can return different virtual MAC addresses associated with active virtual forwarders. As a result, multiple routers forward traffic for the same subnet rather than leaving one router idle during normal operation. HSRP and VRRP provide first-hop redundancy, but their basic operation uses one active or master forwarding device for a virtual IP at a time unless multiple groups are manually engineered per VLAN. IRDP is not the Cisco campus FHRP used for this design. Therefore, when the requirement is automatic load balancing across multiple routers using one virtual IP and multiple virtual MAC addresses, GLBP is the correct protocol.

BGP outbound route filtering is the correct solution because the enterprise wants control over which routes it receives without waiting for a provider change cycle each time the prefix set changes. Cisco BGP prefix-based ORF allows a receiving BGP speaker to send an inbound prefix-list filter to the remote peer, which then applies that list as an outbound filter. This reduces unwanted routing updates before they cross the session and lets the enterprise update the desired prefixes locally when business requirements change. Requesting only fixed prefixes from the ISP would work initially but fails the flexibility requirement because the provider has a two-week change process. Requesting a full table and filtering inbound would provide flexibility but wastes memory and CPU on the customer router because all routes are still received before filtering. A maximum-prefix limit does not select the correct routes. ORF is therefore the scalable operational design for receiving a default route and selected prefixes with minimal provider involvement. Reference topics: BGP ORF, prefix-based filtering, inbound route control, ISP peering design, routing table scale.

Internal border and anywhere border are valid Cisco SD-Access border node types. A border node connects the SD-Access fabric to networks outside the fabric, but different border roles are used depending on what external reachability is required. An internal border provides connectivity to known internal networks such as shared services, data center prefixes, or enterprise routes that should be reachable from inside the fabric. An anywhere border combines external and internal border behavior and can provide broader exit capabilities depending on the fabric design. The commonly described border roles also include external border, which provides default or Internet-facing exit from the fabric, but that option is not available in the listed choices. “Extended border,” “edge border,” and “intermediate border” are not the correct named border node types. The answer is therefore internal border and anywhere border. Border placement is a major design decision because it influences route advertisement, VN-to-VRF mapping, external connectivity, transit behavior, and failure-domain boundaries for SD-Access fabrics.

Dual-stack is the correct IPv6 migration strategy for this corporation. The requirements state that users need access to both IPv4 and IPv6 resources, content providers will migrate over the next two years, and users will move in phases. Dual-stack supports exactly that model because hosts, routers, and services can run IPv4 and IPv6 simultaneously. Applications can select IPv6 or IPv4 based on DNS responses and protocol availability, while the organization gradually enables IPv6 without breaking existing IPv4 connectivity. NAT64 is useful for IPv6-only clients reaching IPv4-only services, but it introduces translation state and does not provide native dual protocol operation. NAT46 is a specialized translation direction and not the broad migration strategy here. Tunneling can connect IPv6 islands across IPv4 infrastructure, but the customer already has IPv4 peering and needs a phased endpoint and application migration, not only island interconnection. Dual-stack is straightforward operationally and gives the longest coexistence window while providers and applications transition. Reference topics: IPv6 migration, dual-stack deployment, DNS-based protocol selection, IPv4 and IPv6 coexistence, phased migration.

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.

The route-reflector design should make R2 a client of R1 and R4, and R5 a client of R3 and R4. The requirement states that the route reflector must have direct physical connections to the core routers R3 and R4, must avoid a single point of failure, and must account for high utilization on the R2-to-R1 link. In BGP route-reflector design, clients peer with redundant route reflectors so they can continue receiving reflected routes if one route reflector or path fails. Placing R5 as a client of R3 and R4 satisfies the direct-core requirement and provides redundant reflection through the core. Placing R2 as a client of R1 and R4 provides redundancy while reducing dependence on the heavily utilized R2-to-R1 link by including R4 as an alternate reflector. Making a router a client of two reflectors is a standard design technique for route-reflector high availability. The other combinations either fail the direct-core requirement, do not provide balanced redundancy, or keep traffic tied to the congested link. Reference topics: BGP route reflectors, client redundancy, iBGP scaling, route-reflector placement, core resiliency.

The SD-Access control-plane node maintains the endpoint database and resolves mappings between endpoints and the fabric edge nodes where those endpoints are located. Cisco SD-Access uses LISP in the fabric control plane. Edge nodes register endpoint identifiers with the control-plane node, and other fabric nodes query the control plane when they need to locate a destination endpoint. This control-plane function is commonly described through LISP Map-Server and Map-Resolver behavior. Option B is not correct because endpoint detection occurs at the edge node, not at the control-plane node. The edge is the device connected to users, access points, or endpoint-facing networks, so it learns local endpoint presence and registers that information. Option C refers to authentication and identity, which is integrated with Cisco ISE. Option D describes the border-node role, because border nodes connect the fabric to external networks. The corrected answer is therefore A. A stable SD-Access design must provide redundant control-plane reachability and scale the control-plane role according to fabric size, mobility, and endpoint churn. Reference topics: SD-Access control plane, LISP Map-Server, LISP Map-Resolver, endpoint-to-location mapping.

VRRPv3 improves protocol applicability by supporting both IPv4 and IPv6 address families. VRRPv2 is associated with IPv4 virtual router redundancy, while VRRPv3 extends the protocol so the same first-hop redundancy concept can be used for IPv6 default gateways as well. In campus and branch designs, this matters because IPv6 deployments should not require a separate redundancy design from IPv4 when a standards-based FHRP is preferred. Preemption is not a unique VRRPv3 advantage because VRRP has long supported priority-based master election and preemption behavior. Authentication is also not the correct differentiator in this comparison; VRRPv3 removed the simple protocol authentication field from the base protocol and expects security to be provided by the underlying network or IPsec where required. Stateful switchover is a platform high-availability capability, not a VRRPv3 protocol feature. Therefore, the key benefit of VRRPv3 over VRRPv2 for enterprise design is IPv4 and IPv6 support under the same redundancy protocol model.

For multimedia conferencing over MPLS, Cisco QoS design normally classifies the traffic into the multimedia conferencing class and marks it with AF4, commonly AF41. This class is intended for interactive video conferencing and similar applications that need assured bandwidth and controlled loss, but that are not usually placed in the same strict-priority class as voice bearer traffic. A bandwidth queue provides a minimum bandwidth guarantee during congestion, while DSCP-based WRED can selectively manage congestion within the class by using the drop precedence encoded in the AF marking. AF3 is generally associated with multimedia streaming, not interactive conferencing. A simple bandwidth queue without WRED does not fully use per-hop behavior characteristics for congestion handling. LLQ is typically reserved for voice and sometimes very tightly controlled real-time classes, because overusing strict priority can starve other traffic. Therefore, bandwidth queuing with DSCP WRED using AF4 is the appropriate per-hop behavior design. Reference topics: Cisco QoS baseline, DiffServ, AF41, multimedia conferencing, MPLS QoS, WRED.

A TLOC extension facilitates WAN Edge router redundancy within a site. In Cisco SD-WAN, a Transport Location identifies a WAN transport attachment using attributes such as system IP, color, and encapsulation. A TLOC extension allows one WAN Edge router to use a transport circuit physically connected to another WAN Edge router at the same site. This is valuable when a branch has two edge routers and two transports, but each transport is cabled to only one router. With TLOC extension, each router can still gain logical access to both transports, improving redundancy and allowing better path diversity without adding more service-provider circuits or handoffs. The feature does not simply identify the physical interface; that is part of TLOC definition. It does not increase the number of colors or create a port-channel-style aggregate. A sound design also accounts for failure domains, service-side routing, and whether the inter-router link has enough bandwidth for extended transport traffic. Reference topics: Cisco SD-WAN TLOC, TLOC extension, WAN Edge redundancy, transport color, branch resiliency.

Virtual networks in Cisco SD-Access provide macro segmentation. Macro segmentation separates major user, device, or service groups into distinct virtual networks, each with its own routing and forwarding context. This is comparable to VRF-based separation in traditional enterprise designs. For example, corporate users, guests, building systems, and IoT devices can be placed into separate virtual networks so their routing domains remain isolated unless controlled inter-VN communication is explicitly provided. Microsegmentation is different; it is normally enforced inside or across virtual networks using Security Group Tags and Security Group ACLs, allowing policy decisions based on group identity rather than only IP subnets or VLANs. Inter-VN describes communication between virtual networks, not the segmentation type itself. Stretched segmentation is not the standard SD-Access term. Therefore, the separation created by virtual networks is macro segmentation, while SGT-based policy provides finer-grained microsegmentation. Reference topics: Cisco SD-Access virtual networks, macro segmentation, VRF, SGT, microsegmentation, policy enforcement.

NETCONF supports XML, while RESTCONF supports both XML and JSON. Cisco programmability documentation describes NETCONF as an XML-based protocol that exchanges RPC requests and replies such as get, get-config, and edit-config using XML encoding. NETCONF is tightly aligned with YANG-modeled data, but the protocol message format itself is XML. RESTCONF exposes YANG-modeled data through an HTTP or HTTPS API and can represent payloads in XML or JSON. Cisco DevNet material commonly summarizes the comparison as NETCONF equals XML, while RESTCONF equals XML or JSON. That is why option D is accurate. Option A is wrong because NETCONF does not use JSON in the same way RESTCONF does. Option B is incomplete because RESTCONF is not limited to JSON. Option C reverses the protocol encodings. This distinction matters in automation design because tool selection, content type, parsing, and API workflows differ by protocol. Reference topics: NETCONF, RESTCONF, YANG, XML encoding, JSON encoding, model-driven programmability.

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.

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.

Dual stack is the correct IPv4 and IPv6 deployment strategy when the customer wants a straightforward design with no information hiding and no tunnel forwarding overhead. In a dual-stack deployment, routers, switches, servers, and clients run IPv4 and IPv6 simultaneously. Applications can select IPv4 or IPv6, typically based on DNS response and protocol availability, while the network forwards each protocol natively. This avoids the translation behavior of NAT64, where address information is hidden or converted between protocols. It also avoids GRE or other tunneling mechanisms, which add encapsulation overhead and operational complexity. LISP can provide location/identity separation and mobility, but it is not the simplest migration approach for native IPv4 and IPv6 coexistence. Dual stack is often the cleanest transition model when the infrastructure supports both protocols, because it permits gradual application migration without forcing all services through translators or tunnels. Reference topics: IPv6 migration, dual-stack deployment, NAT64, tunneling overhead, native IPv4 and IPv6 forwarding.

In-band management is the correct design because the management plan must reach all IP-enabled interfaces, and not every device has a dedicated management port. In-band management uses the production IP network for administrative access, allowing management stations to reach loopbacks, SVIs, routed interfaces, or front-panel interfaces through normal routing. Cisco management guidance distinguishes in-band management from out-of-band designs that depend on a separate physical management network or console path. Because the question requires reachability to all IP-enabled interfaces, in-band is the only listed model that naturally supports that scope. Security must still be enforced with encrypted protocols where supported, such as SSH and HTTPS, plus ACLs, AAA, and management-plane protection where appropriate. A terminal server provides console access, not routed IP management to every interface. A KVM server is a server-management tool, not a network-device management architecture. Out-of-band management is preferred for isolation, but it does not fit devices without dedicated management access. Reference topics: in-band management, secure management protocols, SSH, HTTPS, network management design.

Both WAN routers should run OSPFv2. The requirement explicitly says that the routing protocol must be open standard, provide high availability, and offer fast convergence. OSPF is an open-standard link-state routing protocol and is broadly supported across vendors. It builds a link-state database, calculates best paths with SPF, supports equal-cost multipath, and can be tuned with BFD, SPF throttling, LSA throttling, and hierarchical areas for resilient enterprise WAN designs. EIGRP is fast and operationally efficient in Cisco-only environments, but it is not the best answer when the requirement emphasizes an open-standard routing protocol. Running OSPFv2 on one router and OSPFv3 on another is invalid for a single IPv4 routing design because they would not form the intended common routing domain. Mixing IS-IS and OSPFv3 also fails the requirement for a unified design between the redundant routers. Therefore, both routers should run OSPFv2. Reference topics: OSPFv2, open-standard routing, WAN routing high availability, link-state convergence, ECMP and BFD integration.

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.

Area 1 should be configured as an NSSA when the design must allow selected external routes, such as EIGRP-originated routes, while controlling other external routes such as those from the RIP domain. A normal OSPF area receives Type 5 external LSAs, so it would not inherently block the unwanted RIP-originated external routes. A stub area blocks Type 5 external LSAs, but it also cannot contain an ASBR that injects external routes in the normal way. An NSSA is designed for this exact middle ground: it restricts external LSAs from the backbone while allowing external routes to be injected inside the area as Type 7 LSAs, which are translated by the ABR when needed. This allows Area 1 to receive the necessary internal and selected redistributed information while excluding external routes originated elsewhere. Making the routers part of area 0 would not solve the external-route filtering requirement and would weaken the intended area structure. Therefore, NSSA provides the required balance of route visibility and external-route control. Reference topics: OSPF NSSA, Type 5 LSAs, Type 7 LSAs, external route control, area design.

The best design is the option that prefers ISP-1 for both outbound and inbound traffic while keeping ISP-2 available as a backup. For outbound traffic from the enterprise, local preference is the correct BGP attribute because it is evaluated inside the local AS and higher local preference wins. R1 should assign a high local preference to routes learned from ISP-1, while R2 should assign a low local preference to routes learned from ISP-2. For inbound traffic from the Internet toward the enterprise, AS-path prepending is the practical signal sent to external networks. Advertising routes to ISP-1 with no prepending and routes to ISP-2 with five prepends makes the ISP-1 path look shorter and therefore more attractive. The R1-to-R2 internal advertisements should not be blocked by NO-ADVERTISE because each edge router must still share reachability internally for failover. Option B matches these controls without unnecessarily suppressing routes between the edge routers. Reference topics: BGP local preference, AS-path prepending, active/backup Internet design, inbound and outbound path control.

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.

Dual-stack is the correct IPv6 migration technique because the DWDM devices provide Layer 2 transport between routers that already support both IPv4 and IPv6. Layer 2 transport is generally transparent to IPv6 because it forwards Ethernet frames rather than participating in Layer 3 routing. The routers at the ends of the DWDM circuit can peer directly over the Layer 2 service and run IPv6 in parallel with IPv4, while mail servers can also retain IPv4 reachability during the migration. Cisco dual-stack migration guidance uses simultaneous IPv4 and IPv6 operation to support phased application and host transition with minimal tunneling overhead. 6to4, ISATAP, and 6rd are tunneling or transition mechanisms used when IPv6 islands must cross IPv4-only routed infrastructure. In this case, the limiting devices are in the transport layer and do not need to route IPv6. Deploying dual-stack on the capable routers and servers is simpler, more transparent, and avoids unnecessary encapsulation. Reference topics: IPv6 dual-stack migration, Layer 2 transparency, IPv6 over Ethernet, tunneling avoidance, phased migration.

LTE is the most appropriate backup WAN option for remote sites that already rely on microwave links. A backup transport should use a different failure domain from the primary service; LTE provides carrier wireless connectivity that is operationally separate from the customer’s microwave infrastructure. It is widely available, fast to deploy, and suitable as an out-of-band or secondary WAN path for branch continuity. WiMAX is an older metropolitan wireless technology and is not the preferred current enterprise backup choice. A laser link is another line-of-sight technology and can suffer from similar environmental and alignment constraints as microwave, so it is a weaker diversity option. Bluetooth is a short-range personal-area technology and is not a viable WAN backup for enterprise branches. LTE also integrates well with SD-WAN, IPsec VPN, and routing-based failover designs. In a resilient WAN architecture, the architect should validate signal quality, carrier coverage, data plan, antenna placement, NAT behavior, and whether the backup link must support dynamic routing, VPN encryption, and QoS for critical traffic during failover.

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.

gRPC provides secure communication between network devices and control systems by supporting TLS. In Cisco programmability and model-driven telemetry designs, gRPC is commonly used as a high-performance remote procedure call framework that carries structured data encoded with Protocol Buffers. Security is provided through TLS so that the client and server can authenticate and protect the session in transit. The question asks for security functionality, so TLS support is the correct selection. The other options describe incorrect or misleading cryptographic behavior. gRPC does not implement generic RSA tunnel encryption as described in option A, and it does not provide mandatory encryption of data at rest. RC6 with CRC is not the security model used for Cisco gRPC telemetry or programmability. In a secure management design, gRPC should be deployed with certificates, TLS verification, controlled access lists, and appropriate AAA integration so only authorized collectors or controllers can communicate with infrastructure devices. Reference topics: gRPC, TLS, model-driven telemetry, Protocol Buffers, secure automation transport.

OpenConfig separates intended configuration from operational state by using separate config and state containers, while many IETF and Cisco native models use a single hierarchy for configuration and operational data or expose operational data differently. This distinction is important in automation because the client must know whether it is writing desired configuration or reading actual device state. OpenConfig’s structure was designed to provide consistent multivendor modeling, with configuration data placed under config containers and observed state under state containers. Cisco native models tend to mirror the Cisco device CLI and feature hierarchy more closely, while IETF models focus on standards-based interoperability. Option B correctly states the contrast presented in the question. Option A reverses the relationship. Option C incorrectly assigns split containers to IETF and native models. Option D incorrectly isolates Cisco native models as the only split-container style. Reference topics: YANG model structure, OpenConfig config and state containers, IETF YANG, Cisco native models, network automation data modeling.

Cisco SD-WAN uses the vSmart controller as the control-plane component that distributes the information needed for secure data-plane tunnel establishment. Before WAN Edge devices build full-mesh IPsec tunnels, they must learn reachability and security information through the SD-WAN control plane. Cisco documentation describes the vSmart controller as the centralized control-plane element that exchanges OMP routes, policy, TLOC information, and security parameters with WAN Edge routers. In the traditional SD-WAN key-exchange model, vSmart sends IPsec encryption keys to edge devices so the data plane can be secured without each edge independently negotiating IKEv2 with every other edge. vManage is the management platform and is not the key exchange point. vBond performs orchestration, authentication assistance, and NAT traversal during onboarding, but it is not the data-plane key server. IKEv2 may be used in specific newer or configured security models, but the typical Cisco SD-WAN overlay relies on vSmart for scalable key distribution. Reference topics: Cisco SD-WAN control plane, vSmart, OMP, IPsec key distribution, WAN Edge security.

MSDP is required because the design connects separate PIM-SM multicast domains and needs multicast source discovery across domain boundaries. In each autonomous system, receivers join a multicast group through the local rendezvous point. Without MSDP, an RP in one domain does not automatically learn about active sources registered to an RP in another domain. MSDP allows RPs to exchange Source-Active information so that receivers in AS65773 can learn about VoD sources in AS5373 and build the required multicast forwarding state. Auto-RP and BSR are mechanisms for discovering or advertising rendezvous point information inside a PIM domain; they do not solve interdomain source discovery between separate multicast domains. PIM SSM can work for source-specific applications, but the question states that R2 has been selected as RP, which indicates an ASM/PIM-SM design. With BGP already established between offices, MSDP complements the interdomain routing design by exchanging multicast source reachability information. Reference topics: MSDP, PIM-SM, interdomain multicast, Source-Active messages, rendezvous point resilience.

Manual underlay is the correct deployment approach for a brownfield SD-Access scenario. In a greenfield fabric, Cisco DNA Center LAN Automation can build the routed underlay by discovering devices, assigning addresses, and creating the required underlay adjacencies. Brownfield environments already have an installed campus network, addressing plan, routing policy, operational constraints, and production dependencies. Rebuilding that underlay automatically can introduce unnecessary disruption. Cisco SD-Access brownfield designs normally preserve and validate the existing routed underlay, then use Cisco DNA Center to discover devices and automate the fabric overlay, policy, and endpoint segmentation functions. Subnet stretching is not the required deployment model and can create operational complexity. Automated underlay and LAN automation are powerful when the physical network is being newly built, but they are not the safest default for an established production environment. A professional brownfield design should first confirm MTU, routing reachability, loopback advertisements, device support, and fabric readiness before onboarding nodes. Reference topics: SD-Access brownfield migration, manual underlay, Cisco DNA Center, LAN Automation, fabric readiness.

Controller redundancy is the only viable answer among the listed choices. In Cisco SD-WAN, production control-plane resiliency is achieved by deploying redundant controller infrastructure so WAN Edge routers can maintain control connectivity even if a controller instance fails. Strictly speaking, vSmart controllers are the primary SD-WAN control-plane components because they distribute OMP routes, TLOC information, service routes, and policy. vManage is the management plane, and clustering vManage improves management-plane availability. However, the provided options do not include redundant vSmart controllers. Of the available answers, using multiple controller instances in a cluster is the closest redundancy design concept, while the other options do not provide SD-WAN controller redundancy. BFD on WAN Edge routers detects data-plane path failure, not control-plane controller failure. Deploying controllers on UCS or CSP affects hosting, not redundancy by itself. OMP manages overlay routes; it is not an underlay management mechanism. A complete professional design should include redundant vSmart, vBond, and vManage components across failure domains. Reference topics: Cisco SD-WAN control plane, controller redundancy, vSmart, vManage clustering, OMP.

BFD is the correct mechanism for sub-second failure detection. The question describes unequal failover behavior when an interface on an ISP router toward the campus fails. In many WAN and Internet edge designs, BGP timers or next-hop tracking may not react fast enough when the physical failure is not directly visible to the customer router. Cisco defines Bidirectional Forwarding Detection as a lightweight protocol that provides rapid forwarding-path failure detection independent of the routing protocol timers. When BFD is associated with BGP, OSPF, EIGRP, or static routing, the routing process receives failure notification quickly and can withdraw or replace the route without waiting for longer protocol hold timers. Aggressive timers can improve reaction time but increase session churn and CPU load. Next-hop address tracking improves BGP response when next-hop reachability changes, but it is not the most precise sub-second detection tool. Graceful restart is intended to preserve forwarding during control-plane restart, not detect failures faster. Reference topics: BFD, WAN edge resiliency, BGP failure detection, sub-second convergence.

An MPLS WAN from two separate ISPs is the strongest fit when the enterprise requires an active/backup WAN design with guaranteed SLAs for applications on either connection. MPLS VPN services are typically delivered with provider-backed service-level commitments for latency, jitter, packet loss, and availability, which is why they are selected for predictable enterprise application transport. Using two separate MPLS providers improves resiliency against a provider failure while preserving SLA-backed behavior on the backup path. A hybrid MPLS and Internet VPN model can be cost effective, but the Internet path generally does not provide the same deterministic SLA unless enhanced by a specific managed service contract. Internet from two providers improves reachability diversity but does not inherently guarantee application SLA. A single ISP hybrid design creates a provider dependency and weakens availability. Therefore, dual-provider MPLS is the conservative design for guaranteed active/backup WAN service. Reference topics: MPLS WAN design, service-level agreements, active/backup WAN, provider diversity, application performance assurance.

The strict-priority queue should be limited to approximately 33 Mbps on a 100 Mbps Internet connection. Cisco QoS design guidance warns that strict priority traffic must be bounded, because excessive priority traffic can starve other queues and cause poor application performance for non-real-time traffic. For voice and interactive video, priority queuing is appropriate, but the priority class should normally be constrained to about one-third of the link capacity in a converged enterprise design. That makes 33 Mbps the best choice for a 100 Mbps link. A 75 Mbps strict-priority allocation is far too high and would leave inadequate bandwidth for routing, signaling, business data, and default traffic. A 50 Mbps allocation still gives real-time media excessive control of the interface. A 25 Mbps allocation may work in some environments but is not the standard upper-limit design answer for strict priority in this Cisco context. The architect should also classify TelePresence accurately, mark traffic consistently, and police the priority queue to protect the WAN. Reference topics: LLQ, CBWFQ, strict priority limits, TelePresence QoS, WAN congestion management.

The fabric control plane in Cisco SD-Access creates and resolves endpoint-to-location mappings. SD-Access separates endpoint identity from physical topology by using LISP in the control plane. Endpoint addresses are treated as Endpoint Identifiers, and fabric node locations are represented by Routing Locators. When an endpoint appears on a fabric edge node, the edge registers that endpoint-to-edge binding with the control-plane node. When another edge needs to send traffic to that endpoint, it queries the control plane to resolve the current location and then uses the fabric data plane to encapsulate traffic toward the correct destination. Group-Based Access Control policy creation and enforcement involve Cisco ISE, security group tags, and policy components rather than the basic mapping purpose of the fabric control plane. BGP route reflection is not the SD-Access control-plane function, and extending multiple subnets to one RLOC is not the main purpose. Reference topics: SD-Access control plane, LISP, EID-to-RLOC mapping, endpoint registration, map resolution.

The selected design is correct because the requirement describes a resilient campus architecture that must support the same VXLAN at any access-layer switch while maintaining fast convergence and high availability. In Cisco campus and data-center-style fabric designs, VXLAN provides network virtualization by carrying Layer 2 adjacency over a routed or resilient transport. The correct design must avoid a fragile single spanning-tree domain and must provide redundant forwarding paths so that an access switch or uplink failure does not isolate the VLAN or VXLAN segment. The selected option represents the design that meets those conditions by allowing the overlay segment to be extended consistently across access switches while keeping the underlay resilient. Designs that rely on a traditional Layer 2 tree, a single aggregation point, or blocked redundant links would not meet the high availability and fast convergence objectives. The important design principle is that VXLAN should ride on a stable, redundant transport and should not depend on large Layer 2 failure domains. Reference topics: VXLAN campus design, overlay networking, fast convergence, access-layer resiliency, high availability.

TLOC extension is the Cisco SD-WAN mechanism that allows a WAN Edge router without direct access to a transport to reach that transport through another WAN Edge router at the same site. Cisco describes TLOC extension as a redundancy feature in SD-WAN networks. In the question, the WAN Edge router is connected to an MPLS transport link, but Internet access is available through another WAN Edge device. With TLOC extension, the MPLS-only edge can extend traffic through the peer router toward the Internet transport, allowing the site to use multiple transports without requiring every edge router to have a physical connection to every circuit. OMP can advertise routes and TLOCs, but OMP alone does not create physical Internet access for a router attached only to MPLS. Requiring a local 4G/5G or Internet circuit on the same router is not necessary when TLOC extension is part of the design. An MPLS extranet is also not the normal SD-WAN solution for Internet transport reachability. Therefore, TLOC extension is the correct design method.

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.

In multicast routing, a source tree is also called a shortest-path tree because it is rooted at the multicast source and follows the best unicast path from receivers back toward that source. Cisco PIM documentation describes source trees as shortest-path trees and contrasts them with shared trees, which are rooted at a rendezvous point. Because the tree is built directly toward the source, it provides an optimal forwarding path between source and receivers and generally gives the lowest latency path for multicast delivery. This is why statements A and B are correct. A shared tree, not a source tree, uses a single common root at a selected point in the network, normally the RP in PIM sparse mode. Shared trees can create suboptimal forwarding because traffic may travel through the RP before switching to the shortest-path tree. Source trees require per-source multicast state, so they may consume more control-plane resources, but they are the correct choice when optimal forwarding and minimum latency are the design priorities.

EIGRP stub routing is designed to prevent remote or spoke routers from being used as transit routers. In a hub-and-spoke or dual-homed remote design, a stub router advertises only the route types permitted by its stub configuration, such as connected or summary routes, and it is not queried for routes that it cannot reasonably provide. This reduces EIGRP query scope and helps avoid stuck-in-active conditions. The tradeoff is that the network must not depend on a stub site to carry transit traffic between other parts of the topology. In this scenario, the spoke nodes are configured as EIGRP stubs. When the direct R1-to-R2 link fails, R1 cannot use the alternate path through the other spoke-side topology as a transit path to reach a subnet attached to R2. The EIGRP stub design prevents the route from being advertised in a way that would make the spoke act as a transit router. As a result, R1 has no valid route to R2 ' s attached subnet and drops the traffic. This behavior is consistent with the purpose of EIGRP stub routing.

The vSmart controller is the Cisco SD-WAN control-plane element that maintains centralized routing and policy information. WAN Edge routers form secure control connections to vSmart, and vSmart distributes OMP routes, TLOC information, service routes, and policy information across the overlay. It does not forward user traffic in the data plane; forwarding is performed by the WAN Edge routers. It also does not provide the primary management GUI, because that role belongs to vManage. vBond handles orchestration, authentication facilitation, and NAT traversal during control-plane bring-up, not the centralized routing table. The importance of vSmart in the design is that it removes the need for every WAN Edge router to maintain complex direct control-plane relationships with every other edge. It also enforces centralized control policy, which determines which routes and paths are available to which sites. Reference topics: Cisco SD-WAN architecture, vSmart controller, OMP, centralized route table, control policy, WAN Edge. This preserves scalable WAN control-plane behavior.

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.

An open YANG model is the correct choice because the automation scope is multivendor and the workflow must be reusable across diverse routing and switching platforms. Native vendor models expose platform-specific details and are valuable when a feature is unique to one operating system, but they create code branching and operational inconsistency when many vendors and hardware families are in scope. The question also says the DR playbook will be adjusted in the future, which argues for a model that reduces redesign whenever a device vendor or platform changes. Open models, such as IETF or OpenConfig where supported, provide common schema structures for standard network functions and allow the microservice and controller integration to remain cleaner. A custom individualized model would increase development and maintenance burden, not reduce it, unless there is a very specific abstraction layer requirement. Using a single native vendor model cannot support the stated multivendor environment. The professional design is to use open models wherever coverage is sufficient, then fall back to native models only for unsupported platform-specific capabilities. Reference topics: YANG model selection, OpenConfig, IETF YANG, Cisco native YANG, multivendor automation.

Contracting an internet connection and deploying DMVPN is the most practical solution when the enterprise needs a fast, affordable, and reliable backup for a single MPLS provider. DMVPN can use broadband internet transport to build encrypted GRE/IPsec tunnels between sites, providing a backup WAN path without waiting for another private MPLS provider circuit. It supports dynamic routing and can be deployed incrementally, which makes it suitable after a recent outage when time and cost matter. BFD echo mode toward a provider PE can improve failure detection, but it does not create an alternate transport if the only MPLS provider has an outage. Adding a WAN router and a floating static route also fails unless another path exists. Contracting a second MPLS provider and deploying GETVPN may be robust, but it is slower and more expensive than the requested quick and affordable backup. Reference topics: DMVPN backup WAN, MPLS resiliency, internet VPN, IPsec, branch availability, rapid WAN deployment.

TLOC information is the OMP update that allows Cisco SD-WAN to build an overlay over any public or private transport without depending on the actual underlay link addressing. Cisco OMP advertises route reachability along with Transport Location mappings. A TLOC represents where and how a WAN Edge can be reached in the transport network, using attributes such as system IP, transport color, encapsulation, and next-hop information. Remote WAN Edge routers use this information to form secure data-plane tunnels to the correct transport attachment. RLOC is a LISP locator term associated with SD-Access and LISP designs, not the SD-WAN OMP construct. DTLS is the secure transport used for control connections, but it is not an OMP route information type. LISP PITR is unrelated to Cisco SD-WAN OMP. The secure overlay is built by combining OMP routes, TLOCs, policy, and encrypted tunnel establishment. Reference topics: Cisco SD-WAN OMP, TLOC routes, transport color, overlay routing, secure data-plane tunnels.

BGP community is the correct attribute because it can support both policy requirements through coordination with the service provider. Communities are route tags that an upstream provider can match to apply routing policy, such as adjusting local preference to influence which dual-homed provider link is preferred for inbound traffic. Communities also include well-known values used to constrain route propagation. Cisco documents no-export as a community that prevents a route from being advertised outside the receiving AS, and no-advertise as a community that prevents advertisement to any peer. This directly matches the requirement that several customer-advertised networks must propagate no further. MED can influence inbound path selection in some dual-link designs, but it does not provide the propagation-control function. AS-path prepending can influence inbound traffic but is less precise and again does not solve the no-further-advertisement requirement. Local preference is normally applied inside an AS, not directly by the customer to external peers. Reference topics: BGP communities, no-export, no-advertise, provider policy, inbound traffic engineering.

The client edge can reach the Internet through ISP1 only if downstream routers inside the client network have a usable route toward the Internet. Since ISP1 provides full Internet connectivity and ISP2 is used for direct exchange with selected third parties, the edge design should advertise a default route into the client network. This gives internal routers a simple, scalable route for all Internet destinations while preserving specific routing where necessary. Running separate VRFs for each ISP may be a valid segmentation technique, but it does not by itself tell downstream routers how to reach the Internet. AS-path prepending toward ISP2 influences inbound path preference from external networks; it does not solve internal default routing. Filtering outbound advertisements so the client advertises only its own originated routes is important to avoid becoming a transit AS, but it is not the mechanism that enables internal users to reach the Internet through ISP1. The clean design is to receive or originate a default route at the edge and advertise that default to the client routing domain. Reference topics: BGP Internet edge design, default route advertisement, transit prevention, ISP peering policy.

The valid EIGRP stub options listed are receive-only and summary. Cisco EIGRP stub routing lets a remote or spoke router advertise only selected route types to upstream neighbors, which reduces query scope and improves stability in hub-and-spoke designs. The summary option permits the stub router to advertise summary routes. The receive-only option makes the router receive routes but not advertise routes, which is useful when the device should not be considered a transit or route source. “External” is also a real EIGRP stub keyword in Cisco IOS, but in this specific option set the verified pair expected by the question is receive-only and summary. “Summary-only” is not the correct EIGRP stub keyword. “Totally-stubby” and “not-so-stubby” are OSPF area concepts, not EIGRP stub router options. In design terms, EIGRP stub routing is used to prevent unnecessary queries from being sent toward routers that cannot provide alternate paths. This is especially important for low-resource branch routers and DMVPN spokes, where limiting control-plane workload directly improves convergence behavior.

A full-mesh topology best satisfies the requirement that devices make informed forwarding decisions, backup paths always exist, and suboptimal paths are used only after a failure. In a full mesh, each site or WAN node has direct connectivity to every other relevant node. This gives the routing protocol complete path visibility and allows traffic to use direct optimal paths under normal conditions. If a direct link fails, alternate paths remain available through other nodes, so the network can reroute without depending on a single hub. A hub-and-spoke design is simpler and less expensive, but spoke-to-spoke traffic must traverse the hub, which is suboptimal even during normal operation. A partial mesh can reduce cost but may still force some traffic over indirect paths when no direct connection exists. Clos is a data center fabric topology concept and is not the typical WAN topology answer here. The full mesh is the most resource-intensive design, but it best matches the stated forwarding and backup requirements. Reference topics: WAN topology, full mesh, path optimality, backup paths, routing convergence.

The action is to configure the EIGRP stub router in receive-only mode. Cisco EIGRP stub routing limits which routes a router advertises to neighbors, reducing query scope and improving stability in hub-and-spoke or WAN designs. The receive-only keyword is the most restrictive stub option: the router receives routes from neighbors but does not advertise any routes to them. That directly satisfies the requirement that WAN routes must not be advertised to the routers in the data center. Advertising only a default route still advertises routing information, so it does not meet the wording. Summarizing local subnets reduces the number of routes, but it still advertises reachability. The “distributed mode” option is not the correct EIGRP stub behavior for this requirement; redistributed stub mode would allow redistributed routes to be advertised. Receive-only is therefore the precise design control for stopping route advertisement from the stub router. Reference topics: EIGRP stub routing, receive-only mode, query scoping, route advertisement control, WAN-to-data-center design.

An OSPF sham link is the correct MPLS VPN design when backdoor links exist between customer sites and should be used only if the MPLS core is unavailable. In MPLS Layer 3 VPN designs that run OSPF between CE and PE routers, the MPLS VPN path can appear as an interarea route, while a direct dark-fiber backdoor link may appear as an intra-area route. OSPF prefers intra-area routes over interarea routes, so traffic could incorrectly prefer the dark-fiber path during normal operation. Cisco sham links solve this by creating an intra-area logical link across the MPLS VPN backbone between PE routers, making the MPLS path competitive or preferred according to OSPF cost. A virtual link connects disconnected OSPF area 0 sections and is not the right MPLS VPN tool. Stub and NSSA area types control external LSA behavior, not MPLS-backdoor path preference. The sham link preserves the desired routing hierarchy while keeping the direct dark fiber as backup. Reference topics: OSPF sham link, MPLS L3VPN, PE-CE routing, backdoor links, route preference.

AS-path prepending is the correct inbound path-control tool for this design. The objective is for traffic entering AS100 to use link 1 during normal operation and link 2 only after a failure. In BGP, the AS_PATH attribute is a primary path-selection attribute used by external autonomous systems; a shorter AS path is normally preferred over a longer path. By prepending AS100 multiple times on advertisements sent from R4 across link 2, AS100 makes the backup path look less attractive to upstream networks while leaving it available for failover. Modifying next-hop on R3 or R4 does not influence how external networks choose between two entry points into AS100. Prepending on R3 would make the preferred link less attractive, which is the opposite of the requirement. The design should also document provider policy because some providers local-preference routes before AS path, but within the choices, prepending on R4 is the appropriate inbound traffic-engineering method. Reference topics: BGP AS_PATH, inbound path control, multihoming, backup Internet edge design.

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

The Cisco SD-Access fabric control-plane node requires the LISP Map-Resolver and Map-Server functions. In SD-Access, fabric edge nodes register locally attached endpoints with the control-plane node, and other fabric nodes query the control plane when they need to locate a destination endpoint. The Map-Server stores Endpoint Identifier to Routing Locator bindings, while the Map-Resolver resolves lookup requests and returns mapping information so the source edge node can encapsulate traffic toward the correct remote fabric node. Ingress Tunnel Router and Egress Tunnel Router roles are performed by fabric edge or border nodes that encapsulate and decapsulate user traffic, not by the dedicated control-plane function. The option labeled Map-Server Proxy reflects the map-server role used in the answer set, while the Map-Resolver is explicitly required. This separation lets SD-Access provide host mobility, anycast gateway behavior, and scalable endpoint reachability without flooding. Reference topics: Cisco SD-Access control plane, LISP, Map-Server, Map-Resolver, EID-to-RLOC mapping, fabric edge registration.

PIM-SSM with IGMPv3 is the correct multicast design. Source-Specific Multicast requires receivers to identify both the multicast group and the permitted source, normally through IGMPv3 membership reports. That source-specific join model prevents unauthorized or spoofed sources from injecting traffic into the group because receivers do not simply accept traffic from any source for a group address. It also improves bandwidth efficiency because the network builds forwarding state only for the requested source and group pair, without requiring shared trees or rendezvous point discovery. PIM-SM with MSDP can interconnect multicast domains, but it is built around Any-Source Multicast behavior and does not provide the same source-specific anti-spoofing property. IGMPv2 cannot signal source-specific joins, which is why IGMPv3 is required for SSM. Since the network may merge with another multicast domain later, SSM also reduces integration complexity by avoiding RP and MSDP dependencies. Therefore, PIM-SSM and IGMPv3 meet both the security and efficiency requirements. Reference topics: PIM-SSM, IGMPv3, source-specific joins, multicast security, bandwidth efficiency.

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.

The configuration-protocol mapping distinguishes NETCONF and RESTCONF behavior in model-driven programmability. NETCONF is an XML-based network configuration protocol that runs over a secure transport such as SSH and supports structured operations such as get-config, edit-config, lock, unlock, commit, and datastore manipulation. It is well suited to transactional configuration workflows where candidate and running datastores are supported. RESTCONF exposes YANG-modeled data through a REST-style interface over HTTP or HTTPS, using familiar methods such as GET, POST, PUT, PATCH, and DELETE. It can encode data in XML or JSON depending on headers and implementation. Both protocols use YANG models to define the structure and semantics of configuration and operational data, but they differ in transport style, operation model, and tooling. The selected mapping therefore places NETCONF characteristics with the protocol that provides RPC-style operations and datastore handling, while RESTCONF receives HTTP method and URI-based characteristics. In design, the choice depends on controller support, device operating system, required transaction semantics, security policy, and developer tooling. Reference topics: NETCONF, RESTCONF, YANG, datastores, XML and JSON encoding.

Route summarization should be planned from the aggregation layer toward both the core and the access layer. In hierarchical campus routing, aggregation or distribution devices are natural summarization boundaries because they sit between more specific access-layer networks and the core. Summarizing from aggregation toward the core prevents access-layer subnet churn from forcing unnecessary recomputation and route table growth in the core. Summarizing from aggregation toward access can also provide a concise upstream route, often a default or summary route, so access devices do not need the entire network routing table. The goal is to contain failures, reduce routing state, and preserve fast convergence at hierarchy boundaries. Summarizing from the core toward aggregation may hide useful topology details in the wrong direction, while summarizing directly from access toward aggregation is not always possible or efficient when access devices are numerous and have limited resources. The answer that places summarization at aggregation in both directions best matches Cisco hierarchical design principles. Reference topics: hierarchical campus design, route summarization, aggregation layer, core route scale, convergence containment.

The telemetry mapping separates dial-in and dial-out behavior. In dial-in telemetry, the collector initiates the session toward the network device and subscribes to the data that it wants streamed. This model gives the collector direct control over the subscription lifecycle, but it requires the collector to reach the device and manage each session. In dial-out telemetry, the network device initiates the session toward the collector based on a configured subscription. This is useful when devices must stream telemetry to a centralized destination through firewalls or controlled management paths. Cisco model-driven telemetry can stream structured data from YANG models using subscription behavior rather than relying on repeated CLI polling. The selected drag-and-drop answer matches each consideration to the mode that owns the connection initiation and subscription handling. In design work, the architect must consider reachability direction, security policy, NAT traversal, collector scale, subscription persistence, and whether subscriptions should be configured on the device or created by the collector. Reference topics: model-driven telemetry, dial-in mode, dial-out mode, YANG subscriptions, gRPC telemetry, operational data streaming.

The border node is part of the Cisco SD-Access overlay architecture. In the SD-Access fabric, the overlay consists of fabric roles and services that provide endpoint connectivity, segmentation, policy, and external reachability over the routed underlay. Border nodes connect the fabric overlay to external Layer 3 networks, shared services, WAN, Internet, or other fabric/transit domains. They perform the fabric boundary function, including routing between virtual networks and external routing domains as designed. Spine and leaf are generic data center or fabric topology terms and are not the named SD-Access fabric overlay roles in this question. Cisco DNA Center, now Cisco Catalyst Center, is central to management, automation, assurance, and policy deployment, but it is not itself an overlay forwarding component. The forwarding overlay is built from roles such as edge, border, control-plane, and intermediate nodes. Therefore, the correct component from the options is the border node. The design should select border placement based on external connectivity, scale, route control, redundancy, and whether the border is internal, external, or anywhere border. Reference topics: SD-Access overlay, border node, fabric roles, external connectivity, virtual networks.

The primary capability of IaaS in this question is elastic scaling: the ability to increase or decrease infrastructure resources based on demand. In Infrastructure as a Service, the provider offers compute, storage, and network resources as an on-demand service, while the customer deploys operating systems and applications on top of that infrastructure. Cisco cloud material describes this model as providing scalable IT capacity without requiring the organization to own all physical assets. Option C is the best answer because dynamic capacity adjustment is a fundamental cloud capability and a major reason enterprises choose IaaS for variable workloads. Option B is a valid business benefit because consumption-based billing can reduce cost, but the question asks for a primary capability, not the pricing model. Option D describes automation and orchestration, which support cloud operations but are not the specific capability being tested. Option A is closer to hybrid-cloud workload mobility and is not guaranteed by IaaS alone. Reference topics: cloud service models, IaaS, elasticity, scalable compute, on-demand resource provisioning.

The selected configuration sets are correct because the addressing plan must use VLSM to maximize subnets and minimize wasted addresses. Customer A requires 125 hosts, so it needs a /25 subnet, which provides 126 usable host addresses. Customer D requires 62 hosts, so it needs a /26 subnet, which provides 62 usable addresses exactly. Point-to-point or small WAN links B, C, and E should use the smallest appropriate link subnets shown in the exhibit, typically /30 for IPv4 point-to-point links when two usable addresses are required. A correct plan must allocate the largest blocks first, align every subnet on the proper boundary, avoid overlap, and avoid assigning a larger-than-needed subnet to any customer or link. Options A and C are the two valid combinations that satisfy those rules in the exhibit. Any option that places a /25 or /26 on the wrong boundary, overlaps with another block, or wastes larger subnets on links would fail the design objective. Reference topics: IPv4 VLSM, subnet boundary alignment, host capacity planning, point-to-point addressing, route summarization readiness.

The drag-and-drop mapping is based on the standard Cisco Catalyst SD-WAN component roles. vManage, now Cisco Catalyst SD-WAN Manager, provides centralized management, configuration, monitoring, templates, and operational visibility. vSmart Controller provides the centralized control plane, distributes OMP routing information, and applies control policy to determine reachability and path selection. vBond Orchestrator supports initial authentication, orchestration, and NAT traversal so WAN Edge devices can join the overlay. WAN Edge routers provide the data plane at branches, campuses, data centers, and cloud edges; they forward user traffic, establish secure tunnels, and apply localized policies. Correctly separating these roles is critical in the design because management, control, orchestration, and forwarding scale independently. Misidentifying vBond as the data-plane element or vManage as the route controller would lead to an incorrect SD-WAN architecture. Reference topics: Cisco Catalyst SD-WAN components, vManage, vSmart, vBond, WAN Edge, OMP control plane. This role separation is also what lets large deployments scale without mixing troubleshooting, provisioning, and forwarding responsibilities on one system.

VPLS is the appropriate design model when multiple remote sites must appear to share the same Layer 2 segment. Because all sites use the same IP subnet, the solution must preserve a common broadcast domain rather than require Layer 3 route exchange between unique subnets. Cisco VPLS provides multipoint Layer 2 VPN service across a provider network, allowing customer edge devices at different sites to communicate as though they were attached to the same Ethernet LAN. Including 802.1Q connectivity on the LAN-facing side of the CE is the practical requirement because the CE must carry the relevant VLAN toward the provider-delivered VPLS service. Route exchange with the provider is not the main mechanism because VPLS is a Layer 2 service. NAT would hide overlapping addressing, but it would defeat the requirement to keep the same subnet operational across the sites. Placing each site in a different VLAN would also break the shared-subnet design. The correct design is therefore VPLS with VLAN tagging on the CE LAN side. Reference topics: VPLS, Layer 2 VPN, 802.1Q trunking, shared subnet extension, Ethernet WAN design.

StackWise Virtual is the correct technology for Cisco Catalyst 9500 aggregation switches when the design requires nonblocking Layer 2 multichassis EtherChannel from aggregation to access. The question specifically describes Catalyst 9500 switches located on different floors for availability, with access switches dual-homed through a Layer 2 MEC design. Traditional VSS was used on older Catalyst platforms such as Catalyst 4500 and 6500 families. For Catalyst 9000 platforms, Cisco uses StackWise Virtual to virtualize two physical switches into a single logical switching system. This enables multichassis EtherChannel, removes the need for STP to block one uplink, improves convergence, and provides device-level redundancy. vPC is a Nexus data-center technology, not a Catalyst campus aggregation technology. StackWise-180 refers to physical stack bandwidth behavior on specific access platforms and does not provide the same distributed campus aggregation function. Therefore, the design should use StackWise Virtual on the Catalyst 9500 aggregation pair. Reference topics: Catalyst 9500, StackWise Virtual, multichassis EtherChannel, campus aggregation, Layer 2 resiliency.

An out-of-band management network should be isolated from the production data network and protected with strict access control. Cisco SAFE design principles treat the management plane as a sensitive function because it provides administrative access to infrastructure devices. Isolation ensures that production outages, routing problems, or compromised user segments do not automatically remove the operator’s ability to manage routers, switches, firewalls, and controllers. Access control ensures that only authorized administrators and management systems can reach the management interfaces and protocols. The management network should not be treated as a backup data path, because that undermines separation and can expose management devices to production traffic risks. It should also not be used as a general-purpose data backup network. “Facilitate network integration” is too vague and can conflict with the isolation requirement. Therefore, the best practices are to enforce access control and ensure network isolation. In a mature design, this normally includes dedicated management interfaces or VRFs, jump hosts, AAA, logging, and tightly controlled management protocol access.

A fabric edge node in Cisco SD-Access is the access-layer fabric device that connects endpoints to the fabric, applies policy, and registers endpoint reachability with the control plane. Cisco SD-Access design material describes edge nodes as devices that identify and authenticate endpoints, place them into the correct virtual network, and update the fabric control plane with endpoint information. The edge node is also where the anycast Layer 3 gateway commonly resides, allowing consistent gateway behavior across the fabric. Option B describes the control-plane node function, because the control plane maintains endpoint-to-location mappings in the host tracking database. Option C describes a border node, which connects the fabric to external Layer 3 networks. Option D also describes the map-resolver behavior associated with the control plane, not the fabric edge. The purpose of the edge node is therefore endpoint attachment, endpoint detection, policy association, and registration of endpoint information with the control plane so the fabric can forward traffic through the correct overlay path.

A single-homed WAN design is appropriate for two small branch offices when cost is the main concern, routing overload must be avoided, and occasional downtime is acceptable. Single-homed connectivity uses one WAN connection from the branch to the provider or headquarters. It is the simplest and least expensive model because it minimizes circuits, routers, routing adjacencies, and failover complexity. Dual-homed or multihomed designs improve availability, but they add cost and operational overhead through additional links, devices, routing policy, and monitoring. Dual multihomed designs are the most resilient but clearly exceed the requirement for a small cost-sensitive branch. A single multihomed design provides some provider or link diversity, but it is still more complex than necessary if the customer accepts some downtime. In Cisco WAN design, the correct topology must match the business availability requirement; not every site justifies redundant circuits. Reference topics: WAN topology selection, single-homed branch design, cost versus availability, routing simplicity, branch connectivity.

The correct IS-IS hierarchy places area 49.000 as Level 2 and areas 49.001, 49.002, and 49.003 as Level 1. In IS-IS, Level 2 forms the interarea backbone, while Level 1 areas contain local topology details. This design supports growth in the backbone because Level 2 routers exchange interarea reachability without carrying every local topology change from every access area. Areas 49.002 and 49.003 can perform summarization and route leaking at their Level 1/Level 2 boundaries, allowing routers such as A1 and A2 to avoid suboptimal routing by learning selected more-specific routes from the backbone when necessary. If the nonbackbone areas were made Level 2, the design would flatten the hierarchy and expose more of the network to topology changes. If the backbone were Level 1, interarea routing would be broken or badly constrained. The selected hierarchy preserves scaling, allows route control, and avoids unnecessary propagation of local link flaps. Reference topics: IS-IS hierarchy, Level 1 areas, Level 2 backbone, route leaking, summarization, scaling.

For model-driven telemetry with periodic updates, the architect must understand that each periodic update sends the subscribed data at the configured interval. Cisco telemetry guidance distinguishes periodic subscriptions from on-change subscriptions. A periodic subscription streams a full copy of the subscribed data element or table at each interval, even if the underlying state has not changed. That behavior is useful when the collector needs regular time-series samples, trending, or baseline monitoring, but it creates predictable bandwidth and collector-load requirements. On-change subscriptions are different: they publish updates when the subscribed state changes and are more efficient for state changes such as interface status, memory thresholds, or protocol adjacency m ovement. Empty subscription behavior and initial update timing may matter in specific implementations, but they are not the main design consideration in this question. Since the customer requires periodic updates, the design must size the transport, collector, retention system, and subscription intervals around repeated full data delivery. Reference topics: model-driven telemetry, periodic subscription, on-change subscription, YANG-modeled operational data, collector sizing.

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.

EIGRP variance is the correct design because the requirement is to use the best two paths while all links are available and maintain forwarding if one path fails. EIGRP supports unequal-cost load balancing when feasible successors exist and the variance multiplier allows additional loop-free paths to be installed in the routing table. Cisco EIGRP design uses the feasible distance and reported distance conditions to ensure that unequal-cost alternatives are loop free before they are used. The maximum-paths command controls how many equal or eligible paths can be installed, but it does not make an unequal path eligible. Add-paths is a BGP feature, not an EIGRP mechanism. Changing metric weights is rarely recommended because it affects metric calculation globally and can create inconsistent routing if not deployed everywhere. Variance 2 allows EIGRP to include backup paths whose metric is within two times the successor metric, assuming they satisfy the feasibility condition. Reference topics: EIGRP variance, unequal-cost load balancing, feasible successor, DUAL, path resiliency.

The correct XML/YANG data model set is the option that accurately represents the IOS XE interface hierarchy, assigns the IPv4 address to GigabitEthernet2/1/0, and uses the correct prefix length of 27. In model-driven programmability, the payload must match both the selected YANG model schema and the target platform’s interface naming conventions. For IOS XE native models, interface configuration is structured under the Cisco native namespace, with interface type and name represented in the schema before IPv4 address elements are applied. The address 10.10.10.10/27 must also support a directly connected host at 10.10.10.1/27, which places both addresses in the same 10.10.10.0/27 subnet. Options that place the address under the wrong interface type, use the wrong namespace, incorrectly represent the mask, or configure the host route rather than the interface are invalid. Option D is the only answer aligned to the IOS XE YANG structure and the requested addressing. Reference topics: IOS XE native YANG, NETCONF XML payloads, interface configuration, IPv4 prefix length, model-driven programmability.

VRRP object tracking allows the effective priority of a VRRP router to change when a tracked object changes state. Cisco documentation states that VRRP object tracking ensures the best VRRP router is master by altering VRRP priorities according to tracked objects such as interface or IP route states. This directly supports answer A. It also supports answer D, because VRRP can track interfaces and routes through the tracking process. The priority does not have to remain fixed; object tracking is specifically designed so a router can lower its priority when an uplink, route, or critical dependency fails. A VRRP group is not limited to one tracked object in modern Cisco implementations, so option C is too restrictive. VRRP does not support only interface tracking; route tracking is also a common use case, especially when the LAN interface is still up but upstream reachability has failed. In a resilient campus or branch gateway design, object tracking prevents a router from remaining master when it no longer has a valid upstream path, improving deterministic failover.

IS-IS supports two fundamental circuit types: broadcast multiaccess and point-to-point. A broadcast or multiaccess circuit is used on media such as Ethernet where multiple routers can share the same Layer 2 segment. In that case, IS-IS elects a designated intermediate system to simplify database synchronization on the shared network. A point-to-point circuit is used where exactly two IS-IS routers form an adjacency across a direct link, which is common in modern routed campus, data center, and WAN designs. IS-IS does not use the same nonbroadcast multiaccess and point-to-multipoint network-type model that is familiar from OSPF. When IS-IS must run across technologies that do not naturally behave like Ethernet broadcast media, the design is typically adapted with point-to-point subinterfaces or appropriate Layer 2 treatment rather than selecting an IS-IS NBMA circuit type. Therefore, from the listed choices, the supported IS-IS circuit types are multiaccess and point-to-point.

When BFD echo mode contributes to high CPU utilization on lower-resource devices, the practical design response is to use slower BFD timers for those peers rather than continuing to run an overly aggressive failure-detection profile everywhere. Cisco BFD provides fast failure detection, but timer values must match platform capability, interface scale, and the operational value of subsecond detection. Echo mode can generate frequent packets, and in some environments the processing or punt behavior can create measurable CPU pressure. Slowing the timers reduces packet rate and control-plane stress while keeping BFD available for faster detection than traditional routing protocol dead timers. Moving to asynchronous mode may be appropriate in some designs, but the listed option says “BED” and does not directly address the requirement as cleanly as reducing timer aggressiveness. BFD multihop is used for non-directly connected peers and is not a CPU-relief mechanism. Carrier delay changes interface state notification behavior, but it does not solve BFD packet processing load. Therefore, implement slower timers on peers with limited resources. Reference topics: BFD design, echo mode, failure-detection timers, CPU utilization.

The verifying get-config reply must reflect the same YANG model hierarchy and configured values that were pushed by the Postman request. In model-driven automation, a successful transport response is not enough; the engineer must confirm that the intended datastore contains the exact interface, routing, or protocol objects described by the model. Option D is the selected reply because it matches the expected YANG structure for the configuration operation shown in the exhibit. The key principle is that get-config returns configuration data from a specified datastore, such as running or candidate, using the schema-defined XML hierarchy. If the returned XML uses the wrong container, wrong namespace, incorrect key value, or an unexpected leaf, the model set was not designed or addressed correctly. Cisco NETCONF/YANG workflows rely on strict namespace and path accuracy, so even a small mismatch can result in configuration being placed in the wrong subtree or not applied. A clean validation checks the model namespace, parent containers, list keys, leaf names, and actual configured value. Reference topics: NETCONF get-config, YANG XML encoding, datastore validation, Postman automation workflow.

The border node provides connectivity between the SD-Access fabric and networks outside the fabric. In Cisco SD-Access, edge nodes connect endpoints to the fabric, intermediate nodes transport routed IP traffic through the underlay, control-plane nodes maintain endpoint location mappings, and border nodes connect the fabric to external Layer 3 domains such as the data center, WAN, internet edge, or shared services network. A border node may perform proxy tunnel router functions and can de-encapsulate fabric traffic that is destined outside the overlay, but its design purpose is external connectivity for the fabric site. Network virtualization is primarily delivered through virtual networks, VRF separation, LISP control-plane mappings, and VXLAN encapsulation. Expanding the network is too vague and does not identify a Cisco SD-Access role. Therefore, among the available options, the border node is the component used to connect the fabric to the required external network resources. Reference topics: Cisco SD-Access border node, external connectivity, fabric roles, LISP proxy tunnel router, VN-to-VRF mapping.

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.

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.

Affinity is the SD-WAN feature used to control and reduce control connections between WAN Edge devices and vSmart controllers. Cisco SD-WAN high-availability documentation describes controller affinity as a way to limit the number of controllers that an edge device establishes control connections with, while still preserving controller and data center redundancy. This reduces unnecessary control-plane load and limits the strain placed on vSmart controllers in large overlays. The feature is particularly useful when multiple vSmart controllers exist across multiple data centers and the designer wants predictable primary and backup controller relationships. The color attribute identifies transport characteristics, such as public Internet, MPLS, or other transport types. Control-connections is a general concept, not the feature that minimizes them. Control-direction is not the correct design construct for this purpose. A scalable SD-WAN design should use affinity where controller scale, regionalization, and control-plane efficiency must be explicitly managed. Reference topics: Cisco SD-WAN controller affinity, vSmart scale, control connections, TLOC control-plane optimization.

The correct overlay considerations are that virtual networks provide data-plane isolation and that overlapping IP addresses should be avoided for operational simplicity. In Cisco SD-Access, virtual networks are used for macro segmentation and are commonly mapped to VRFs. This separates routing and forwarding tables between major groups such as corporate users, guests, IoT, and shared services. Security Group Tags provide finer policy control and microsegmentation, but they are not the primary mechanism for data-plane isolation between virtual networks. The phrase “virtual networks should be used for microsegmentation” is therefore inaccurate; microsegmentation is SGT and SGACL driven. Although overlapping IP addresses can technically exist in separate VRF-like contexts, Cisco design practice discourages unnecessary overlap because it complicates troubleshooting, service insertion, external connectivity, and inter-VN communication. A clean overlay address plan improves operations and reduces policy ambiguity. Reference topics: SD-Access overlay design, virtual networks, macro segmentation, SGTs, microsegmentation, overlapping IP avoidance. This also simplifies day-two operations.

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.

A dual-homed Internet design with a single edge router and site-to-site VPN topology best matches the stated cost and flexibility requirements. The customer needs redundant WAN links, has a limited budget, wants easy future bandwidth increases, and does not require consistent end-to-end QoS on the branch routers. Internet circuits are typically less expensive and easier to upgrade than MPLS access circuits, making them appropriate for small to medium-sized remote branches when strong QoS guarantees are not required. A single edge router also reduces hardware cost and operational complexity compared with dual edge routers. WAN MPLS designs can provide stronger service-level guarantees and QoS treatment, but they are more expensive and less flexible for rapid bandwidth upgrades. A design with dual edge routers improves device redundancy but conflicts with the limited-budget condition. Therefore, a dual-homed Internet solution using a site-to-site VPN overlay is the most appropriate option. The architect should still validate encryption requirements, failover behavior, routing preference, and whether the Internet underlay can meet application performance expectations. Reference topics: branch WAN design, dual Internet connectivity, site-to-site VPN, cost-driven WAN selection.

PortFast is the correct functionality for the Gi1/0/1-10 interfaces when those ports are endpoint-facing access ports. Cisco spanning-tree design uses PortFast to allow edge ports to transition directly to the forwarding state, avoiding the normal listening and learning delay associated with traditional STP convergence. That improves user and endpoint connectivity after link-up events and is especially important for workstations, phones, printers, and access devices that should not participate in the Layer 2 topology. Root guard and BPDU guard are protection features, not the primary convergence optimization requested by the architect. UplinkFast was used in older STP designs to accelerate recovery for access switches with redundant uplinks, but it is not the edge-port functionality for interfaces Gi1/0/1-10. In a modern design, PortFast should be enabled only on true host-facing ports, normally together with BPDU guard to protect against accidental switch attachment. If the exhibit shows these interfaces as end-user access ports, PortFast is the feature that follows the recommendation to optimize STP convergence time. Reference topics: STP PortFast, edge-port convergence, BPDU guard, Layer 2 campus design.

PIM Source-Specific Multicast is the correct multicast protocol when receivers can subscribe to traffic from known sources and the design must avoid rendezvous points. SSM uses the (S,G) model, where receivers explicitly join a multicast group from a specific source. Because the source is known at join time, the network does not need a shared tree or RP discovery process. This makes SSM attractive for broadcast-style streaming applications, such as video channels, where each stream source is known and receivers subscribe to specific channels. PIM Sparse Mode and Any-Source Multicast use an RP to allow receivers to discover active sources, so they do not meet the requirement of no rendezvous point. BIDIR-PIM also relies on an RP-rooted shared tree and is optimized for many-to-many applications rather than source-specific broadcast channels. For a large cable TV provider streaming multiple video channels from defined sources, SSM simplifies the multicast control plane, eliminates RP dependency, and scales efficiently by creating only the source-specific state required by active receivers.

Summarization on routers A and C is the correct design because the requirement is to keep failures of the listed access networks from impacting the core while still supporting fast convergence in both access and core. Route summarization creates an aggregation boundary: more-specific access routes can flap behind the summary without causing the core to learn and withdraw every individual prefix. Cisco hierarchical routing design uses summarization at distribution or aggregation boundaries to reduce routing-table size, contain convergence events, and protect the core from access-layer instability. Adding another aggregation layer may be appropriate in some large designs, but it is not necessary when the question asks for the mechanism that stops specific prefix failures from impacting the core. Graceful restart protects forwarding during control-plane restart events, not ordinary access-prefix failures. FRR provides fast reroute for link or node failures but does not hide individual connected-network changes from the core. Summarizing at routers A and C directly addresses the stated networks and reduces the query, LSA, or update impact depending on the routing protocol used. Reference topics: route summarization, hierarchical routing, convergence containment, core protection, prefix aggregation.

End-to-end microsegmentation in Cisco SD-Access is enforced with Security Group Tags and Security Group ACLs. Virtual networks provide macrosegmentation by separating routing tables and address spaces, but SGTs provide more granular group-based policy inside or across those virtual networks. Cisco SD-Access segmentation guidance explains that users or endpoints are assigned to security groups through SGTs and that SGACLs control communication between those groups. This avoids building large numbers of VLANs or IP ACLs tied to topology. VLANs alone provide Layer 2 separation but do not deliver identity-based end-to-end microsegmentation. Five-tuple ACLs can filter traffic, but they are more operationally complex and less policy-oriented than group-based access control. VRFs are useful for macrosegmentation, not microsegmentation within a virtual network. Therefore, SGTs and SGACLs are the correct enforcement method. In a professional design, the architect should define scalable groups according to business roles and application access needs, then use Cisco DNA Center and ISE integration to automate consistent policy deployment across the fabric.

When eBGP neighbors share the same autonomous system number, normal BGP loop-prevention behavior can block route acceptance because the receiving router sees its own AS in the AS_PATH. Two BGP features address this design condition. The allow-as-in feature permits a BGP router to accept routes even when its own AS appears in the AS_PATH a configured number of times. This is often used in dual-homed or migration designs where the same customer AS appears at multiple sites. The as-override feature is typically used by a provider edge router to replace the customer AS in the AS_PATH with the provider AS before advertising the route to another customer site that uses the same AS. Together, these features allow successful route exchange in same-AS eBGP scenarios while preserving loop-prevention intent through controlled policy. Advertise-best-external influences advertisement of best external paths and does not solve same-AS rejection. Bestpath as-path ignore affects path selection, not route acceptance. Client-to-client reflection is an iBGP route-reflector behavior, not an eBGP same-AS solution.

gRPC provides efficient integration by using protocol buffers to serialize and deserialize structured data over the network. In network programmability and telemetry designs, gRPC is commonly used as the transport framework for streaming model-driven telemetry or for remote procedure calls between collectors, controllers, and network devices. Protocol buffers define compact structured messages that are faster and less ambiguous than parsing text output. This makes gRPC suitable for high-volume telemetry and programmatic device interaction. LDAP is a directory and authentication-related protocol, not the integration mechanism provided by gRPC. XMPP is associated with messaging and presence systems, not gRPC data serialization. Graph API is not a gRPC feature. The operational value of gRPC is that it provides a modern RPC framework with efficient message encoding, service definitions, and support for secure transport through TLS when implemented by the platform. Reference topics: gRPC, protocol buffers, model-driven telemetry, network programmability, structured data serialization. It improves controller interoperability.

Enabling EIGRP stub routing on the spokes decreases convergence time in a hub-and-spoke design by reducing unnecessary queries and preventing spokes from being treated as transit routers. EIGRP convergence can be delayed when a router loses a route and must query many neighbors to determine whether an alternate path exists. In remote-site or spoke designs, a spoke normally has no useful alternate path for networks beyond itself, so querying it wastes time and can contribute to stuck-in-active conditions. Cisco EIGRP stub routing allows the spoke to advertise only permitted route types and informs upstream routers not to query the spoke for routes outside its scope. This creates a cleaner query boundary and accelerates convergence after link or route failures. Subsecond timers can detect neighbor loss more quickly, but they do not address the broader EIGRP query behavior shown in the design. Increasing hold or dead timers would slow detection, not improve convergence. Therefore, in the displayed hub-and-spoke EIGRP design, enabling stub routing on the spokes is the correct solution to decrease convergence time.

The correct policy is to prepend the AS path on the nonpreferred advertisement for each prefix. For inbound BGP traffic engineering, the enterprise normally influences remote autonomous systems by changing attributes that those systems see when selecting a path. AS-path prepending makes a route appear less attractive by adding repeated instances of the local AS number to the AS path. In this design, network 10.1.1.0/24 should enter through R3-R1, so R2 must advertise that prefix with a prepended AS path to make the R4-R2 path less preferred unless the primary path fails. Conversely, network 10.1.2.0/24 should enter through R4-R2, so R1 must advertise that prefix with prepending to make the R3-R1 path less preferred. This creates inbound load sharing while preserving failover because the prepended route remains available as a backup. Local preference affects outbound path selection inside the local AS, not inbound selection by the provider. Reference topics: BGP traffic engineering, AS-path prepending, inbound path control, prefix-specific policy, multihomed WAN design.

Bidirectional PIM is the correct multicast protocol for this many-to-many financial application. The question states that most multicast sources also receive multicast traffic and that the design must not use source trees. Cisco describes BIDIR-PIM as a multicast mode built for many-to-many applications that use a shared tree rooted at the rendezvous point and avoid per-source shortest-path trees. This reduces multicast state because routers do not maintain separate source/group state for every active sender. PIM Sparse Mode can start with a shared tree, but it can switch to source trees, which violates the stated requirement. PIM-SSM is explicitly source-specific and requires receiver knowledge of the source, so it is not appropriate for a many-to-many model where source trees are disallowed. MSDP is not a multicast forwarding mode; it is used for source discovery between PIM-SM domains. The option text contains a spelling error, but the intended answer is BIDIR-PIM. The architect should verify RP placement, Designated Forwarder behavior, group ranges, and whether the application can tolerate shared-tree forwarding rather than shortest-path source trees. Reference topics: BIDIR-PIM, many-to-many multicast, shared tree, source-tree avoidance, multicast scaling.

Option A is the best addressing design because it gives each site enough capacity while avoiding excessive address waste and supporting summarization. A campus requiring 12,000 devices needs at least 14 host bits because 2^13 minus two is only 8190 usable addresses, while a /18 provides 16,382 usable addresses. That leaves room for growth without assigning an unnecessarily huge block. Each branch requiring 1,000 devices needs at least 10 host bits; a /22 provides 1,022 usable addresses, but /21 provides 2,046 usable addresses and additional growth capacity. The selected branch blocks, 10.0.192.0/21 and 10.0.200.0/21, are contiguous on valid /21 boundaries and can be summarized cleanly where appropriate. Option D fails because a /20 supports only 4094 usable addresses and cannot accommodate the 12,000-device campus. Option B overallocates a /16 to the campus and /20s to branches, wasting resources. Option C is grossly oversized and operationally poor. Reference topics: hierarchical IPv4 addressing, route summarization, VLSM, host-capacity planning, convergence containment.

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.

Using multiple equal-cost links and an IGP maximizes utilization between the core and distribution layers in a Layer 3 campus design. When links are routed point-to-point links and have equal routing cost, the IGP can install equal-cost multipath routes in the forwarding table. Traffic can then be distributed across multiple uplinks, improving bandwidth utilization and resiliency without depending on spanning tree. HSRP provides first-hop gateway redundancy for end hosts, but it does not by itself load-share all core-to-distribution links. Rapid PVST+ improves Layer 2 convergence but still blocks redundant Layer 2 paths in a looped topology, so it does not maximize link use. Multiple unequal-cost links are not the normal design for maximum use unless a routing protocol and platform specifically support unequal-cost load sharing, and even then it adds complexity. Cisco enterprise campus design generally prefers routed links between distribution and core for predictable convergence and ECMP. Therefore, the correct pair is multiple equal-cost links and an IGP. Reference topics: routed campus design, ECMP, IGP path selection, core-distribution resiliency, Layer 3 campus.

LFA FRR is the correct improvement because it gives OSPF a precomputed repair path instead of waiting for normal SPF reconvergence after a component failure. Cisco describes OSPF LFA Fast Reroute as using a precomputed alternate next hop to reduce failure reaction time when the primary next hop fails. The forwarding plane can move traffic to the alternate path while the control plane reconverges, which directly addresses the short outage described in the question. Incremental SPF reduces CPU impact by recomputing only the affected part of the SPF tree, but it still relies on the post-failure SPF process. BFD detects a failure quickly, but by itself it does not install a loop-free repair path. Aggressive timers also improve detection but increase control-plane sensitivity and do not provide local repair. In an enterprise OSPF design where the complaint is outage during recomputation, LFA FRR is the stronger availability mechanism. Reference topics: OSPF Loop-Free Alternate, IP Fast Reroute, SPF convergence, local repair paths, routed resiliency.

Wake-on-LAN across routed boundaries requires directed broadcast handling toward the client subnet and helper behavior to forward the magic packet correctly. A sleeping host normally does not maintain a normal IP session, so the WoL magic packet is commonly sent as a directed broadcast to the destination subnet. Cisco designs therefore enable IP directed broadcast on the routed interface or SVI for the client subnet where the sleeping endpoints reside, while controlling the feature carefully to avoid abuse. The ip forward-protocol behavior is also relevant because routers must forward the required UDP broadcast traffic rather than dropping it at the Layer 3 boundary. In addition, an IP helper address toward the WoL server or relay path may be needed on client-facing interfaces so the magic packet can be delivered from the management or server subnet to the client subnet. PortFast helps endpoints become reachable quickly at Layer 2, but it does not replace routed broadcast forwarding. Reference topics: Wake-on-LAN, directed broadcast, ip helper-address, UDP forwarding, PortFast, campus services.

As a STUN server, Cisco vBond allows Cisco Catalyst SD-WAN routers to discover their public mapped IP addresses and ports when they sit behind NAT. This function is essential during overlay bring-up because many WAN Edge devices are deployed behind internet circuits, firewalls, or provider NAT devices. vBond helps devices understand how they are seen from the public transport side and facilitates the formation of secure control connections to the SD-WAN controllers. vBond also participates in orchestration and Zero-Touch Provisioning workflows, but the question specifically asks about its purpose as a Session Traversal Utilities for NAT server. That wording points directly to NAT discovery, not general ZTP. vBond does not secure user data traffic between edge routers; data-plane encryption is established between WAN Edge devices. It also has no role in integrating SD-Access wireless into a fabric. Reference topics: Cisco SD-WAN vBond, STUN, NAT traversal, orchestration, WAN Edge onboarding. This is fundamental for internet transports.

The correct code snippet must use a secure HTTPS-based RESTCONF transaction with the YANG JSON media type. The requirement explicitly states that the content type is application/yang-data+json and that the connection to the network device must be secured. In Cisco IOS XE programmability, RESTCONF uses HTTP methods against YANG-modeled resources, and secure deployments use HTTPS rather than clear-text HTTP. A loopback interface with address 172.16.15.12/32 would be configured by sending a JSON payload that follows the selected YANG model structure, commonly an IETF or Cisco native interface model, with the correct content-type and authentication headers. The key security indicator in the option must therefore be HTTPS/TLS, not an insecure HTTP URL or a non-YANG content type. NETCONF over SSH would also be secure, but the stated content-type points to RESTCONF with JSON encoding. Option A is the valid snippet because it aligns the payload format with a secure transport. Reference topics: RESTCONF, YANG JSON encoding, application/yang-data+json, HTTPS, IOS XE programmability.

A logical topology that virtually connects devices over an arbitrary physical network is an overlay. In Cisco SD-Access, the underlay provides basic IP reachability between fabric nodes, while the overlay creates the logical network used by endpoints, virtual networks, and policy segmentation. The overlay is not constrained to the exact physical cabling topology; instead, it uses encapsulation and control-plane mapping to carry user traffic across the routed fabric. Cisco SD-Access uses LISP in the control plane for endpoint-to-location mapping and VXLAN in the data plane for encapsulation. This allows the fabric to present consistent logical connectivity even when the physical network is built from routed links and different infrastructure layers. The data plane is the forwarding mechanism, the control plane resolves location information, and the underlay is the physical and routed transport. The logical topology built on top of those components is the overlay. Reference topics: Cisco SD-Access overlay, underlay, VXLAN, LISP, fabric logical topology.

Cisco Catalyst SD-WAN separates orchestration from management, control, and data forwarding. The orchestration-plane function is provided by vBond, which authenticates WAN Edge devices and helps establish secure connectivity between edges and controllers. In Cisco design terms, vBond is also the NAT traversal facilitator because it allows devices sitting behind NAT to discover reachable public and private address information and form the correct control connections. These two functions match the options for primary authentication point and NAT traversal facilitation. Centralized provisioning, troubleshooting, monitoring, and template-based configuration belong to vManage, the management plane. Route and policy distribution belongs to vSmart, the control plane, through OMP. Zero Touch Provisioning is part of the onboarding workflow, but the question asks for orchestration-plane functions, not the broader provisioning service. A sound SD-WAN design should deploy redundant vBond instances, ensure DNS reachability to them, and validate firewall rules so DTLS/TLS control connections can be established reliably across Internet and private transports. Reference topics: Cisco SD-WAN architecture, vBond orchestration, control connections, NAT traversal.

Switch D should be the VLAN 10 primary root, Switch C should be the VLAN 10 secondary root, and link A should remain a Layer 2 trunk. The requirements say VLANs span multiple access switches and all VLANs are trunked on all uplinks. In that design, the distribution interswitch link must remain Layer 2 so the VLAN can exist consistently across the access layer. For fastest and most deterministic Rapid PVST+ convergence, the spanning-tree root bridge should align with the active first-hop gateway for the VLAN. In the exhibit, Switch D is the active gateway for VLAN 10, so making Switch D the primary STP root avoids unnecessary traffic tromboning and keeps the forwarding path optimal. Switch C becomes the secondary root for resiliency. A Layer 3 routed interdistribution link is a best practice when VLANs are not stretched, but it contradicts the stated requirement that VLANs span access switches. Reference topics: Rapid PVST+, STP root placement, FHRP alignment, Layer 2 campus distribution, VLAN spanning design.

An inbound IP prefix list is the correct tool because the routers must decide which prefixes to accept from the service provider based only on prefix length. Prefix lists are designed to match network prefixes and mask-length ranges using operators such as le and ge. Applying the prefix list inbound to the BGP neighbors prevents routes with masks longer than /24 from entering the local BGP table, regardless of what the service provider advertises. This conserves memory and ensures the customer routing policy is enforced locally. An access list is a poor fit because it does not natively express prefix-length logic as cleanly as a prefix list. Applying the policy outbound would filter routes the customer sends to the provider, which is the wrong direction; the requirement is about routes the customer learns. A route map could reference a prefix list, but the simplest and most exact answer is to use an IP prefix list inbound. Therefore, the design should apply an inbound prefix list to both BGP peers to block prefixes greater than /24. Reference topics: BGP route filtering, prefix lists, inbound policy, maximum accepted prefix length.

Service routes in OMP updates identify services that are available for centralized service insertion. In Cisco Catalyst SD-WAN, OMP does more than advertise ordinary VPN prefixes. It also carries TLOC routes, which describe transport locators, and service routes, which allow the fabric to steer traffic toward network services such as firewalls, intrusion prevention systems, or other centralized service nodes. This is how the SD-WAN control plane distributes enough information for WAN Edge routers to make policy-driven forwarding decisions without requiring each device to learn service attachment through a separate routing protocol. A service route is not used to describe the underlay transport itself, because that function is handled by TLOC information. It is also not a route to the orchestration plane or a remote management definition. The design value is that service insertion can be centrally advertised and controlled through OMP, then applied consistently through SD-WAN policy. Reference topics: Cisco SD-WAN OMP, service routes, TLOC routes, service insertion, centralized data policy.

DiffServ is the correct QoS model for a business-critical, delay-sensitive, high-bandwidth application across DMVPN tunnels protected with IPsec. Differentiated Services classifies and marks traffic, usually with DSCP, and then applies per-hop behavior at each network device. This model scales well across enterprise WANs because routers do not need to maintain per-flow reservation state. DMVPN and IPsec overlays can carry marked traffic, and the WAN design can apply queuing, shaping, and congestion avoidance based on those markings. IntServ with RSVP can provide explicit resource reservation, but it is stateful and does not scale well across many branch tunnels. RSVP also becomes operationally difficult across encrypted overlay environments. WRED is only a congestion avoidance mechanism, not a complete QoS architecture. Because the application needs differentiated treatment but the WAN must remain scalable, DiffServ is the practical Cisco enterprise design model. Reference topics: DiffServ, DSCP marking, DMVPN QoS, IPsec QoS pre-classify, per-hop behavior, enterprise WAN QoS.

BFD with default BGP timers is the best design choice because it improves failure detection without forcing BGP itself to run aggressive keepalive processing. Cisco documentation describes BFD as providing fast forwarding-path failure detection and notes that BFD can be less CPU-intensive than reduced EIGRP, BGP, and OSPF timers because parts of BFD can be distributed to the data plane. Lowering BGP keepalive and hold timers makes the BGP process detect failure sooner, but it increases control-plane activity and can create instability at scale. Tuning the BFD multiplier to an extreme value such as 50 is also counterproductive because it lengthens detection rather than improving it, depending on the interval used. The correct approach is to leave normal BGP timers in place and bind BGP neighbor fall-over to BFD. When the forwarding path fails, BFD notifies BGP quickly, allowing the route to be withdrawn and an alternate provider path to be selected faster without unnecessary BGP timer churn.

EIGRP with stub routing and variance is the best fit for Cisco-only DMVPN branches with unequal Internet link speeds and limited branch resources. EIGRP works well over DMVPN because it supports hub-and-spoke designs, unequal-cost load balancing, and simple branch optimization through stub routing. Stub branches limit query propagation and reduce CPU, memory, and bandwidth consumption on small routers. Variance allows EIGRP to use feasible unequal-cost paths, which is important when one Internet connection is 10 Mbps and the other is 100 Mbps. OSPF can run over DMVPN, but virtual links are not an appropriate branch design and OSPF is less efficient in this specific Cisco-only unequal-bandwidth scenario. IS-IS is not commonly selected for small DMVPN branch overlays. iBGP with route reflectors can scale, but it does not inherently use link utilization and unequal metric behavior as cleanly as EIGRP variance for this requirement. Reference topics: EIGRP over DMVPN, stub routing, variance, unequal-cost load balancing, branch resource optimization.

This YANG mapping is based on how IETF, OpenConfig, and Cisco native models differ in portability and schema organization. IETF models are produced through the standards process and are appropriate when the same management structure is expected across vendors for common protocols. OpenConfig models are also vendor-neutral, but they are built around a consistent operational model used heavily for streaming telemetry and multivendor automation. Cisco native models mirror Cisco platform configuration more closely and expose device-specific capabilities that may not exist in common models. The selected answers keep those boundaries clear. This matters because a NETCONF or RESTCONF payload is validated against the YANG schema; a payload written for one model family cannot be assumed to work against another. In design terms, the model family should be selected after confirming device software release support, feature coverage, operational-state requirements, and vendor diversity. Open models give portability; native models give feature completeness. Reference topics: IETF YANG, OpenConfig YANG, Cisco native YANG, schema validation, automation model selection.

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.