DMVPN Phase 3 - NHRP does not refresh

[mihaly.szuhanics]

Dear Engineers,

I am facing a very odd situation.

I have a DMVPN network based upon 2 Hubs.

One of the spoke sites, - let's call it Site A - I work on, have two routers sharing the two same hubs.

The other site which is involved in my issue is Site B.

The issue is that the NHRP registers on Site B that my Backup router has my local LAN network and not the Primary. However, as I clear the DMVPN sessions, the Site B router starts to learn the LAN subnet from the Primary VPN router.

I checked the config is identical on each and every spoke router, its based on a template. Each has the ip nhrp shortcut and both hubs have the ip nhrp redirect.

The last key thing to note, is that due to overutilization and not efficient Qos setup, the primary router had some minor disconnections and tunnel flaps. 

In case the primary goes down, when a remote spoke wants to reach out to the Site A's LAN range, it'll ask the HUB to send it the proper entry to reach the actual router on Site A that has the network, that will be in this case the back-up router.

But when the Primary comes up again, I would expect the hub to know that, and when a new query comes in from another spoke, it'll provide it with the actual setup and it'll receive the Primary router.

Here comes the question. If such flap happens, what triggers a remote spoke that already learned the Back-up router as the source of the Site A's LAN to ask for a new query and update it with the Primary router when it comes back online.

As for now, I can't seem to find anything and based on my understanding that is the purpose of Phase 3 to keep that update as long as its alive.

I am not asking for config review, but theoritical discussion. As for now, this causes asymmetric routing since even if the primary is up again, the back-up's address was updated at many spokes and they keep sending packets there.

Thanks for your inputs

[Georg Pauwen]

Hello,

can you post the configs ?

[paul driver]

Hello

humm.. I guess you think it should occur like that but if this is eigrp?

if it is eigrp providing the routing then  needs to update - your router will need to check its metrics for each destination  since it’s last valid check which would have been from the last active to passive state for that particular destination

after that any neighbors with a suggestive best path (lowest calculated distance ) need also to meet the eigrp feasibility condition which states it’s path to that particular destined is loop free

If this neighbor does meet the F.C. and has the lowest CD then good stuff you have a successor if not eigrp will go active for that destination.

so what I am trying to say with your flaky links eigrp  might not always be  converging  like you are expecting it to 

Have you tried increasing the hold-time for the flaky eigrp peer?

[mihaly.szuhanics]

Hi,

I have BGP communication between the hubs and the spokes not EIGRP. But the routing refreshed, I can clearly see on the HUB that the BU is not the only/best path anymore but the primary. However this does not reflect on the NHRP in some of the spoke routers.

My question is really, what would trigger a working spoke, that has already learned a prefix from the back-up, to forget it and replace it with the primary router's NHRP information. Since both are up and both respond.

As I read, the spoke has to request an inquiery but why would it do that if there is already an entry?

Thanks