Troubleshooting practice questions

The tunnel mode is multipoint, but the spokes need to be configured with 'tunnel mode gre ip' for direct communication.

Why it fails: 'tunnel mode gre multipoint' is required for DMVPN and is already correct; changing spokes to 'tunnel mode gre ip' would break the mGRE/NBMA design entirely. The option is tempting because point-to-point GRE tunnels do carry spoke-to-spoke traffic, but that static full-mesh approach is not DMVPN phase 2.

The spokes have different NHRP network IDs, preventing registration.

Why it fails: Mismatched NHRP network IDs would prevent registration, yet the hub already shows both spokes registered, so the IDs must match. The option is tempting because network-ID mismatch is a classic DMVPN fault, and it would be the cause if registration had failed rather than succeeded.

The IPv6 addresses on the tunnel interfaces are in different subnets.

Why it fails: DMVPN tunnel interfaces must share one subnet, and the stem gives no evidence of differing subnets; the hub already shows both spokes registered, which requires reachable tunnel addresses. The option is tempting because subnet mismatch does break spoke-to-spoke reachability, but it would also prevent the registrations already observed.

The route-target import on PE1 is misconfigured.

Why it fails: A wrong import route-target would stop the VPNv4 prefix entering the VRF table entirely, so it would not appear as best in the BGP table. Import route-targets are tuned when you need to control which VPN communities a VRF accepts.

The MP-BGP session is not using the loopback interface.

Why it fails: The 'r' flag denotes RIB-failure, meaning BGP could not install the prefix into the VRF routing table; MP-BGP peering over a loopback affects session stability, not RIB installation. Loopback sourcing is chosen when you need a peering address that survives interface failures.

The VRF on PE1 has a different route-target export.

Why it fails: A mismatched export route-target would prevent the prefix arriving at PE1 at all, yet the route shows as received and best. Route-target export is configured correctly when you want a VRF's prefixes advertised into a particular VPN community.

Spokes must be configured with the ip nhrp network-id command matching the hub.

Why it fails: The ip nhrp network-id command is used to identify the NHRP network. It must match on all routers in the same DMVPN cloud for NHRP to function. However, if the network-id mismatched, NHRP resolution would fail entirely, preventing even spoke-to-hub communication. Since the scenario states that spokes are unable to establish direct spoke-to-spoke tunnels but presumably can reach the hub, a network-id mismatch is not the likely cause. Thus, it is not a correct explanation for the specific issue.

The hub must be configured with the ip nhrp map multicast dynamic command.

Why it fails: The ip nhrp map multicast dynamic command is used on the hub to automatically add multicast mappings for spokes. It is commonly used for routing protocol multicast traffic, but it is not specific to Phase 3 operation. While it may be present in a DMVPN configuration, it does not enable or disable spoke-to-spoke shortcut tunnels. Therefore, its absence would not directly cause the failure of direct spoke-to-spoke tunnels in Phase 3.

The hub must be configured with the ip nhrp authentication command.

Why it fails: The ip nhrp authentication command is used to authenticate NHRP messages between peers. If authentication is misconfigured, NHRP resolution would fail, affecting all NHRP operations, not just spoke-to-spoke tunnels. While authentication is important for security, it is not a Phase 3-specific requirement for shortcut tunnels. The question asks for statements that describe correct Phase 3 operation that could explain the issue; authentication is not specific to Phase 3. Hence, it is not a correct choice.

The OSPF route is a type 5 LSA, which has a higher AD than type 3 LSAs.

Why it fails: LSA type does not set administrative distance; OSPF's AD of 110 applies to all OSPF-learned routes regardless of LSA type. Type 5 LSAs carry external prefixes, but that does not raise their AD above EIGRP external's 170. LSA types describe flooding scope and origin, not preference.

The OSPF route has a metric of 20, while the EIGRP route has a metric of 2560.

Why it fails: Metrics are only compared between routes of the same protocol; EIGRP's 2560 and OSPF's 20 are never weighed against each other. Administrative distance decides first, and 170 exceeds 110. Metric tuning is the correct approach when selecting between two EIGRP paths, not across protocols.

