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
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?
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?