Tunnel up/Down after flap, but has ping communication

Eduardo Guido Manhaes da Rocha · ‎09-06-2012

We have this situation.

ROUTER1#sh int tu 4

Tunnel4 is up, line protocol is down

Hardware is Tunnel

Description: Con. Lan2Lan RJO ROUTER 2

MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation TUNNEL, loopback not set

Keepalive set (10 sec), retries 3

Tunnel source 10.255.60.134 (GigabitEthernet4/7), destination 10.255.60.133

Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled

Tunnel TTL 255

Checksumming of packets disabled, fast tunneling enabled

Last input 23w1d, output 00:00:04, output hang never

Last clearing of "show interface" counters 14w0d

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: fifo

Output queue: 0/0 (size/max)

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

L2 Switched: ucast: 0 pkt, 0 bytes - mcast: 0 pkt, 0 bytes

L3 in Switched: ucast: 0 pkt, 0 bytes - mcast: 0 pkt, 0 bytes mcast

L3 out Switched: ucast: 0 pkt, 0 bytes mcast: 0 pkt, 0 bytes

2390839 packets input, 307799934 bytes, 0 no buffer

Received 0 broadcasts (0 IP multicasts)

0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

102461 packets output, 4918128 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 output buffer failures, 0 output buffers swapped out

ROUTER1#sh run int tu4

Building configuration...

Current configuration : 221 bytes

!

interface Tunnel4

description Con. Lan2Lan ROUTER 2

no ip address

logging event link-status

keepalive 10 3

tunnel source GigabitEthernet4/7

tunnel destination 10.255.60.133

end

ROUTER1#sh run int g4/7

Building configuration...

Current configuration : 373 bytes

!

interface GigabitEthernet4/7

description Con. Lan2Lan ROUTER 2

mtu 9216

bandwidth 1000000

ip address 10.255.60.134 255.255.255.252

ip accounting output-packets

ip flow ingress

ip ospf authentication-key 7 060F1B1E424B1D

ip ospf cost 100

logging event link-status

logging event status

load-interval 30

speed nonegotiate

end

ROUTER1#ping ip 10.255.60.133 source 10.255.60.134 repeat 1500 size 1500

Type escape sequence to abort.

Sending 1500, 1500-byte ICMP Echos to 10.255.60.133, timeout is 2 seconds:

Packet sent with a source address of 10.255.60.134

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Success rate is 100 percent (1500/1500), round-trip min/avg/max = 8/8/44 ms

Router 1#sh int tu 4

Tunnel4 is up, line protocol is down

Hardware is Tunnel

Description: Con. Lan2Lan Router 1

MTU 17868 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 10.255.60.133 (GigabitEthernet7/2), destination 10.255.60.134

Tunnel Subblocks:

src-track:

Tunnel4 source tracking subblock associated with GigabitEthernet7/2

Set of tunnels with source GigabitEthernet7/2, 1 member (includes iterators), on interface <OK>

Tunnel protocol/transport GRE/IP

Key disabled, sequencing disabled

Checksumming of packets disabled

Tunnel TTL 255, Fast tunneling enabled

Tunnel transport MTU 9192 bytes

Tunnel transmit bandwidth 8000 (kbps)

Tunnel receive bandwidth 8000 (kbps)

Last input 00:00:04, output never, output hang never

Last clearing of "show interface" counters 6w4d

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: fifo

Output queue: 0/0 (size/max)

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

L2 Switched: ucast: 0 pkt, 0 bytes - mcast: 0 pkt, 0 bytes

L3 in Switched: ucast: 0 pkt, 0 bytes - mcast: 0 pkt, 0 bytes mcast

L3 out Switched: ucast: 0 pkt, 0 bytes mcast: 0 pkt, 0 bytes

102476 packets input, 4919688 bytes, 0 no buffer

Received 0 broadcasts (0 IP multicasts)

0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

