Hard Difficulty Questions

The ACL is filtering NHRP packets, preventing spoke-to-spoke resolution.

Why it fails: NHRP resolution succeeds, so NHRP packets are not blocked.

The spoke has a misconfigured NHRP authentication key.

Why it fails: Authentication mismatch would prevent NHRP registration, but resolution succeeds.

The ACL is applied outbound, filtering outgoing traffic.

Why it fails: Outbound ACL would affect traffic leaving the spoke, not incoming spoke-to-spoke traffic.

The tunnel mode is mGRE, but the spokes are configured with point-to-point GRE tunnels.

Why it fails: The hub runs mGRE, and spokes must also use mGRE to build dynamic spoke-to-spoke tunnels via NHRP; point-to-point GRE spokes cannot form the multipoint mapping. The stem's symptom of no dynamic sessions fits a missing spoke-side NHRP configuration or registration, not tunnel mode mismatch on the spokes.

The NHRP network-id is different on R2 and R3, preventing communication.

Why it fails: The hub's configuration shows only network-id 1, and NHRP requires matching network-ids for spokes to register and resolve each other; a mismatch on R2 or R3 would indeed block entries. However, the stem gives no evidence of differing network-ids, so this is speculative rather than the demonstrated root cause.

The tunnel source interface is not reachable between spokes.

Why it fails: Spoke-to-spoke tunnels are built directly between spoke public addresses using NHRP-resolved NBMA addresses, so the hub's tunnel source reachability is irrelevant to that path. The stem shows R3 has no NHRP entry for R2, indicating a registration or network-id problem rather than transport reachability.

VTP transparent mode prevents RSPAN from working correctly.

Why it fails: VTP transparent mode still propagates and supports RSPAN VLANs; it merely stops the switch participating in VTP domain advertisements. Transparent mode is the right answer when the question concerns local VLAN database independence from VTP server updates.

The source VLAN 50 is not allowed on the trunk ports.

Why it fails: VLAN 50 is the source, not the RSPAN transport; if it were disallowed on trunks, monitoring would fail entirely rather than intermittently. Verifying source VLAN trunk allowance is correct when no traffic reaches the destination at all.

The monitor session 2 is missing the 'no shutdown' command.

Why it fails: Monitor sessions and destination interfaces are enabled by default, so 'no shutdown' is not required; the intermittent symptom stems from VLAN 200 also serving as native VLAN on trunks, which strips or misforwards tagged RSPAN traffic. The command would matter only if the interface were administratively down.

OSPF traffic is being policed to 1000 pps, which is too high, causing CPU overload.

Why it fails: A higher rate allows more traffic, not less.

CoPP only works on hardware-switched platforms, not software.

Why it fails: CoPP works on both, but CPU impact varies.

The class-default should have a higher rate than the OSPF class.

Why it fails: There is no such requirement; the issue is the policing overhead.

The router with the larger MTU (1500) cannot process the smaller DBD packets from the neighbor.

Why it fails: Smaller packets are not a problem; the issue is larger packets being fragmented or dropped.

The OSPF network type is point-to-point, which ignores MTU mismatches.

Why it fails: Point-to-point networks still use DBD packets and are affected by MTU mismatch.

The 'ip ospf mtu-ignore' command is needed on both sides to bypass the MTU check.

Why it fails: This command can fix the issue, but the question asks for the explanation of the problem.

1 to 256

Why it fails: 256 is the limit for some older platforms, but modern IOS-XE supports up to 1023.

1 to 4096

Why it fails: 4096 is the VLAN range, not ERSPAN ID.

1 to 65535

Why it fails: 65535 is too large; ERSPAN ID is limited to 1023.

15

Why it fails: EIGRP's maximum hop count is 255, not 15; 15 is RIP's limit. It is tempting because 15 is the best-known routing protocol hop ceiling, but EIGRP uses a 24-bit metric with a default maximum hop count of 100, adjustable to 255.

255

