Hard Difficulty Questions

Inbound

Why wrong: No default direction; the keyword is mandatory.

Outbound

Why wrong: No default direction; the keyword is mandatory.

The command defaults to inbound.

Why wrong: Cisco IOS requires explicit direction.

The transform-set does not support HTTP traffic due to port filtering.

Why wrong: Transform-set defines encryption and authentication algorithms, not traffic selection.

The IPsec SA is only established for ICMP; other traffic requires a separate SA.

Why wrong: The SA is triggered by the ACL; if the ACL is narrow, only matched traffic creates SAs.

The router has a NAT rule that bypasses IPsec for HTTP traffic.

Why wrong: NAT can interfere, but the question does not mention NAT.

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

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

The spoke has a misconfigured NHRP authentication key.

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

The ACL is applied outbound, filtering outgoing traffic.

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

R2 has a loopback interface that is not advertised via EIGRP, so R1 cannot reach it.

Why wrong: The issue is LDP session establishment, not reachability to the loopback.

R1 has an ACL that blocks LDP UDP packets (port 646).

Why wrong: No ACL is mentioned.

R2's 'force' keyword causes it to use the loopback even if it is not reachable.

Why wrong: The 'force' keyword ensures the router-id is used, but it does not cause failure.

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

Why wrong: Spokes typically use mGRE as well; if they used p2p GRE, they would only connect to the hub, but the scenario does not indicate this.

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

Why wrong: The network-id must match, but the scenario shows it is 1 on the hub; if spokes had different IDs, they would not register.

The tunnel source interface is not reachable between spokes.

Why wrong: Spoke-to-spoke reachability is established via NHRP; if NHRP is not working, the tunnel source may be reachable but the tunnel itself fails.

The customer's default route causes asymmetric routing, which breaks strict mode.

Why wrong: Asymmetric routing is a problem for strict mode, but the issue here is missing route for the source IP.

The uRPF mode should be loose mode to allow the default route.

Why wrong: Loose mode only checks that a route exists, not the interface, but the question specifies strict mode.

The router has an ACL that is blocking the traffic before uRPF checks.

Why wrong: uRPF is applied before ACLs, so ACL is not the cause.

The ACL is applied outbound, so it filters OSPF routes being sent to the neighbor.

Why wrong: Outbound ACL would affect outgoing updates, not incoming learning.

The router has a static route for the prefix with AD 1.

Why wrong: Static route would override both, but the question does not mention static.

The OSPF process has a distribute-list that is filtering the route.

Why wrong: Distribute-list would filter the route from the routing table, but the ACL is the configured filter.

The spoke's 'ip nhrp shortcut' command is missing on the tunnel interface.

Why wrong: Incorrect because the engineer verified that 'ip nhrp shortcut' is enabled.

The spoke's routing table has a static route to the remote spoke's LAN via the hub.

Why wrong: Incorrect because a static route would not prevent shortcut creation; the redirect is still needed.

The hub's tunnel interface has 'no ip nhrp redirect' configured.

Why wrong: Incorrect because the engineer verified that 'ip nhrp redirect' is enabled.

The route map uses a prefix-list that does not match the spoke's subnet.

Why wrong: Even if matched, the next-hop would still be the hub's tunnel IP.

The spoke routers have NHRP authentication mismatch, preventing direct communication.

Why wrong: NHRP authentication affects registration, not route next-hop.

The tunnel mode is mGRE on the spokes, which does not support spoke-to-spoke.

Why wrong: Phase 2 supports spoke-to-spoke with mGRE.

The spoke is missing the ip nhrp shortcut command under Tunnel0.

Why wrong: While the spoke also needs this command, the hub's missing redirect is the primary cause here.

The tunnel mode should be gre multipoint on the spokes.

Why wrong: Spokes can use point-to-point GRE tunnels; multipoint is only required on the hub.

IPv6 NHRP is not supported on DMVPN phase 3.

Why wrong: IPv6 NHRP is supported on DMVPN phase 3 with appropriate configuration.

The VRF names must match for OSPF to form neighbors.

Why wrong: Incorrect: VRF names are local; OSPF process is per VRF, but network type mismatch is the issue.

The OSPF process ID must be the same on both routers.

Why wrong: Incorrect: OSPF process ID is local and does not need to match.

The interface must be configured with the same IP subnet mask.

Why wrong: Incorrect: While IP subnet mismatch can cause issues, the primary problem here is network type mismatch.

Configure 'no logging trap debugging' globally.

Why wrong: Incorrect because this would change the global trap level, affecting all logging destinations including local buffer if not overridden.

Use 'undebug all' to stop all debug output.

Why wrong: Incorrect because this stops debug generation entirely, which may not be desired for local troubleshooting.

Set 'logging buffered 4096 notifications' to limit local buffer to severity 5.

Why wrong: Incorrect because this would reduce local logging detail, which the engineer wants to preserve.

Define the applet using the 'event manager policy' command instead of 'event manager applet'.

Why wrong: Incorrect. 'event manager policy' is used for Tcl policies, not CLI applets.

Add an 'event syslog pattern "WRITE"' to detect the write memory operation.

Why wrong: Incorrect. The syslog message for 'write memory' does not contain 'WRITE' consistently; using 'event cli' is more reliable.

Include an 'action cli command "enable"' before the copy command to ensure privileged access.

Why wrong: Incorrect. The applet inherits the privilege level of the user who triggered it; an explicit 'enable' is not required and may cause issues.

The time-range is applied to the entire ACL, not individual ACEs.

Why wrong: Incorrect. The time-range is referenced per ACE using the 'time-range' keyword, so each ACE can have its own time constraint.

If the router's clock is not set, the time-range will be considered active at all times.

Why wrong: Incorrect. If the clock is not set, the time-range is considered inactive, and the ACE will not match any traffic.

The time-range feature can only be used with extended named ACLs, not standard ACLs.

Why wrong: Incorrect. Time-ranges can be used with both standard and extended ACLs, as long as the ACL is named (not numbered).

15

Why wrong: Incorrect. 15 is the maximum hop count for RIP, not EIGRP.

255

Why wrong: Incorrect. While some implementations allow 255, the standard maximum is 224.

Unlimited

Why wrong: Incorrect. EIGRP has a hop count limit of 224.

The 'default-metric' command was not configured, so the routes are redistributed with an infinite metric.

Why wrong: Infinite metric would show the route in passive state but not installed.

The OSPF routes are external type 2, which are not redistributed by default.

Why wrong: OSPF external routes are redistributed by default.

The 'route-map' used for redistribution has a 'match ip address' that does not match the OSPF routes.

Why wrong: If route-map denies, the route would not appear in topology table.

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

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

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

Why wrong: 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 wrong: IPsec mismatch would prevent tunnel establishment, but the DMVPN session is up.

The metric-type 1 should be type 2 to avoid loops.

Why wrong: Metric type does not prevent loops; filtering does.

The EIGRP metric values are incorrect; they should match OSPF cost.

Why wrong: Metric conversion is not the root cause of loops.

The subnets keyword is missing in the redistribute command for OSPF.

Why wrong: The subnets keyword is present; missing it would cause classful redistribution, not loops.

R1 has a stuck interface causing the SIA.

Why wrong: SIA is due to query/reply issues, not interface state.

EIGRP is misconfigured with wrong autonomous system number.

Why wrong: AS number mismatch would prevent neighbor formation.

The route 10.0.0.0/24 is flapping, causing continuous queries.

Why wrong: Flapping can cause SIA, but the summary is the direct cause here.