Troubleshooting Scenario Questions

BGP is not receiving any routes due to CoPP dropping updates.

Why it fails: The output shows one prefix marked valid and best, so updates are arriving; CoPP dropping updates would leave the received-routes table empty or stale. It tempts because CoPP does police BGP TCP/179, but that would be the diagnosis only when no prefixes appear at all.

BGP is receiving routes but not installing them in the routing table due to CoPP.

Why it fails: The prefix carries the > and * valid-best codes, meaning it was installed in the BGP table and passed to the RIB; a RIB-failure would show the r code instead. CoPP causing non-installation is correct only when routes appear with r or are missing from the routing table.

BGP session is flapping due to CoPP.

Why it fails: A flapping session would show the neighbour in Idle/Active or repeatedly reset, and received-routes would list nothing or reset counters; here the session is Established and passing one prefix. Flapping is the right conclusion only when neighbour state or uptime changes repeatedly.

The DHCPv6 server has assigned only an IPv6 address to the client.

Why it fails: The binding shows both an IA NA address (2001:DB8:1::100) and an IA PD delegated prefix (2001:DB8:1::/48), so address-only assignment is contradicted by the prefix entry. It is tempting because IA NA alone is the common case for hosts; prefix delegation applies when the client is a requesting router needing downstream subnets.

The DHCPv6 client is using stateless autoconfiguration (SLAAC) because no address is shown.

Why it fails: An address is present (2001:DB8:1::100), and SLAAC bypasses DHCPv6 binding state entirely, so no binding would appear. It is tempting because SLAAC also autoconfigures addresses, but it uses router advertisements, not the DHCPv6 server's binding table shown here.

The DHCPv6 server has a pool with only one prefix available.

Why it fails: The binding shows one client holding one IA_NA address and one IA_PD prefix; it says nothing about pool size or remaining prefixes, since bindings list active leases only. It tempts because a single prefix appears, but pool exhaustion would require checking pool configuration or statistics, not this per-client binding table.

The DHCPv6 relay agent is not functioning because messages are not being forwarded.

Why it fails: The debug shows SOLICIT, ADVERTISE, REQUEST and REPLY each forwarded in both directions, so relay is working end to end. This option would fit if messages arrived but no forwarding lines appeared, indicating a relay configuration fault.

The DHCPv6 server is unreachable because no REPLY is received.

Why it fails: The log shows a REPLY received from 2001:DB8:2::1 and forwarded to the client, so the server is demonstrably reachable and the four-message exchange completed. It is tempting because a missing REPLY is the classic signature of an unreachable DHCPv6 server, but that symptom would appear as repeated SOLICIT retransmissions with no ADVERTISE or REPLY.

The DHCPv6 client is using a global unicast address as its link-local address.

Why it fails: Every client message arrives from FE80::1, a link-local address, which is the expected source for DHCPv6 clients on the local segment. It is tempting because a client misconfigured with a global address as its link-local would look similar in a capture, but the FE80:: prefix here proves the address is genuinely link-local.

The prefix is learned via iBGP and is not the best path.

Why it fails: The output shows 'external' and 'best', meaning the path was learned via eBGP and selected as best, contradicting this option. It is tempting because iBGP paths also appear in the BGP table, but the external and best flags here rule that out.

The prefix is suppressed and not advertised to peers.

Why it fails: The entry shows 'best #1' and is advertised to update-group 1, so the prefix is selected and being advertised, not suppressed. It is tempting because route suppression does hide prefixes from peers, but no dampening or suppression state appears in this output.

The prefix is invalid due to missing next-hop reachability.

Why it fails: The output shows the path as valid and best, with no next-hop unreachability flagged, so the prefix is installed in the BGP table. It is tempting because a missing next-hop does invalidate a path, but that would appear as 'invalid' with the next-hop inaccessible, not as 'valid, external, best'.

The router is load-balancing between OSPF and EIGRP routes.

Why it fails: EIGRP's administrative distance of 90 beats OSPF's 110, so the OSPF route is deleted and only the EIGRP path remains installed. Load-balancing requires equal-cost paths from the same or configured sources; unequal distances prevent it. This debug would show two inserts only if both protocols had matching distances.

The OSPF route is preferred due to lower metric.

Why it fails: Administrative distance, not metric, decides here: EIGRP's 90 beats OSPF's 110, so the OSPF route is deleted despite its lower metric of 20. Metric comparison is the correct tie-breaker only when both routes come from the same protocol.

Both routes are installed in the routing table.

Why it fails: The OSPF entry is deleted after the EIGRP insert, leaving only the EIGRP path; the table holds one route, not two. It is tempting because both protocols initially inserted the prefix, but administrative distance resolves the conflict in EIGRP's favour.

OSPF adjacency is forming correctly, moving to FULL state.

Why it fails: The debug shows EXSTART with the neighbour reporting a larger interface MTU, so the adjacency stalls rather than reaching FULL; mismatched MTU blocks DBD exchange. This output would indicate healthy progression only if both interfaces shared identical MTU values and the state advanced past EXSTART.

OSPF adjacency is stuck because the router is not the DR/BDR.

Why it fails: DR/BDR status is irrelevant to EXSTART; the debug shows the neighbour has a larger interface MTU, so the master/slave negotiation stalls and DBD exchange cannot proceed. DR/BDR election occurs after two-way and does not block adjacency formation at EXSTART.

OSPF adjacency is stuck due to authentication mismatch.

Why it fails: The debug shows the neighbour reaching EXSTART then reporting a larger interface MTU, so the stuck adjacency stems from an MTU mismatch, not authentication. Authentication failures halt OSPF earlier, during hello exchange, producing 'authentication failure' messages; that is the scenario where this diagnosis would apply.

SNMP traps are sent to host 10.1.1.2 only.

Why it fails: The output lists two configured trap destinations, so traps are sent to both 10.1.1.2 and 10.1.1.3, not to 10.1.1.2 alone. It tempts because a single-host filter or `snmp-server host` entry with one address would produce exactly that behaviour, making one destination the correct reading in that narrower scenario.

The router is configured to receive traps from these hosts.

Why it fails: The `show snmp host` output lists trap *destinations* the router sends notifications to, not sources it accepts traps from. Inbound traps require no such host entry. It tempts because SNMP hosts are bidirectional in concept, and configuring a host for trap reception would be the right approach when the router itself acts as the SNMP manager.

SNMPv3 is used for trap communication.

Why it fails: The output lists Version 2c for both hosts, so SNMPv3 is not in use. SNMPv3 adds authentication and encryption via user-based security model (USM) credentials, which would appear as a username rather than a community string. It would be correct where trap integrity and confidentiality are required.

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 CoPP policy is dropping all traffic due to a misconfigured CIR.

Why it fails: Zero offered and zero violated packets mean no traffic is reaching the control plane policer at all, so nothing is being dropped by the CIR. The counters are tempting to read as drops, but a misconfigured CIR would show violated packets with drop actions.

The CoPP policy is working correctly and policing traffic at 1 Mbps.

Why it fails: Zero conformed and zero violated packets mean no traffic has matched the class, so nothing is being policed at 1 Mbps. This would be correct if counters showed conformed packets incrementing, proving the policy actively transmits within the CIR.

The CoPP policy is only applied to the output direction.

Why it fails: The command explicitly queries the control-plane input policy, and the header confirms the input direction, so the policy is not output-only. Output-direction policing is configured under a service policy on an interface egress; that would be the right check if drops occurred on outbound traffic.

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.