Refer to the Exhibit Practice Questions

The engineer used 'ip default-network' which is not supported in EIGRP; instead, 'default-information originate' should be used.

Why it fails: Ly states that 'default-information originate' should be used for EIGRP. That command is for OSPF, not EIGRP. While 'ip default-network' is indeed not supported in EIGRP, the correct method is to redistribute a properly configured static default route, not to use 'default-information originate'. Therefore, this is not the most likely reason.

The internal routers have a route to the default network with a better metric from another source.

Why it fails: Internal routers are not receiving the default route at all, so they cannot have a route with a better metric from another source. This option describes a scenario where the route is received but not preferred, which does not match the problem.

The engineer needs to configure 'eigrp stub' on the router to allow default route advertisement.

Why it fails: Configuring 'eigrp stub' on the router would restrict route advertisement, not allow it. To advertise a default route from a stub router, you would need the 'summary' keyword, but the router is not necessarily a stub. This would not be the most likely reason for the failure.

Fabric border node

Why it fails: Fabric border nodes handle traffic entering and leaving the fabric, including connectivity to external networks and shared services. They do not maintain the endpoint-to-locator mapping database or provide the control plane for endpoint resolution. Their function is to translate VXLAN to external protocols, not to act as the mapping authority.

Fabric intermediate node

Why it fails: Fabric intermediate nodes are part of the underlay and simply forward VXLAN-encapsulated packets based on the outer IP header. They do not participate in the control plane for endpoint mapping or maintain any endpoint database. Their role is purely transport, so they do not fulfill the described requirement.

Fabric edge node

Why it fails: Fabric edge nodes are responsible for connecting endpoints to the fabric and encapsulating traffic into VXLAN. They query the control plane node for endpoint location information but do not maintain the authoritative mapping database themselves. The scenario asks for the component that maintains the mapping and provides the control plane, which is not the edge node's primary role.

NETCONF

Why it fails: NETCONF is used for configuration management and is supported by Cisco DNA Center for some devices, but it is not the primary protocol required for discovery and monitoring in this scenario. The switch would still need SNMP or another discovery protocol enabled for DNA Center to detect it. NETCONF alone would not make the device appear in the topology view.

Syslog

Why it fails: Syslog is used for sending event logs to a remote server, but it does not provide the device discovery and monitoring capabilities required by Cisco DNA Center. While syslog can be integrated for assurance, it is not the protocol that enables the device to be discovered and displayed in the topology. Enabling syslog alone would not resolve the issue.

IP SLA

Why it fails: IP SLA is used for network performance monitoring and threshold violations, not for device discovery. It allows tracking of delay, jitter, and packet loss but does not provide the management plane access that Cisco DNA Center needs to inventory a device. Enabling IP SLA would not make the switch appear in the topology.

Configure policy-based routing to match 192.168.1.0/24 and set the next hop to 10.0.0.1.

Why it fails: Configuring policy-based routing (PBR) would force traffic matching 192.168.1.0/24 to a specific next hop, effectively bypassing the OSPF routing table for that traffic. While this achieves a different forwarding path, it does not address the underlying issue of OSPF learning both routes with identical metrics, which could lead to undesirable load balancing or path selection for other traffic. PBR is typically employed when specific traffic flows require an exception to the standard routing table, such as for internet breakout or service chaining, rather than influencing the routing protocol's path determination itself.

Use the 'distance ospf' command to change the OSPF administrative distance for all routes.

Why it fails: The 'distance ospf' command globally changes the administrative distance for all OSPF routes (or for intra-area, inter-area, and external routes as a group), so it would alter the preferred path for every OSPF prefix, not just 192.168.1.0/24. This broad change can unexpectedly shift traffic for many other destinations and may introduce suboptimal path selection or routing instability. Since both routes to 192.168.1.0/24 are OSPF routes, changing OSPF's AD cannot selectively break the tie between them.

Adjust the OSPF cost on the interface to 10.0.0.2.

