question about DMVPN crypto session initiation

[west33637]

in a spoke to spoke dmvpn, why is it that the crypto session can only be initiated by the spokes? Is it that IKE authentication can only be initiated from the spoke? Why not the hub? they are both using wild card preshared keys.

I can understand in an IPSEC direct encapsulation hub and spoke scenario where the spoke is statically defining the IKE peer address and defining interesting traffic. The hub uses a wild card psk and does not define interesting traffic so therefore cannot initiate the crypto session.

but in a hub and spoke dmvpn, with spoke to spoke capability (both running mGRE) why is the spoke the only one that can initiate a crypto session? I know that the spoke has static NHRP mappings to the Hub outside address, but the hub should also have all the NHRP mappings to the spokes in its NHRP cache. shouldnt it therefore be able to initiate ike authentication?

Thanks

[Federico Coto Fajardo · Accepted solution]

Hi,

The DMVPN hub has no NHRP mapping information (only when the session is up).

The spokes do have configured the hub as the NHRP server.

Federico.

[west33637]

Hello Fredrico. Thanks for the quick response. So you are saying that if there is no traffic from the branch office over time, and the IPSEC SA gets torn down, the Hubs NHRP cache will age out and traffic will need to be initiated from the spoke?

Also, when a spoke configured for DMVPN is first powered up and connected to the network, does it automatically start trying to register to the NHS server? Is this when the IKE and IPSEC negotiation occurs using the static mapped address in the spoke NHRP cache?

[west33637]

Hello Frederico. I think I found the answer to all my questions from the excerpt below. Thanks for your help.

Next Hop Resolution Protocol (NHRP), defined in RFC 2332, is a Layer 2 address resolution protocol and cache, like Address Resolution Protocol (ARP) and Frame Relay Inverse-ARP. NHRP is used by a branch router connected to a non-broadcast, multi-access (NBMA) sub-network to determine the IP address of the "NBMA next hop"; in this case, the headend router or the destination IP address of another branch router.

When a branch router is first established onto a DMVPN network, it registers its IP address with the headend router whose IP address is already pre-configured on the branch router. This registration enables the mGRE interface on the headend router to build a dynamic tunnel back to the registering branch router without having to know the branch tunnel destination through a CLI configuration. NHRP maps a tunnel IP address to an NBMA IP address. NHRP tells the mGRE interface where to tunnel a packet to reach a certain address. When the packet is encapsulated in the mGRE packet, the IP destination address is the NBMA address.

Branch routers must be configured with the NBMA address of the headend router as their next hop server (NHS) to register with the headend router. The branch routers send a registration to the headend router that contains the tunnel IP address and the NBMA address. The headend router creates an entry in its NHRP cache and returns a registration reply. The branch router now views the headend router as a valid NHS and uses it as a source to locate any other branches and networks in the NHRP domain