How DMVPN phase 2 establishes the spoke-to-spoke tunnel?

Hello

Regarding the spoke-to-spoke tunnel establishment in DMVPN phase 2, I went through Petr Lapukhov's post in http://blog.ine.com/2008/08/02/dmvpn-explained/ where in few words Petr showed that when a spoke wants to establish a tunnel with a remote spoke it will send NHRP Resolution Request to the NHS (hub) and the NHS will send the NHRP Resolution Reply based on its local NHRP cache mappings. The same will do for the destination spoke. The same behavior is also described by Brian McGahan in the DMVPN VoD from the CCIE Sec series.

Now what is interesting is that I did 2 tests in GNS3 and I used Wireshark to capture NHRP messages (I didn't configure IPsec in order to be able to see the NHRP messages). In the first test I used as routers Cisco 7200 with 15.1M image. The NHRP Resolution Request was sent by the spoke, but insted of the hub replying it was forwarding the request to the remote spoke. The remote spoke was sending an NHRP Resolution Reply back to the hub with a NHRP Resolution Request from his side towards the hub. The hub would forward the NHRP Resolution Request and Reply to the initiator spoke, the initiator spoke would send a NHRP Resolution Reply back to the hub and the hub would forward it to the destination spoke. So the hub was relying the requests and replies.


A second lab with 12.4(15)T images showed a third behavior (both labs exactly the same configuration as documentation in the DVMPN config guide).
The spoke1 (initiator) sends a NHRP Resolution Request to the hub. Again the hub doesn't reply directly, but forwards the request to the spoke2 (destination). The destination spoke will send the NHRP Resolution request directly to the spoke1 bypassing the hub completely.

So I see 3 different NHRP operations for DMVPN phase 2 depending on the IOS version.
Has anyone else tested DMVPN phase 2 and what kind of behavior you noticed?


Mikis

Comments

Sign In or Register to comment.