GRE tunnel problem

I have used tunnels several times and I have not seen this... However, those always were tunnels with "tunnel protection ipsec .." That should not matter, I think. I don't use the "keepalive 10 3" but I do use eigrp over the tunnel to build routes. This seems to work fine.

No idea why it does not work for you...

The wise ve7eje enlightened me with:

What do the interfaces say? Up or Down? How do you do routing? Static or dynamic? Does it help to use 'shut' and 'no shut' on the tunnels, instead of a delete and reconfigure?

Greetings

Mark

I have used tunnels quite a lot, with and without keepalives, and this should not be happening - obviously:)

I wonder if there is perhaps some routing problem such that the routers cannot communicate when the interfaces exist. Then when you recreate the interface but before some change occurs in the routing table the tunnel gets established.

Crazy idea, can't see how it could be true, but maybe worth considering.

I often used static first hops for the gre traffic to ensure that recursive routing could not occur. First hop was enough for our topology.

e.g.

far end router int tu0 no ip address keepalive 10 3 tunnel source fa0/1 tunnel destination [near end routers fa0/1 routable IP]

ip route near-end-routers-fa0/1-routable-IP next-hop

The tunnel interfaces show admin up but protocol down. I have tried shut/no shut and that doesn't do anything. Next time this happens, I will try a few more things. This is a production link so the emphasis is on restoral, not testing. The routing is dynamic (OSPF). This only affects the tunnel though which is used to pass DECNET through a Telco that doesn't support that protocol. Other IP traffic flowing between the physical interfaces restores just fine. I will keep bod43's idea in mind for when this happens next time. I am also building a sandbox that I can use to experiment with. Assuming I can duplicate the problem that is.

-Rob-

Once I had a similar issue with a 3750 L3 switch as a tunnel endpoint, removing the keepalive command made the trick and after that the tunnel worked like a charm for years. Don't know if it was a release related issue or what. Bye, Tosh.

Sorry to echo the thoughts of others, but I have never seen this either. How long are you waiting for the tunnel to establish? Can you ping the endpoint address when the tunnel fails to come back ? Is anything logged ? Can you attach a monitor port to some intermediate switch between the device to see whether the tunnel is attempting to rebuild ? Same IOS both sides ? Tunnel in same state when down at both sides ?

Sorry to have no magic bullet.

Andy.

I have the same problem with the GRE tunnels + OSPF on both 2811 (R1) and 2821 (R2) routers. IOS 12.4(12) and 12.4(24)T.

R1 connected to ISP1 R2 connected to ISP2 Both ISPs provided its own MPLS network Each of that routers terminates several tunnels to a branch offices where we usualy have a 1841 or 1721 routers with different IOSes

R1 R2 are linked together via ethernet and both are belongs to an OSPF area 0. There is no any other links betwenn that routers.

All is working well but 2-3 times a week something strange is happening. Several tunnels goes down simulteniously on both R1 and R2. links to ISP1 or ISP2 did not flaps though but tunnels goes down. To get the tunnel UP I have to delete the tunnel from a config of a branch router, wait for a minute or two and then make the tunnel again.

This is not a routing issue because we are using static routes to a tunnels endpoints

BTW We have 3d 2811 router with a GRE tunnels + OSPF to all of our branches via Internet. It has the same IOS 12.4(12) but have no such problems at all

P.S. sorry for my terrible english