Why it fails: EIGRP's maximum hop count is 255, but that limit applies to the hop count carried in the TLV, not to the metric calculation the question asks about. 255 is the theoretical ceiling, so it is tempting when recalling EIGRP's administrative distance or its protocol number 88.

Unlimited

Why it fails: EIGRP does not cap hop count at infinity the way RIP does; its metric is bandwidth- and delay-based, with 255 as the actual maximum. Unlimited is tempting because EIGRP has no hop-count limit in its metric, but the protocol still enforces 255.

The spoke routers have incorrect NHRP authentication, causing the mapping to be invalid.

Why it fails: Authentication mismatch would prevent NHRP registration, but the mapping exists.

The tunnel interface on R1 is not in the correct VRF.

Why it fails: VRF misconfiguration would cause other issues, but not specifically spoke-to-spoke failure with existing NHRP mapping.

The IPsec transform set is mismatched between spokes.

Why it fails: IPsec mismatch would prevent tunnel establishment, but the DMVPN session is up.

The authNoPriv security level uses encryption but no authentication.

Why it fails: authNoPriv uses authentication but no encryption; encryption is only in authPriv.

SNMPv3 always requires encryption for all security levels.

Why it fails: Encryption is optional; noAuthNoPriv and authNoPriv do not use encryption.

The 'priv' keyword in the snmp-server group command disables authentication.

Why it fails: The 'priv' keyword enables encryption, but authentication is still required.

The tunnel interface is not configured with 'ipv6 eigrp' under the interface.

Why it fails: The question states the interface is included in the EIGRP process, so this is not the issue.

The IPsec transform set does not allow multicast traffic, which EIGRP uses for hellos.

Why it fails: IPsec can encrypt multicast traffic; EIGRP hellos are sent to the multicast address FF02::A, which is encapsulated in the tunnel.

The GRE tunnel does not support EIGRP for IPv6; only OSPFv3 is supported.

Why it fails: GRE tunnels support any Layer 3 protocol, including EIGRP for IPv6.

Both paths are equally preferred, and BGP load-balances traffic.

Why it fails: The header states best #2, and only the second path carries the best flag, so BGP selects a single path rather than load-balancing. It is tempting because two valid paths exist, but equal preference requires identical attributes and multipath configuration, which this output does not show.

The path from AS 65002 is best because it has a higher local preference.

Why it fails: Both paths display localpref 100, so local preference does not differentiate them; the second path is best due to a later tie-breaker such as router ID. It is tempting because higher localpref does win selection, but here the values are identical.

The path from AS 65001 is best because it was received first.

Why it fails: The best path marker sits on the AS 65002 entry, not the first-received AS 65001 path; BGP selects on weight, then local preference, AS-path length, origin, MED and router ID, not arrival order. First-received would matter only for route dampening or oldest-path tie-breaking.

The DHCP pool is configured with 'lease infinite', causing bindings to be stored in a different database.

Why it fails: Incorrect: Infinite lease still creates bindings; they should appear.

The router's DHCP server is configured in 'database' mode, which stores bindings externally.

Why it fails: No such 'database' mode exists for the IOS DHCP server; bindings always appear locally once leases are granted. External storage is achieved by configuring a DHCP database agent or an external server, so this option misstates the mechanism entirely.

The clients are using DHCPv6, not DHCPv4.

Why it fails: DHCPv6 uses a separate binding table and stateful address assignment via DHCPv6, so no IPv4 bindings appear; the stem's IPv4 pool would still show leases if DHCPv4 clients were served. DHCPv6 would be the right answer when clients request stateful IPv6 addressing.

Router R1 is the DR and the neighbor is the BDR, so the state is correct.

Why it fails: Even if R1 is DR and neighbor is BDR, they should still form a FULL adjacency, not 2WAY.

The dead timer is about to expire, causing the neighbor to go down.

Why it fails: Dead timer is 00:00:38, which is not near zero.

