IEOC - Internetwork Expert's Online Community

I have verfied I have the correct EIGRP configuration on all of my routers and I keep getting the below error message on R1 and R6.

Rack15R1#
*Feb  1 06:06:13.107: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 183.5.123.3 (Serial0/0/0) is down: retry limit exceeded
Rack15R1#
*Feb  1 06:06:53.875: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 183.5.123.3 (Serial0/0/0) is up: new adjacency

Rack15R6#
*Feb  1 06:06:11.913: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 10: Neighbor 54.5.1.254 (Serial0/0/0) is down: retry limit exceeded
*Feb  1 06:06:12.353: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 10: Neighbor 54.5.1.254 (Serial0/0/0) is up: new adjacency

Does anyone know what is needed to resolve this problem. I did a search on this and it referred to possible access list or hardware problem or configuration. I am using rented equipment so I am assuming the equipment is OK. My configuration is identical to the solution guide but I continue to get these messages even after rebooting the two routers.

I aggree that it looks like a hardware issue.  I had this once also on reneted equip.  and spent a lot of time trying to figure it out.  What I observed is that show ip eigrp neig showed the rto was incrementing up to 5000 then the adjacency would go down.  The adjacency would form (somtimes), but after awhile would timeout as the hellos where not coming back from the backbone in time.  It would be something to show the proctor.  Hope it just doesn't happen in the real lab. 

Thanks for replying I was starting to wonder if anyone was reading this thing.

I got the same issue here and are tring to find the reason.

If you already got the answer. Please kindly give me an email to franklee40@gmail.com.

Good luck.

In my case it appeared to be hardware related. I was renting lab time with Rack Time Rental and they claimed there was not a hardware issue. The thing is I saved my configurations up to that point and reapplied them to my next rack rental and I did not get the same errors. So I am assuing that there was something with the rack since the same configurations worked fine without this error on my next rental.

Thx for reply this.

After rebooted router, this problem gone. But we just not be able to reproduce this issue.

Some of my friends suggest this might be an IOS related problem.

I just had this issue in a production environment.  One neighbor logged retry limit exceeded, the other neighbor logged k values invalid.  The k values were correct.  One of the devices was a 3750 which had been configured with "system mtu routing 1998"  This caused an mtu mismatch on the ehternet link.  Entered the command "system mtu routing 1500".  Problem solved.

Our problem turns out to be (the most possiblity) an IOS issue. There are documents in cisco indicated with some version of IOS, this ISSUE exists.

With Cisco's recommend, we replaced IOS, it works.

The MTU, unidirection link or a bad detail route can causes this situation also.

Personally I don't think this is a hardware issue or IOS issue. If I am not mistaking you can't establish a good adjacency from spoke to spoke which is what R1 <> R3 are trying to do with each other. If you do some debugs you'll see where the routers send UPDATEs on the serial interface going over to R2, but don't get a response in time. Please see below...

before peer is torn down:

Rack1R3#sh ip eigrp int
IP-EIGRP interfaces for process 100

                        Xmit Queue   Mean   Pacing Time   Multicast    Pending
Interface        Peers  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
Se1/0              2        0/0         6       0/15          50           0

Rack1R3#sh ip eigrp nei
IP-EIGRP neighbors for process 100
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
0   183.1.123.1             Se1/0            158 00:01:14    1  5000  1  0  ***notice the Q count showing something in the queue, and RTO is 5000*** adjacency***
1   183.1.123.2             Se1/0            142 4d12h      12   200  0  35

*Aug 22 22:50:33.977: EIGRP: Sending UPDATE on Serial1/0 nbr 183.1.123.1, retry 37, RTO 5000
*Aug 22 22:50:33.977:   AS 100, Flags 0x1, Seq 1760/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
Rack1R3#u all
*Aug 22 22:50:38.977: EIGRP: Retransmission retry limit exceeded
*Aug 22 22:50:38.981: EIGRP: Build goodbye tlv for 183.1.123.1
*Aug 22 22:50:38.981: EIGRP: Sending HELLO on Serial1/0
*Aug 22 22:50:38.981:   AS 100, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
*Aug 22 22:50:38.981: EIGRP: Holdtime expired
*Aug 22 22:50:38.981: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 183.1.123.1 (Serial1/0) is down: retry limit exceeded
Rack1R3#u all
*Aug 22 22:50:38.981: Going down: Peer 183.1.123.1 total=1 stub 0 template=1, iidb-stub=0 iid-all=1
*Aug 22 22:50:38.981: EIGRP: Neighbor 183.1.123.1 went down on Serial1/0

*Aug 22 22:58:10.305: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 183.1.123.1 (Serial1/0) is down: retry limit exceeded

Rack1R3#sh ip eigrp nei  
IP-EIGRP neighbors for process 100
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
1   183.1.123.2             Se1/0            138 4d12h      12   200  0  35

This one took me awhile to figure out but I did.  Write out a Layer 2 map, then look for the STP root for the VLAN the EIGRP traffic is on.  If your seeing the EIGRP status flapping, it is probably because one of the neighbors is the root bridge on that VLAN.  So what happens is the trafic leaves then comes right back and everything screws up.  Simply make some other switch the root for that VLAN and poof...problem solved!

Many thanks for your insight on this one. I changed the root bridge and poof, it works. Can you please flesh out a bit more .. technical speaking.

I think it's something like this.  If you draw out a Layer-2 map, you'll see the EIGRP traffic goes out the routed port on SW4 to some switch, then since SW4 is the root bridge for that vlan, the traffic comes right back on the connected trunk port and everything breaks down.  I wish I could tell you in more detail why this is but I'm a total noob.  Good Luck!

Guys,

I have ran into the same issue in Vol2 ver5.0 lab 9 scenario. Fortunately with these posts and other post I have found on this forum I know what the problem is.

Root cause:

Main issue here is an architecture of 3550. This piece of HW does not like any frame incoming with a souce MAC address which also local on the switch.

This can happen very easily when using routed ports on 3550. How? Routed packet sourced from switch A with MAC XXX will go along STP topology towards a switch B and then back to switch A that should be only middle stop towards some other switches along STP topology. Unfortunately switch A (3550) will protest and discard this frame. This way EIGRP neighborship between switdch A and other switch (e.g. C) may flap.  What does help is change STP topology - e.g. by making some other switch root.

Tom

Tom

Does the problem occur with 3560? Because i have only 3750 and i can't remember i had such an issue.