The static route was redistributed with a route-map that sets the EIGRP metric to 1.

Why it fails: Setting the EIGRP metric to 1 does not alter administrative distance, so the external EIGRP route still carries AD 170 and loses to OSPF's 110. Route-map metric manipulation is used to influence EIGRP path selection among EIGRP routes, not to override a competing protocol's AD.

Two EEM applets are currently registered: one for syslog and one for timer.

Why it fails: History events record past triggers, not currently registered applets; registration is shown by show event manager policy registered. Two events fired once each, which does not establish that two applets remain registered on the device.

The OSPF-5-ADJCHG syslog event triggered an applet that executed a timer.

Why it fails: The history lists two independent events, each with trigger count 1; nothing shows the syslog event launching an applet that started the timer. Correlating a syslog trigger to an applet action requires the applet configuration, not this event history output.

The timer event is a countdown timer that triggered after 5 minutes and 23 seconds.

Why it fails: The output lists an absolute timer named MY-TIMER that fired at 00:06:00, not a countdown of five minutes twenty-three seconds; that figure is the syslog event's timestamp. Countdown timers appear as Timer Type: countdown, which this entry does not show.

IPv6 Source Guard is blocking inter-host traffic because the hosts' bindings are not in the binding table.

Why it fails: IPv6 Source Guard drops traffic whose source address lacks a binding-table entry, but it validates the source, not the destination, so it would not stop host-to-host pings between validly bound hosts. It is correct for preventing source-address spoofing, not for isolating hosts within a VLAN.

RA Guard is blocking Neighbor Advertisements between hosts.

Why it fails: RA Guard filters Router Advertisement and Redirect messages on access ports; Neighbor Advertisements between hosts are unaffected. It is the correct control for blocking rogue routers advertising on a VLAN, not for stopping Neighbor Discovery between hosts.

DHCPv6 Guard is blocking DHCPv6 messages between hosts.

Why it fails: DHCPv6 Guard filters server-to-client DHCPv6 messages on untrusted ports; it does not block host-to-host traffic, and these hosts may use static or SLAAC addresses anyway. It is the right control for stopping rogue DHCPv6 servers, not for inter-host reachability.

Check the EEM applet's script for errors.

Why it fails: Reading the script for syntax or logic errors only proves the code is valid, not that its frequent routing-table rewrites are causing the loss. Script inspection is the right step when an applet fails outright or throws execution errors, not when correlating trigger frequency with intermittent packet loss.

Use the 'show event manager statistics' command to see how often the applet is triggered.

Why it fails: Trigger counts alone cannot confirm the applet is rewriting routes during the loss windows; the statistics show frequency, not the routing impact. This command is the correct choice when validating whether an applet fires as expected after configuration, not for correlating route changes with packet loss.

Increase the logging level to debug to see more details.

Why it fails: Raising logging to debug increases output volume and CPU load without proving the applet alters the routing table; it shows more messages, not causation. Debug logging suits diagnosing protocol or adjacency errors, where the fault lies in message exchanges rather than a triggered script.

The OSPFv3 router ID is a 128-bit value derived from the highest loopback IPv6 address.

Why it fails: The OSPFv3 router ID is a 32-bit value formatted like an IPv4 address, not 128-bit, and it is not derived from an IPv6 loopback address. It must be manually configured or inherited from an IPv4 address. A 128-bit identifier describes the IPv6 address, not the router ID.

The 'ipv6 router ospf' command is used to enable OSPFv3 on an interface.

Why it fails: The 'ipv6 router ospf' command creates the OSPFv3 routing process in global configuration mode; interface participation requires 'ipv6 ospf <process-id> area <area-id>' under the interface. It is tempting because process creation is a genuine prerequisite, but that step alone leaves the interface without an OSPFv3 adjacency.

OSPFv3 uses the network type configured under the OSPFv3 process globally, not per interface.

Why it fails: OSPFv3 network type is configured per interface with 'ipv6 ospf network', not globally under the process; the stem's global claim contradicts IOS-XE behaviour. It is tempting because several OSPFv3 parameters, such as router-id and reference bandwidth, are indeed set process-wide, but network type is not among them.

