ipip Tunnels always up?

Enable keepalives on the tunnel interfaces.

I already tried setting keepalives but the tunnel is always up up, even with a random destination ip. I tried also non standard values for the keepalive time-out and retries settings, but nothing changes. I don't know, maybe I'm missing the obvious

this is my simple Tunnel config:

interface Tunnel124 ip address 124.124.124.124 255.255.255.248 keepalive 10 3 tunnel source A.B.C.D (my WAN Ip) tunnel destination 7.7.7.7 (I chose a random IP here; 7.7.7.7 won't even respond to pings) tunnel mode ipip

and this is the tunnel status, still Up Up even after 10 minutes:

Router#sh int tun 124 Tunnel124 is up, line protocol is up Hardware is Tunnel Internet address is 124.124.124.124/29 MTU 17920 bytes, BW 100 Kbit/sec, DLY 50000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation TUNNEL, loopback not set Keepalive set (10 sec), retries 3 Tunnel source A.B.C.D, destination 7.7.7.7 Tunnel protocol/transport IP/IP Tunnel TTL 255 Fast tunneling enabled Tunnel transport MTU 1480 bytes Tunnel transmit bandwidth 8000 (kbps) Tunnel receive bandwidth 8000 (kbps) Last input never, output never, output hang never Last clearing of "show interface" counters never Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops:

I have used this in anger and it does work.

interface Tunnel5 ip address 1.1.1.1 255.255.255.0 tunnel source Dialer0 tunnel destination 2.2.2.2 tunnel mode ipip

Tunnel5 1.1.1.1 YES manual up up OK this is what we expect.

interface Tunnel5 ip address 1.1.1.1 255.255.255.0 keepalive 10 3 ! ############# tunnel source Dialer0 tunnel destination 2.2.2.2 tunnel mode ipip

! wait a long time

Tunnel5 1.1.1.1 YES manual up up

Hmmm.

interface Tunnel5 ip address 1.1.1.1 255.255.255.0 keepalive 10 3 tunnel source Dialer0 tunnel destination 2.2.2.2 ! change to GRE - the default - not ipip

Tunnel5 1.1.1.1 YES manual up down

OK, looks like IP in IP tunnels do not support keepalives. I have always just used GRE which is the default, sorry for the confusion.

By the way the debug output seems a bit confusing.

router#sh deb General-purpose tunnel: Tunnel keepalive debugging is on

May 28 23:47:42.516 BST: Tunnel5: sending keepalive, 2.2.2.2->92.x.x.x (len=3D24 ttl=3D255), counter=3D29

All the wrong way round source is 92.x.x.x, dest is 2.2.2.2. c870-advipservicesk9-mz.124-15.T7.bin.

| By the way the debug output seems a bit confusing. | | router#sh deb | General-purpose tunnel: | Tunnel keepalive debugging is on | | May 28 23:47:42.516 BST: Tunnel5: sending keepalive, 2.2.2.2->92.x.x.x | (len=3D24 ttl=3D255), counter=3D29 | | All the wrong way round source is 92.x.x.x, dest is 2.2.2.2.

That's the inner (i.e., return) packet. See:

Thanks! I tried without ipip and it works as expected now. I'll keep this limitation in mind next time, and I'll probably stick with the default GRE from now on.

Thanks. I wasn't losing all that much sleep over it however it is always good to have a mystery solved:-)

The description at the link suggests to me that the keepalive may be returned even if there is no remote tunnel interface configured. I may have to do some reading on GRE.

In article , snipped-for-privacy@hotmail.co.uk (bod43) writes: | On 29 May, 04:46, ddl@danlan.*com (Dan Lanciani) wrote: | > In article , snipped-for-privacy@hotmail.co.uk (bod43) writes: | > | May 28 23:47:42.516 BST: Tunnel5: sending keepalive, 2.2.2.2->92.x.x.x | > | (len=3D3D24 ttl=3D3D255), counter=3D3D29 | > | | > | All the wrong way round source is 92.x.x.x, dest is 2.2.2.2. | >

| > That's the inner (i.e., return) packet. =A0See: | >

| >

There has to be a matching (source/destination and key if configured) remote tunnel interface for the return packet to be decapsulated; however, it may be possible to have that interface (mis)configured such that the tunnel doesn't really work even though the keepalive does. Of course, that's not what keepalives are meant to guard against and for most purposes they do what you want.

Dan Lanciani ddl@danlan.*com

That seems to sum up the cisco philosophy, from the point of view of a user of the kit. :-)))

It's always a good plan to stick with the cisco defaults. They do have a clue:-)

Of course if you understand what is going on and have specific requirenents then do whatever you want.