Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

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

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

2 REPLIES
New Member

Re: Tunnel Interface flaps - but physical interface if fine - Wh

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

Hall of Fame Super Silver

Re: Tunnel Interface flaps - but physical interface if fine - Wh

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

514
Views
0
Helpful
2
Replies
CreatePlease login to create content