The local router has a distribute-list out applied to the neighbor.

Why it fails: A distribute-list out filters routes the local router advertises to that neighbour, so the neighbour's topology table would be empty, not the local one. It is the correct tool for controlling what you send; here the local router is failing to receive, so the filter must be inbound.

The EIGRP metric weights are different on the two routers.

Why it fails: Mismatched K-values prevent the routers forming an adjacency at all, because EIGRP validates metric weights in hello packets. The stem states the adjacency is up, so weights already match. K-values are configured identically when you want a neighbour relationship to establish in the first place.

The local router has a route-map applied to the EIGRP process that is filtering all routes.

Why it fails: A route-map filtering all routes would remove them from the topology table, but the stem states the neighbour is listed with no routes, which points to a distribute-list or prefix filtering rather than route-map denial. Route-maps are tempting because they filter EIGRP updates, but they would be correct when specific routes are selectively blocked.

The relay agent R2 is missing the 'ip dhcp relay information option' command.

Why it fails: The relay information option inserts circuit and remote IDs for DHCP snooping and option 82 handling; it is not required for basic DISCOVER forwarding. It is tempting because option 82 relates to relayed DHCP, but R1's failure to respond stems from pool or giaddr matching, not missing option 82.

The DHCP pool on R1 is missing the 'default-router' command.

Why it fails: A missing default-router only omits the gateway address in the DHCP offer; it does not stop R1 from selecting a pool and replying. It is tempting because the client needs a gateway, but the symptom is no response at all, indicating pool selection failure.

The 'ip helper-address' on R2 should point to the server's loopback address, not the interface IP.

Why it fails: The helper address correctly targets the server's reachable interface, and giaddr is already being set, so redirecting to a loopback changes nothing. It is tempting because loopback addresses are stable, but reachability is proven by the successful ping.

The logging buffer is full and needs to be cleared.

Why it fails: A full logging buffer affects only buffered logging; it does not set the global 'Syslog logging: disabled' state, and clearing it would not re-enable message generation. It is tempting because buffer exhaustion does stop 'show logging' output, but the disabled status indicates logging was switched off, not that storage filled.

The router has run out of memory to generate syslog messages.

Why it fails: Memory exhaustion would degrade or drop messages, not set the explicit 'Syslog logging: disabled' flag, which is a configuration state. It is tempting because resource starvation can silence logging, but the displayed status points to logging being administratively turned off rather than a hardware constraint.

The 'logging host' command is missing, so no destination is configured.

Why it fails: A missing 'logging host' removes remote syslog forwarding only; the router would still generate and display messages locally, so 'Syslog logging: disabled' would not appear. It is tempting because absent destinations are a common syslog fault, but the disabled status reflects the global logging state rather than destination configuration.

The redistribute eigrp command under OSPF is missing the match external keyword.

Why it fails: Incorrect. The 'match external' keyword is not a valid option for the 'redistribute eigrp' command under OSPF. The correct command does not have such a keyword.

EIGRP has a higher administrative distance than OSPF, causing route suppression.

Why it fails: Incorrect. Administrative distance does not affect redistribution; it is used for route selection when multiple routes exist.

The OSPF process on R2 has a distribute-list blocking these routes.

Why it fails: Incorrect. While a distribute-list could block routes, it is less likely than the missing 'subnets' keyword, especially given the symptom of external routes not appearing.

The tunnel mode is incorrectly set to ipv6ip instead of 6to4.

Why it fails: The 'tunnel mode ipv6ip' command configures a manually operated IPv6-over-IPv4 tunnel that requires explicit tunnel source and destination IPv4 addresses. A 6to4 tunnel, in contrast, uses automatic address mapping and has no tunnel destination; setting the wrong mode would cause different encapsulation behavior, but the tunnel interface would still come up administratively. Since the question reports a non-functional 6to4 tunnel, the invalid private source address, not the tunnel mode, is the critical fault.

The tunnel destination is misconfigured with the remote router's IPv6 address instead of its IPv4 address.