Why it fails: Adjusting the OSPF cost on the interface toward 10.0.0.2 changes the metric for all routes learned via that interface. If both 192.168.1.0/24 routes are advertised by the same neighbor (or learned over the same interface), the cost change applies equally to both, leaving them still equal-cost and load-balanced. Even if they come from different neighbors, modifying a single interface cost would only affect the route advertised over that interface, but the given scenario indicates both are via the same neighbor, so no differentiation occurs.

Inter-area (IA)

Why it fails: Incorrect. Inter-area routes (IA) are OSPF routes that originate in one area and are advertised to another area, but they are not external routes. A default route redistributed from outside the OSPF domain is an external route, not an inter-area route.

NSSA external type 2 (N2)

Why it fails: N2 routes are OSPF external routes originating only in not-so-stubby areas (NSSA), where the ASBR injects them as type 7 LSAs. The exhibit depicts regular OSPF areas rather than an NSSA, and the default route is being redistributed or originated by standard commands, so it cannot be classified as an N2 route.

External type 1 (E1)

Why it fails: E1 routes require explicit configuration with metric-type 1 and include the internal cost from the local router to the ASBR in addition to the external metric. The exhibited default route carries the characteristic E2 seed metric of 20 and shows no accumulation of internal path cost, so it cannot be an E1 route.

Enable Loop Guard on all access ports.

Why it fails: Loop Guard is incorrect because it is designed to detect the absence of BPDUs on a port that is expected to receive them, typically a root port or designated port, and then transition the port to a loop-inconsistent state. It does not take action on receiving a BPDU; rather, it prevents alternate paths from forwarding when BPDUs are lost due to unidirectional link failures, so it cannot block an unauthorized switch that actively sends BPDUs.

Enable Root Guard on all access ports.

Why it fails: Root Guard is incorrect because it only protects the placement of the root bridge by placing a port into a root-inconsistent state when a superior BPDU is received, preventing that port from becoming a root port. The port remains administratively up and still processes BPDUs; it simply stops forwarding on that port while the superior BPDU is present, which does not disable the port or permanently block an unauthorized switch from causing a loop.

Enable UDLD on all access ports.

Why it fails: UDLD is incorrect because it addresses physical unidirectional links by exchanging protocol frames with the neighbor and, upon a missing acknowledgment, either errdisables the interface or reports an undetermined state. It does not examine BPDUs and has no mechanism to detect or prevent a rogue switch from injecting BPDUs into the spanning tree, so it is irrelevant to the scenario of an unauthorized switch causing a loop.

One route has a higher administrative distance.

Why it fails: Administrative distance is a per-protocol preference value; all OSPF routes, including external types like E2, have the same AD of 110 on Cisco devices. For two routes to be considered equal-cost candidates for the same prefix, they must have identical AD and equal metric. A difference in AD would cause the route with the lower AD to be installed and the other ignored, not shown as an alternative. Therefore, the exhibited equal-cost routes cannot be differentiated by administrative distance.

A default route is overriding the specific route.

Why it fails: A default route is a prefix of 0.0.0.0/0 that is only used when no more specific prefix matches the destination IP. In the routing table, a specific route to the destination always wins over a default route regardless of metric or administrative distance due to longest-prefix-match. The exhibit clearly lists two routes to a specific network, not a default route; there is no default route shown, and even if one existed, it would not influence the selection between two specific routes. Hence, a default route is not overriding the specific route.

The route via 10.0.2.2 is an E1 route.

Why it fails: The routing table in the exhibit explicitly labels both entries as E2, indicating OSPF external type 2 routes. E1 and E2 differ fundamentally: E1 metric includes the internal cost from the router to the ASBR, while E2 metric is the ASBR-advertised external cost alone. If one route were E1, its metric would be larger by the internal cost and it would not share the same metric value for equal-cost load balancing. Since the label and the equal shown metric confirm both are E2, the route via 10.0.2.2 cannot be an E1 route.