Refer to the exhibit. After applying IPsec, the engineer observed that the DMVPN tunnel went down, and both spoke-to-spoke and hub were not establishing. Which two actions resolve the issue? (Choose…

Question

Options

• AConfigure the crypto isakmp key cisco address 0.0.0.0 on R2 and R3.
• BRemove the crypto isakmp key cisco address 10.1.1.1 on R2 and R3.
• CChange the mode from mode transport to mode tunnel on R2.
• DConfigure the mode from mode tunnel to mode transport on R3.

• A
  73% (24)
• B
  6% (2)
• C
  6% (2)
• D
  15% (5)

Explanation

In DMVPN, spokes must dynamically establish IPsec sessions with each other (not just the hub), but spoke IP addresses are not known in advance. If R2 and R3 are configured with a specific hub IP key (e.g., 'crypto isakmp key cisco address 10.1.1.1'), they can only authenticate with the hub - not with other spokes. Adding 'crypto isakmp key cisco address 0.0.0.0' (the wildcard) allows spokes to authenticate with any ISAKMP peer, enabling dynamic spoke-to-spoke IPsec negotiation. Without this wildcard key, Phase 1 IKE fails for spoke-to-spoke paths because no matching pre-shared key exists, which is why all tunnels (including hub) may fail depending on the key lookup order.

No community discussion yet for this question.