Why it fails: 6to4 is fundamentally a point-to-multipoint mechanism; each router builds the outer IPv4 header based on the 2002::/16 prefix embedded in the destination IPv6 address. The 'tunnel destination' command is not used in 6to4 configuration and would be ignored or rejected by Cisco IOS, so any misconfiguration there cannot explain a down tunnel. The real issue is that the source interface's private IPv4 address produces an unusable 6to4 prefix.

The IPv6 address on the tunnel interface is not in the 2002::/16 range.

Why it fails: The IPv6 address assigned to the tunnel interface is a local, logical address and is not used to derive the 6to4 tunnel endpoints. 6to4 computes the next-hop and encapsulated IPv4 destination from the destination IPv6 packet's 2002:V4ADDR::/64 prefix, not from the interface's own address. Therefore, even if the tunnel interface holds an address in a different range, such as 2001:db8::1/64, it does not stop the tunnel from functioning; only a private source IPv4 address invalidates the prefix.

The NHRP authentication key is mismatched between the spokes.

Why it fails: NHRP authentication is enforced only between each spoke and the hub during registration and resolution, not between spoke peers. In DMVPN phase 2, a spoke sends its NHRP Resolution Request to the hub, which responds with the destination spoke's NBMA address, after which the initiating spoke sends a unicast GRE packet directly to that address. The destination spoke does not validate the source spoke's NHRP authentication key because no direct NHRP packet exchange occurs between them; any mismatch between spokes is therefore irrelevant to spoke-to-spoke connectivity. If the key were mismatched between a spoke and the hub, the spoke would fail registration entirely and the problem would be much broader than a single missing route.

The tunnel key is not configured on the mGRE interface.

Why it fails: The tunnel key is an optional 8-bit identifier used to validate GRE packets on a tunnel interface; when multiple GRE tunnels share the same underlay, all routers must either use the same key or none at all. If a spoke's mGRE interface lacks the tunnel key while the hub and the remote spoke use one, GRE decapsulation would fail for all traffic, including the hub communication, which is not the reported symptom. Conversely, if no router is configured with a tunnel key, spoke-to-spoke GRE packets are encapsulated and decapsulated normally because the key merely adds a check for matching IDs. The described failure is a data-plane routing issue to a specific internal network, which a missing tunnel key cannot cause because it would break all tunnel traffic rather than a single destination.

The hub is not configured with 'ip nhrp redirect' and the spokes with 'ip nhrp shortcut'.

Why it fails: The commands 'ip nhrp redirect' (on the hub) and 'ip nhrp shortcut' (on spokes) are fundamental to DMVPN phase 3, where the hub redirects a spoke to the destination spoke's NBMA address when it sees a packet routed from one spoke to another through the hub, and the source spoke installs a dynamic NHRP shortcut entry. In DMVPN phase 2, spokes already initiate NHRP Resolution Requests to the hub for any spoke-to-spoke traffic, and the hub replies with the mapped NBMA address, so the source can establish a direct tunnel without redirect assistance. Therefore, omitting these phase 3-specific commands does not affect phase 2 operation, and the failure described (missing static route to the remote internal network) is a routing-table problem, not an NHRP forwarding-mechanism issue.

The router's NVRAM has a hardware failure and lost the configuration.

Why it fails: While NVRAM can fail, a hardware failure would typically manifest during boot as a checksum error, an inability to access the configuration, or a router that cannot properly start. In this scenario, the router rebooted cleanly and reported that startup-config is 'not present', which more directly points to an empty NVRAM because the running configuration was never saved. NVRAM failures are rare and usually accompanied by other symptoms, making this explanation far less plausible than a simple administrative oversight.

The 'boot system' command points to a TFTP server that also contains a configuration file, overwriting the local startup-config.

Why it fails: The 'boot system' command only tells the router which IOS image or boot location to use, such as flash or a TFTP server; it does not manage configuration files. Overwriting the local startup-config would require the 'boot config' command, and even then the local NVRAM file would not be erased or replaced automatically. Therefore, a TFTP server with a configuration file cannot remove the local startup-config simply because 'boot system' points to that server.