The neighbor has a lower priority than R1, so it remains in 2WAY.

Why it fails: Priority does not affect the state progression beyond 2WAY; all routers should go to FULL with DR/BDR.

EIGRP uses multicast, and CoPP cannot police multicast traffic.

Why it fails: CoPP class-maps can match multicast destination addresses, and EIGRP multicast hellos are policed like any other control-plane traffic. The claim is tempting because multicast handling differs elsewhere, but policing rate, not multicast itself, causes the SIA.

CoPP only affects incoming traffic, but EIGRP SIA is caused by outgoing packet drops.

Why it fails: CoPP polices ingress traffic on the control plane interface, and EIGRP SIA arises from dropped inbound hello or update packets, not outbound ones. This option is tempting because SIA involves retransmissions, but those are triggered by missing inbound acknowledgements.

EIGRP uses TCP, and CoPP only polices UDP.

Why it fails: EIGRP is a protocol that runs directly over IP using protocol number 88, so it is neither TCP nor UDP; CoPP class-maps match it via IP protocol, not transport ports. The option is tempting because CoPP commonly polices TCP and UDP management traffic, but EIGRP's transport differs entirely.

The transform set uses ESP with null encryption.

Why it fails: ESP with null encryption authenticates packets but leaves payload plaintext, so the tunnel encrypts nothing. It is tempting because null encryption is a legitimate transform for integrity-only tunnels where confidentiality is not required, such as certain lab or compliance-testing setups.

The ISAKMP policy has the wrong authentication method.

Why it fails: A wrong ISAKMP authentication method (for example pre-shared key versus RSA signatures) prevents Phase 1 from completing, so the tunnel would not come up at all. It is tempting because authentication mismatches are a common IPsec fault, but they cause negotiation failure rather than plaintext traffic.

The pre-shared key is incorrect.

Why it fails: A mismatched pre-shared key prevents phase 1 or phase 2 completing, so the tunnel would not come up at all. It tempts because key errors are common IPsec faults, but here the tunnel is established while traffic passes unencrypted, pointing to a crypto ACL or interesting-traffic mismatch.

public

Why it fails: No SNMP community string exists by default on an unconfigured Cisco IOS device; SNMP is effectively disabled until snmp-server community is configured. 'public' is the conventional read-only string administrators choose, which is why it is tempting, but it is a common practice, not a factory default.

private

Why it fails: Cisco IOS ships with no SNMP community strings configured; 'private' is merely the conventional read-write string administrators assign, not a default. It tempts because 'private' pairs with 'public' in common documentation, but an unconfigured device rejects all SNMP queries until snmp-server community is entered.

cisco

Why it fails: 'cisco' is a widely used example community string in Cisco documentation and lab exercises, never a factory default. It tempts because it appears throughout configuration guides, but an unconfigured IOS device has no SNMP community defined at all, so no string grants access until explicitly configured.

Auto-summary is enabled by default and summarizes routes at classful boundaries.

Why it fails: IOS-XE disables EIGRP auto-summary by default, so it neither runs nor summarises at classful boundaries unless configured. The classful-summarisation description is tempting because auto-summary did behave that way on older IOS releases, and would be correct there rather than on current DMVPN tunnel interfaces.

Auto-summary is enabled by default but only for tunnel interfaces.

Why it fails: Auto-summary is disabled by default in IOS-XE EIGRP, and the feature is interface-independent, never scoped to tunnels alone. Restricting it to tunnel interfaces is tempting because DMVPN designs often tune summarisation there, and would be correct if the stem asked about manual summary-address configuration on tunnel interfaces.

Auto-summary is disabled by default but can be enabled only for DMVPN.

Why it fails: EIGRP auto-summary is disabled by default on IOS-XE and can be enabled on any interface, not restricted to DMVPN tunnels. It is tempting because DMVPN designs often discuss summarisation at the hub, but that concerns manual interface summary configuration, not a DMVPN-only auto-summary capability.

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.