I doubt that HSRP is doing anything that is causing this problem. There is not quite enough information here to know for sure the source of the problem, but I do have a guess at it. I am guessing that in normal operation (when OSPF is running through MPLS) the tunnel destination is advertised through OSPF and the tunnel works. But I am guessing that when OSPF stops running through MPLS that either the tunnel destination is not advertised and is not reachable (which causes the tunnel to fail) or that the tunnel destination is advertised through RIP over the tunnel (which causes the tunnel to fail with a recursive routing problem).
You could do some things to verify whether my guess is correct: when OSPF is running over MPLS on the remote router with GRE tunnel do a show ip route for the tunnel destination address and do a traceroute from the remote router to the tunnel destination address. I suspect that the traceroute will go through the MPLS cloud to get to the tunnel end point. Then when OSPF is not running through MPLS do the show ip route and the traceroute. I suspect that either the traceroute has no route to the tunnel destination or that it is trying to go THROUGH the tunnel to get to the tunnel end point.
If that is not the cause of the problem then it might be helpful if you would post the configuration of the routers that have the tunnel.
One thing to check is that your tunnels end points (tunnel source/tunenl dest) do not get advertised though the tunnels.
You can get the problem of tunnel tring to form itself through itself.
In your case since OSPF has a better AD at the remote site it would override any rip routes learned. When the OSPF no longer has the route the rip routes are left. With 2 tunnels you can get all kinds of nasty senerios.
Thanks for posting the config info. It answers some questions and raises other questions.
I note that the tunnel end points are:
tunnel destination 10.10.1.1
tunnel destination 10.10.1.5
and I note that these addresses are covered by static routes:
ip route 10.10.1.1 255.255.255.255 22.214.171.124
ip route 10.10.1.5 255.255.255.255 126.96.36.199
static routes for the tunnel end points are one of the best ways to avoid problems with the tunnel recursive route problem (the problem where the router attempts to get to the tunnel end point through the tunnel) which is the issue that Tim and I both raised.
So it looks like you are protected from the recursive issue. But I would like to know what these static routes are doing. I see that the next hop address in the static route is 188.8.131.52 and that is in the connected subnet of FastEthernet0/1. But I do not see anything in the drawing or in your explanation that tells me what/where that is and what impact might be on it when MPLS fails. Can you clarify this?
Also as I suggested before it would be helpful to get the output of a traceroute from the router to the tunnel endpoint at a time when the tunnel is working and then from a time when the tunnel is not working.
Another note about tunnels: unless you have configured GRE tunnel keepalive (a recent feature in IOS) you can not depend on the interface state to tell you anything useful about a GRE tunnel. The router will report the tunnel as up/up so long as it believes that it has a route to the tunnel destination. The tunnel can be up/up and pass no traffic at all.
Question We run asr9001 with XR 6.1.3, and we have a very long delay to
login w/ SSH 1 or 2 to the device compare to IOS device. After
investigation, the there is 1s delay between the client KEXDH_INIT and
the server (XR) KEXDH_REPLY. After debug ssh serv...
Introduction The purpose of this document is to demonstrate the Open
Shortest Path First (OSPF) behavior when the V-bit (Virtual-link bit) is
present in a non-backbone area. The V-bit is signaled in Type-1 LSA only
if the router is the endpoint of one or ...
Hi, I am seeing quite a few issues with patch install and wanted to
share my experience and workaround to this. Login to admin via CLI, then
access root with the “shell” command Issue “df –h” and you’ll probably
see the following directory full or nearly ...