cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
8188
Views
0
Helpful
2
Replies

EIGRP SRTT difference between neighbors & EIGRP Flapping

bhatok
Level 1
Level 1

I have a 4510R-E supervisor 6E running IOS 12.2(46)SG. It has 5 EIGRP neighbors. From the 4510 I do a "show ip eigrp neighbor" and 3 of the neighbors show a SRTT of around 500ms and RTO around 3000. When I do a "show ip eigrp neighbor" from each of these 3 devices they show an SRTT of around 15ms and RTO around 200-300 for the 4510. Why would these times differ from what the 4510 sees and what the 3 neighbors see?

2 of the 3 neighbors with the problem go thru a Riverbed Steelhead appliance.We use vlans to force traffic thru the Riverbed.

For EIGRP to run between the Riverbed connected devices it goes from VLAN 1000 on 4510 thru the LAN port of the Riverbed (this switchport is in vlan 1000), out of WAN port on Riverbed (this switchport is in VLAN 700) and into a router connected to an interface in VLAN 700. The router IP is in the same subnet as 4510 IP address of vlan 1000.

Routing works perfectly most of the time but every once and a while EIGRP hold timers expire and routing must reconverge. It always happens to the same 3 neighbors. Has anybody else had issues running EIGRP thru a Riverbed or had issues with EIGRP flapping with this version of IOS on 4510?

The 3 neighbors are  3825 router, an ASA 5510 version 8.2(2) and an ASA 5540 version 8.0(4).

I don't want to blame the Riverbed just yet because 1 of the neighbors having this problem does NOT go thru the Riverbed.

Thanks,

Brandon

2 Replies 2

Peter Paluch
Cisco Employee
Cisco Employee

Hello Brandon,

The SRTT and RTO values are actually derived only from acknowledged packets - Updates, Queries and Replies. They are not evaluated by Hello packets (logically, they cannot be - Hello is not a response to any external event and thus cannot be used to monitor a response time). So, to actually force the EIGRP to recalculate these values, a topology change would need to be repeated in the network, such as having a phony loopback interface go up and down a few times on both neighbors to force the EIGRP to emit some acknowledged packets and thereby reestimate the SRTT/RTO. It may be that there were far less acknowledged packets sent from one neighbor to other than in the opposite direction, thus a possible cause for the difference.

Nevertheless, while certainly an issue worth keeping an eye at, I do not think that this is actually responsible for your EIGRP flapping. If the hold timers expire then there is probably something more fishy going on - are you using the timers at their default value (i.e. 15 seconds)? Missing three Hello packets in a row is a good indication that there are some packet losses on the link. Can it be that the link is oversubscribed? Also, what is its real speed and what is the bandwidth setting on the interface? Also, have you modified the percentage of the bandwidth reservable for EIGRP traffic (using the max-reserved-bandwidth command)? I am trying to find out if it is possible that the EIGRP is allowed to reserve too small a portion of the link bandwidth, resulting in occassional drops.

Besides all this, is there any trigger that causes these adjacency flaps or do they occur randomly?

Best regards,

Peter

Thanks for the response Peter. After monitoring this for a few days it seems the high RTO and SRTT move between the devices. Right now the switch has normal times and the other devices are much higher. The bandwidth for all the links is 1000Mbps and I have not adjusted the timers or the max-reserved bandwidth for EIGRP. The flapping also takes place over night when there is little traffic on the network so I dont think it's a bandwidth issue at this point. We are going to try and remove the Riverbed completely from the network and see if this makes any difference.


Thanks again,

Brandon

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: