Tunnel Interface flaps - but physical interface if fine - Why?

astanislaus · ‎10-07-2008

sh log

Oct 8 08:30:20: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel40, changed state to down

Oct 8 08:30:20: %OSPF-5-ADJCHG: Process 1, Nbr 202.163.46.66 on Tunnel40 from FULL to DOWN, Neighbor Down: Interface down or detached

Oct 8 08:30:30: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel40, changed state to up

Oct 8 08:31:05: %OSPF-5-ADJCHG: Process 1, Nbr 202.163.46.66 on Tunnel40 from LOADING to FULL, Loading Done

Oct 8 11:11:50: %OSPF-5-ADJCHG: Process 1, Nbr 172.16.3.34 on Tunnel409 from FULL to DOWN, Neighbor Down: Dead timer expired

Oct 8 11:11:52: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel409, changed state to down

Oct 8 11:13:42: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel409, changed state to up

Oct 8 11:13:43: %OSPF-5-ADJCHG: Process 1, Nbr 172.16.3.34 on Tunnel409 from LOADING to FULL, Loading Done

Oct 8 11:24:51: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel107, changed state to down

Oct 8 11:24:51: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.107.6 on Tunnel107 from FULL to DOWN, Neighbor Down: Interface down or detached

Oct 8 11:26:21: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel107, changed state to up

Oct 8 11:26:29: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.107.6 on Tunnel107 from LOADING to FULL, Loading Done

Oct 8 11:26:47: %OSPF-5-ADJCHG: Process 1, Nbr 172.16.33.6 on Tunnel602 from FULL to DOWN, Neighbor Down: Too many retransmissions

Oct 8 11:27:47: %OSPF-5-ADJCHG: Process 1, Nbr 172.16.33.6 on Tunnel602 from DOWN to DOWN, Neighbor Down: Ignore timer expired

Oct 8 11:27:56: %OSPF-5-ADJCHG: Process 1, Nbr 172.16.33.6 on Tunnel602 from LOADING to FULL, Loading Done

This is happening only on this one router of the tunnels and not on the destination routers of the tunnels.

IS this due to keepalive packets on teh tunnel interface getting dropped somewhere?

The physical interface never flaps or sees any input or output drops.

Processor and memory usage doesn't seem to be a problem.Cisco IOS Software, 7200 Software (C7200-IS-M), Version 12.4(7), RELEASE SOFTWARE (fc6)

Technical Support: http://www.cisco.com/techsupport

Compiled Wed 01-Mar-06 05:13 by alnguyen

ROM: System Bootstrap, Version 12.3(4r)T3, RELEASE SOFTWARE (fc1)

BOOTLDR: 7200 Software (C7200-KBOOT-M), Version 12.3(9), RELEASE SOFTWARE (fc2)

MegaPop_CR1 uptime is 1 year, 3 weeks, 1 day, 7 hours, 8 minutes

System returned to ROM by power-on

System restarted at 12:52:36 GMT Sat Sep 8 2007

System image file is "disk2:c7200-is-mz.124-7.bin"

Cisco 7206VXR (NPE-G1) processor (revision B) with 229376K/32768K bytes of memory.

Processor board ID 34706531

SB-1 CPU at 700MHz, Implementation 1025, Rev 0.2, 512KB L2 Cache

6 slot VXR midplane, Version 2.11

astanislaus · ‎10-07-2008

interface Tunnel40

description xxxxxxx

bandwidth 64

ip address x.x.x.x x.x.x.x

ip ospf cost 2

keepalive 10 3

tunnel source a.a.a.1

tunnel destination a.a.a.2

Richard Burts · ‎10-08-2008

Alphonse

It certainly looks like the issue is that the GRE tunnel keepalives are experiencing enough packet drops to bring down the tunnel. It might be interesting to see the configuration of the tunnel from both routers.

If you want to do some testing I would test with traffic from the router that is stable to the router that has the flapping tunnel interface. I would suggest using an extended ping to generate traffic. In the extended ping I would specify the destination address as the address used as tunnel destination, specify the source address as the address used as tunnel source, and specify a large number of ping packets. Then look to see if there is much packet drop in the ping results.

HTH

Rick

HTH

Rick