0 packets output, 0 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 unknown protocol drops

0 output buffer failures, 0 output buffers swapped out

Router1#sh run int tu4

Building configuration...

Current configuration : 221 bytes

!

interface Tunnel4

description Con. Lan2Lan Router 1

no ip address

logging event link-status

keepalive 10 3

tunnel source GigabitEthernet7/2

tunnel destination 10.255.60.134

end

Router2#sh run int g7/2

Building configuration...

Current configuration : 351 bytes

!

interface GigabitEthernet7/2

description Con. Lan2Lan Router1

mtu 9216

bandwidth 1000000

ip address 10.255.60.133 255.255.255.252

ip accounting output-packets

ip flow ingress

ip ospf authentication-key 7 130C032D050910

ip ospf cost 100

logging event link-status

load-interval 30

speed nonegotiate

end

Router2#ping ip 10.255.60.134 source 10.255.60.133 repeat 1500 size 1500

Type escape sequence to abort.

Sending 1500, 1500-byte ICMP Echos to 10.255.60.134, timeout is 2 seconds:

Packet sent with a source address of 10.255.60.133

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Success rate is 100 percent (1500/1500), round-trip min/avg/max = 4/8/108 ms

Giuseppe Larosa · ‎09-06-2012

Hello Eduardo,

your ping test is performed between gigabit interfaces on R1 and R2.

Your GRE tunnel configuration has

no ip address

and this is quite uncommon.

try to give ip addresses taken from a /30 to the GRE Tunnels like 10.1010.0/30 and let's see if something changes.

After that you can try to ping from GRE tunnel address to GRE Tunnel address.

Edit:

as these devices are C7600 or C6500 try to remove the GRE keepalive as in the past it was not correctly implemented on these platforms.

Hope to help

Giuseppe

Eduardo Guido Manhaes da Rocha · ‎09-06-2012

Hi Giuseppe, thank's for your answer, i also see this, but my doubt is that i have other box with the same config

and flap too but the Tunnel up/up..

Richard Burts · ‎09-06-2012

In general for GRE tunnels (not using IPSec) without keepalive configured the router will mark the tunnel as up/up if the router has a valid route to the tunnel destination. In this case certainly the router has a valid route to the tunnel destination. But the router is marking the tunnel as up/down. So I have to believe that the issue here involves the GRE keepalive.

I suggest - at least as a test - that you remove the keepalive configured on both ends of the tunnel and see what happens. I am guessing that without keepalive the tunnel will come to up/up.

I also agree that it is very unusual to have a GRE tunnel that has no layer 3 protocol address. I am curious what you are using this tunnel for if it has no IP address?

HTH

Rick

HTH

Rick

Eduardo Guido Manhaes da Rocha · ‎09-10-2012

Hi Richard,

It´s use just to monitoring a lan to lan link. Because it´s an "ethernet-wan", the physic interface never goes down... With Tunnel using the physic interface as source and the other side physic interface as destination, we can monitore the stat of link.

Rememeber that in pair 02 of the same devices, we use tunnel without IP, and he is working well.

Richard Burts · ‎09-10-2012

Thanks for the additional information.

This is an interesting (and unusual) use of a GRE tunnel. But I can understand using it this way.

Have you tried my suggestion of a test in which you remove the configuration of tunnel keepalives on both routers?

HTH

Rick

HTH

Rick

Eduardo Guido Manhaes da Rocha · ‎09-11-2012

Hi,

Without Keepalives,this Tunnel always will on UP, i think that is BUG on IOS

c7600s72033-adventerprisek9-mz.122-33.SRB5a.bin.

Richard Burts · ‎09-11-2012

Are you saying that without keepalives the tunnel will always be up because you have done the test that I suggested?

In reading through this thread I notice your post where you say that you have this config on other box and it does not have this problem. So what version of software is running on those devices that do not have the problem?

HTH

Rick

HTH

Rick