EIRGP expiration

[iholdings]

Greetings,

I've deployed EIGRP on two routers connected to a wireless bridge over Ethernet. Periodically, the hold time expires and drops the connection for a few minutes. Here is the log of this activity.

Mar 13 16:47:55.663: %DUAL-5-NBRCHANGE: IP-EIGRP 1: Neighbor 10.1.51.2 (FastEthernet4/0) is down: holding time expired

Mar 13 16:50:19.340: %DUAL-5-NBRCHANGE: IP-EIGRP 1: Neighbor 10.1.51.2 (FastEthernet4/0) is up: new adjacency

Mar 14 12:19:18.187: %DUAL-5-NBRCHANGE: IP-EIGRP 1: Neighbor 10.1.51.2 (FastEthernet4/0) is down: holding time expired

Mar 14 12:21:39.033: %DUAL-5-NBRCHANGE: IP-EIGRP 1: Neighbor 10.1.51.2 (FastEthernet4/0) is up: new adjacency

Mar 14 23:50:04.282: %DUAL-5-NBRCHANGE: IP-EIGRP 1: Neighbor 10.1.51.2 (FastEthernet4/0) is down: holding time expired

Mar 14 23:58:19.814: %DUAL-5-NBRCHANGE: IP-EIGRP 1: Neighbor 10.1.51.2 (FastEthernet4/0) is up: new adjacency

Mar 15 08:18:40.219: %DUAL-5-NBRCHANGE: IP-EIGRP 1: Neighbor 10.1.51.2 (FastEthernet4/0) is down: holding time expired

Mar 15 08:21:03.800: %DUAL-5-NBRCHANGE: IP-EIGRP 1: Neighbor 10.1.51.2 (FastEthernet4/0) is up: new adjacency

Are there any parameters I can adjust in EIGRP that would prevent these timeouts?

Thanks

[Amit Singh]

Hello Friend,

The neighbor 10.51.254.2 is flapping up and down due to holding time expired. This means the router did not receive an eigrp packet from its neighbor and the hold time expired,causing the neighbor to reset.

%DUAL-5-NBRCHANGE: IP-EIGRP 1: Neighbor 10.1.51.2 (FastEthernet4/0) is down: holding time expired

"If no hellos are received within the hold time, which is 15 seconds by default on most links, the router informs the neighbor that the neighbor relationship has been torn down and logs a syslog message."

1. Send a stream of 10000 count, once using 100 byte and once using 1500 byte packets,using extended ping, to the neighbor's directly connected interface IP address. Are there any packet drops or time outs?

Does the neighbor respond if you ping the EIGRP multicast address 224.0.0.10?

2. Perform "debug eigrp packet hello" on both routers to verify that the neighbors are ending and receiving EIGRP hello packets.

Check the routing table entry to verify the next-hop address is correct for the neighbor.

3. Other possibilities that can bring the neighbor relationship down are unidirectional links, uncommon subnet mismatches, mismatched masks, layer 2 problems, ACL deny statement, etc.

The detailed steps can be found here:

Troubleshooting EIGRP - Neighbor Check

http://www.cisco.com/warp/public/103/trouble_eigrp.html#nc

HTH,Please rate if it does.

-amit singh

[Richard Burts]

This is caused because enough EIGRP hello messages are not received to cause the neighbor relationship to terminate. EIGRP expects to receive hello messages on a certain periodic basis which can be adjusted with ip hello-interval eigrp . If EIGRP does not receive those messages regularly (if some messages are dropped) EIGRP has a hold interval which can be adjusted with ip hold-time eigrp and if there are no hello messages received within the hold interval then EIGRP will drop the neighbor.

You could experiment with changing the values of ip hello-interval and ip hold-time and see if it improves your situation. By default the values are 5 seconds and 15 seconds. I believe that it is good to maintain that ratio if you make changes.

I had a situation at a client where we had connections with variable latency and periodic high packet loss. We were experiencing the instability in EIGRP neighbor relationship that you are having. We did change the values and made them significantly larger. We found that the EIGRP neighbor relationships became much more stable. Recognize that if you do change these timers that when there is a real problem that EIGRP will be slower to recognize the problem and react to it. After all the purpose of these timers was for EIGRP to be able to verify that its neighbors are ok or not.

HTH

Rick

[griffijo]

I've seen the same problem with 2 1300 bridges and the problem was the bridges, not EIGRP. You should check your wireless link in terms of error, etc. You can do some tests right from the GUI interface of the bridges.

[glen.grant]

Personally I don't think this is a great idea trying to runn eigrp between 2 routers wirelessly . The drops could be caused by anything , interference in the wireless environment , rogue AP's etc.. which will be very difficult to track down . You can increase the timers and it may keep the adjacency up but you won't know when you are haveing problems , the link could be dropping packets and you won't know it because the link is being kept up artifically with the longer timers .

[griffijo]

You could use a static route/floating static route depending on whether this is an active link or a backup link to another location. This would stop the EIGRP problems, but you should still troubleshoot the wireless link. I use a number of wireless bridge connections and they are typically very reliable, even in the rain and snow.

[iholdings]

Thanks to everyone for all the advise.

I think I will work back from the wireless bridge and perhaps apply static routes on this interface since it is the primary path between the routers. I will update this post with the solution or with additional questions if these suggestions don't fix the problem.

Thanks again.