10-07-2008 10:18 PM - edited 03-06-2019 01:48 AM
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
Copyright (c) 1986-2006 by Cisco Systems, Inc.
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
10-07-2008 10:21 PM
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
10-08-2008 04:29 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide