From: ve7eje on
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-
From: Rob on
ve7eje <ve7eje(a)gmail.com> wrote:
> 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.

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...
From: Mark Huizer on
The wise ve7eje enlightened me with:
> 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?

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
From: bod43 on
On 27 May, 18:05, Mark Huizer <xaa+news_comp.dcom.sys.ci...(a)dohd.org>
wrote:
> The wise ve7eje enlightened me with:
>
>
>
> > 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?
>
> 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?



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

From: ve7eje on
On May 27, 10:05 am, Mark Huizer <xaa
+news_comp.dcom.sys.ci...(a)dohd.org> wrote:
> 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?
>

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-