The router's configuration register is set to 0x2142, ignoring startup-config.

Why it fails: Setting the configuration register to 0x2142 makes the router bypass startup-config during boot by ignoring NVRAM, but it does not delete or overwrite that configuration. The startup-config remains intact in NVRAM, so 'show startup-config' would still display the saved configuration rather than returning 'not present'. A 0x2142 register explains missing running-config after reload, but not a missing startup-config file.

The route has a low local preference of 100.

Why it fails: Local preference 100 is the default value, so it cannot be the fault here; the genuine anomaly is the 'Not advertised to any peer' line, meaning no outbound filtering or session is propagating it. Local preference manipulation only matters when comparing multiple paths, and this route has just one.

The next hop 10.1.12.2 is unreachable.

Why it fails: The output marks the path 'valid', which confirms the next hop resolved successfully in the RIB, so reachability is not in question. Next-hop validation is the correct check when a path shows 'inaccessible', but here the real anomaly is the 'Not advertised to any peer' line.

The route is not installed in the routing table.

Why it fails: 'Best' plus 'valid' and 'table default' confirms the route was selected and installed in the routing table. Checking installation is the right instinct when a path is marked 'not best' or filtered, but this entry is already active and forwarding.

Configure the host to use DHCPv6 to obtain an address so that the binding is learned via DHCPv6 snooping.

Why it fails: The host already holds a static address, so DHCPv6 snooping cannot populate a binding for 2001:db8:2::20; the address would change. DHCPv6 snooping suits hosts configured to obtain addresses dynamically rather than manually assigned static ones.

Add a static binding entry for the host in the IPv6 binding table using the 'ipv6 neighbor' command.

Why it fails: 'ipv6 neighbor' populates the neighbour cache, not the IPv6 Source Guard binding table, so the drop persists. That command is correct for resolving link-layer address mappings, not for authorising a static address against source guard.

Disable IPv6 Source Guard on the port connected to the host.

Why it fails: Disabling IPv6 Source Guard removes the filtering that drops the traffic, but the stem explicitly requires resolution without disabling it. The feature exists to validate source addresses against the binding table, so it would be the right approach only where that verification is genuinely unwanted, not where a missing binding entry simply needs creating.

Add the 'set ip default next-hop' command to the route map.

Why it fails: 'set ip default next-hop' only applies when no explicit route exists in the routing table, so adding it would not fix a policy that is failing entirely. It is tempting because it is legitimate PBR syntax, and would be correct when you want PBR to act only as a fallback for destinations lacking a specific route.

Change the route map to use 'set interface' instead of 'set ip next-hop'.

Why it fails: Changing to 'set interface' alters the forwarding action rather than isolating the fault; the policy is failing entirely, so the next-hop syntax is not yet the proven cause. It is tempting because 'set interface' is valid PBR syntax, and would be the correct choice when the next hop is a point-to-point interface without a resolvable address.

Apply the route map to the outgoing interface instead of the incoming interface.

Why it fails: PBR is applied to the incoming interface to intercept traffic before normal routing; moving it to the outgoing interface changes the design rather than isolating the fault. It is tempting because interface policy placement matters, and outgoing application would be correct for locally generated traffic via 'ip local policy route-map'.

Check if the route is being summarized on R2.

Why it fails: Summarisation on R2 would hide the specific prefix, but the stem says R2 holds the route and R1 sees no topology entry at all, which points to a filtering or distribute-list issue rather than aggregation. Summarisation is the right check when R1 receives a covering summary instead of the exact prefix.

Check if the EIGRP metric for the route is too high.

Why it fails: An excessively high metric would still install the route in the topology table as a feasible successor candidate; it would only affect best-path selection. The stem shows no topology entry whatsoever, so the route is being suppressed before metric comparison, for example by a distribute list or prefix filter.

Check if the route is a connected route on R2.

Why it fails: A connected route on R2 is still redistributed or advertised into EIGRP if configured, so its origin does not by itself prevent R1 from receiving it. This check is tempting when verifying redistribution, but the missing topology entry on R1 indicates filtering or summarisation, not the route's source type.