03-29-2004 06:11 AM - edited 02-21-2020 01:05 PM
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
03-29-2004 07:56 AM
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.
04-21-2005 12:22 PM
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 ??
04-22-2005 12:32 AM
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
04-22-2005 07:57 AM
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!@
05-05-2005 11:22 AM
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
04-22-2005 12:34 AM
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
04-22-2005 12:46 AM
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.
08-24-2017 05:45 PM
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
06-17-2018 12:40 AM
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. '
06-17-2018 07:01 AM
@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.
07-07-2019 01:11 PM
Thanks, that restored the hub -> spoke communications.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide