GRE tunnel problem

I have a very basic tunnel set up between 2 2800 series routers (IOS
12.4(24)T).

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

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

This all works just fine except if the link goes down. If that happens
the tunnel doesn't automatically recover when the link comes back up.
The only way I have found to get the tunnel back is to manually delete
and rebuild the tunnel config in one of the routers.

Am I missing something?

Thanks -Rob-

 

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

 

Rob,

When the link goes down is it the Fa0/1 interface itself that drops or another device/link between the two?

I've seen a similar problem in the past but it only related to when the physical interface itself went down. When it came back up the tunnel interface didn't seem to notice.

The workaround I found was to change the tunnel source to the actual interface IP address rather the interface name.

 

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-

 

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.
www.netsumo.com // ISP consultancy

 

i have the same problem. a tunnel between two routers with a keepalive 10 3 set on each end. the purpose of the keepalive is to show correct tunnel status if communications go down. otherwise the tunnel shows up/up if the underlying physical interface is up/up. my tunnel goes through a crypto system, so all interfaces from one end to the other always show up/up. i believe that when the crypto gear is reloaded or updated, the tunnel communications are blocked for more than 30 seconds. like the orginator, my tunnel will not recover automatically. however, if i reload the router, the tunnel is operational again. interestingly, only one end of the tunnel goes down because of the keepalive. if no solution can be found, i suppose i will remove the keepalive command.

my routers are both 3825 routers running IOS ADVIPSERVICES 12.4(16B) and 12.4(29)T2

i have a tunnel to another 3825 router that does not experience this issue. it however does not go through any encryption devices.

thanks for anyone who has an answer.