DMVPN - Problem with NHRP

[ovt]

Hi!

Does anybody know how frequently cisco routers do NHRP registrations? It seems the frequency is critically important to properly bootstrap mGRE.

It seems that the hub router doesn't create NHRP mappings until spoke registers (both multicast and unicast mappings). As a result EIGRP adjacencies are not formed.

Could anybody provide details about NHRP registration process?

The config (IOS 12.3):

! R5 - Hub

interface Loopback0

ip address 15.x.x.x.x.255.0

!

interface Tunnel0

ip address 111.x.x.x.255.255.0

no ip redirects

ip mtu 1436

ip nhrp authentication cisco

ip nhrp map multicast dynamic

ip nhrp network-id 1

no ip split-horizon eigrp 50

tunnel source Loopback0

tunnel mode gre multipoint

tunnel key 1

! R6 - Spoke (one of them)

interface Loopback0

ip address 15.x.x.x.x.255.0

!

interface Tunnel0

ip address 111.x.x.x.255.255.0

no ip redirects

ip mtu 1436

ip nhrp authentication cisco

ip nhrp map 111.x.x.x.5.5.5

ip nhrp map multicast 15.xx.5.5

ip nhrp network-id 1

ip nhrp nhs 111.x.x.5

tunnel source Loopback0

tunnel mode gre multipoint

tunnel key 1

[ovt]

To clarify the question a bit: the problem with NHRP is that when the Hub router is rebooted or "clear ip nhrp" is issued on the Hub it sends "Resolution request" messages, but Spokes do not replay.

This makes the DMVPN technology useless, because the Hub had to be statically configured with all the Spokes IP addresses:

interface Tunnel0

ip nhrp map 111.111.111.6 15.6.6.6

ip nhrp map 111.111.111.13 15.13.13.13

ip nhrp map multicast 15.13.13.13

ip nhrp map multicast 15.6.6.6

IOS 12.3(3c) - Hub, 12.3(6) - Spokes.

[thisisshanky]

Oleg,

Your post was over an year ago. This problem should have been fixed. I am experiencing the same problem with 12.3.14T code. Clear ip nhrp, kills the tunnels,but they dont re-register back for a long time. Did you find a fix for this, without having to hardcode spoke addresses at the hub. It becomes dirty if the only work around is to hardcode the NHRP mappings at the hub and the spokes use dynamic IPs. Why use DMVPN ??

[ovt]

My guess is that nobody opened a case to fix this (nobody uses DMVPNs?). As a workaround try to reduce ip nhrp holdtime on all routers (the default is 7200 = 2 hours). This should affect frequency of registrations on spoke routers (with the default 2 hours they register every 1/3 of holdtime = 40 min.). Unfortunately (fortunately?) this should also affect lifetime of dynamic spoke-to-spoke tunnels (specificaly idle lifetime, not absolute one). Also, look at CSCed64463.

Please, drop me a line if you find a better workaround or open a case :)

HTH

Oleg Tipisov,

REDCENTER,

Moscow

[thisisshanky]

My hold times, were set to 360 (which is 6 minutes) which is shorter than the recommended 1/3rd of hold time.

I accidentally cleared the NHRP mappings at the hub yesterday (This is all in a test bed). and NHRP wont work any more. I saw that ASK the EXPERTS section on IPSEC and SSL VPN. I will post my question there.

Thanks for your input!@

[byamamoto]

I'm not sure, but I think I'm having similar problems. I have three Cisco1711 spokes running 12.2(2)XF. Two of the three spokes drop periodically and do not recover unless they are reloaded. Unfortunately, my lab 1711 does not drop so I cannot recreate the problem of the other two. (Physical access to the other two 1711s is limited.) The only difference between all three is the lab uses DSL and the other two use cable.

I wanted to know if the IOS upgrade resolved your problem. If it did what version are you running? I'll probably upgrade DRAM and try that before switching from cable to DSL.

Thanks,

Bryan

[ovt]

My guess is that nobody opened a case to fix this (nobody uses DMVPNs?). As a workaround try to reduce ip nhrp holdtime on all routers (the default is 7200 = 2 hours). This should affect frequency of registrations on spoke routers (with the default 2 hours they register every 1/3 of holdtime = 40 min.). Unfortunately (fortunately?) this should also affect lifetime of dynamic spoke-to-spoke tunnels (specificaly idle lifetime, not absolute one). Also, look at CSCed64463.

Please, drop me a line if you find a better workaround or open a case :)

HTH

Oleg Tipisov,

REDCENTER,

Moscow

[ovt]

BTW, I noticed Ask the Expert session titled "Deploying and Troubleshooting IPSec and Secure Socket Layer (SSL) Based VPNs". The session starts on Apr, 25. So, your question should definetely go there. In general, NHRP is very poorly documented protocol. Using it as a basis for such important thing as VPN is very risky to say the least. Registration/resolution/caching(!) in NHRP must be carefully documented by cisco.

[KennyPerez]

Folks, while I was replicating a CBT Nuggets lab for DMVPN, I decided to clear the sessions for the nhrp "clear ip nhrp"and came across this discussion. Then I tried building the lab again on GNS3 and worked around the issue by clearing the nhrp on my HUB router. Then by trying diferent stuffs, I finally figured it out by just deleting the entire Tunnel interface on my peer router after clearing my arp-cache and ip arp on both piece of equipment. Hopefully this can help should you still have any issues with this subjet.

Kenny,

CCNP 

[Cliffie22]

I know this reply is really late. But on the spoke you need to run ip nhrp registration timeout 5 

This will automatically re register after the hub nhrp is cleared or the hub router reboots. '

[Marvin Rhoads]

---

@Cliffie22 wrote:

I know this reply is really late. But on the spoke you need to run ip nhrp registration timeout 5 

This will automatically re register after the hub nhrp is cleared or the hub router reboots. '

---

Yes - 14 years after the original posting is a bit late. Ha ha.

Thanks for adding the nugget though - perhaps it will assist a future seeker.

[muktar]

Thanks, that restored the hub -> spoke communications.