On the Hub, could you remove the static route ip route 184.108.40.206 255.255.255.255 220.127.116.11. There's no use for this. You only need a static default pointing to your ISP IP.
For the VRF, if you're close to your Spoke site, then configure VRF locally. This is because you will loose IP configuration and connectivity as soon as you apply the VRF forwarding command on the WAN interface. If no chance of going to the Branch, then do the VRF at the Hub.
You would need to do the following:
1. Create a VRF with the vrf definition command and specify ipv4 unicast and multicast (I saw PIM configuration in your configs)
2. Remove the Crypto keyring and reapply with crypto keyring name vrf name
3. Reconfigure WAN interface with vrf forwarding command and reapply IP address
4. Configure static default with ip route vrf name 0.0.0.0 0.0.0.0 next_hop
5. Under the Tunnel interface configure tunnel vrf name
Also remove PBRs that you have at the Hub and Spoke. You can reapply when you're sure everything is working.
When done, do following:
1. Check ospf neighbors and route table
2. Ping from the Hub to the LAN gateway IP on the Spoke, which is I think is VLAN 2000. Use Hub tunnel as Source. This should pass.
2. Do same ping as 1 above, but this time use ping vrf. This should fail.
3. Repeat from the Spoke to the Hub
I didn't find any issue in shown output but I noticed that NHRE uptime and OSPF routes were learned 2 minutes ago. Is it flapping or administrator had made changes?
I'll continue working with the VRF but it looks like I will need to change the tunnel configuration also.
Yes the OSPF adjacency is flapping. I can ping the tunnel IP's but nothing else.
I found the issue. The branch router was learning the its WAN gateway through OSPF. Sure enough there is a static route for that IP pointing to a firewall. I added a static route on the branch router point to the WAN interface and that was it. I can now ping the router ID's. Now I have to figure out why that route was there in the first place. Thanks for your help everyone.
Good you found the error in the branch router, though I must say I'm surprised, as I had mentioned putting your WAN interface in a VRF pointing to your WAN gateway (18.104.22.168). Even though the VRF isn't necessarily required, the WAN gateway must never be in the internal dynamic routing configuration or be advertised as part of the internal networks.
I've just seem the same error message myself in a GNS3 lab while testing a DMVPN configuration. In my lab the DMVPN tunnel was going down as the eigrp hold time expired and then re-establishing.
The problem was caused by the routes to DMVPN end points (the tunnel sources and destinations) being determined by eigrp while the DMVPN was itself running eigrp. I replaced the eigrp routes with static routes and that solved the problem.
I think this was a case of recursive routing as the routes to the end points of the DMVPN were determined by eigrp to be over the DMVPN itself.
We suggest to open a new thread with your information and logs so easy to address as different issue, rather cross posting.
@balaji.bandi believes that you have a different issue. In that case a new discussion is appropriate. If you do have the same issue and a better solution then posting in the same thread is certainly appropriate.
its not about bothering, we love to hear your issue, if possible we suggest and put best effort answer what we can.
since every issue was different, so it easy to have more information provided in the new thread, so many people can give their views.
Hope this make sense ?
I was happy to see your first post in this community, and to see another solution suggested. I hope that you will give us another chance. But if this is in fact your last post with us then I wish you well as you pursue your career in networking and hop that you find some other forum in which you will feel more appreciated.