02-21-2019 02:21 PM
Hey everyone I'm running into an issue with recursive routing and can't seem to figure out how to fix it. I have an IPSEC with GRE runnning OSPF. The tunnel comes up fine but OSPF is flapping. It appears that the route to the destination is via the tunnel itself which is an issue. I inflated the ospf cost of the tunnel interfaces but that didn't help. I also added in a static route to the tunnel destination on each router but that didn't help either. From what I've read in most cases this causes the tunnel to go down but in my case the tunnel stays up on both sides. Configs are attached.
02-22-2019 01:27 PM
On the Hub, could you remove the static route ip route 1.1.1.2 255.255.255.255 2.2.2.1. 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
02-22-2019 10:52 PM
Hi,
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?
Regards,
Deepak Kumar
02-25-2019 04:35 AM - edited 02-25-2019 04:35 AM
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.
02-25-2019 04:43 AM
02-25-2019 05:20 AM
That didn't help either. I'm going to open a TAC case. I'll let you guys know the results.
02-25-2019 11:44 AM
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.
02-25-2019 03:27 PM
greate and good to know it was worked finally, thank you feedback to your solution.
02-25-2019 08:51 PM
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 (2.2.2.1). 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.
07-12-2019 03:39 AM
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.
07-12-2019 04:32 AM
We suggest to open a new thread with your information and logs so easy to address as different issue, rather cross posting.
07-12-2019 06:33 AM
I thought I was discussing the same issue. I have a better solution. I'll not bother in future.
07-12-2019 07:49 AM
@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.
HTH
Rick
07-12-2019 08:27 AM
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 ?
07-15-2019 03:50 AM
07-15-2019 04:45 PM
Bill
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.
HTH
Rick
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: