EIGRP Section EIGRP Retry limit exceeded???????

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.

 

Comments

  • 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 [email protected].

    Good luck.

  • When 'debug eigrp packet'

    Get EIGRP: Checksum error from all other routers.



     

    On Sun, Mar 22, 2009 at 8:45 PM, Frank Li <[email protected]> wrote:

    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 [email protected]..

    Good luck.





    Internetwork Expert - The Industry Leader in CCIE Preparation
    http://www.internetworkexpert.com

    Subscription information may be found at:
    http://www.ieoc.com/forums/ForumSubscriptions.aspx


  • 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.

  • Too bad the TS section does not have switches that are configurable...

     

  • Nice post fellas...........it was of great help.

    Now Cisco is adding L2 switching features to the CCIE R&S
    Troubleshooting exam through L2 IOS software on Unix (L2IOU) virtual
    environment. The new feature will be available starting January 17,
    2011.

    So, we cannot neglect L2 Switching Issues -- hardware/IOS or configuration/tshoot related.........

    https://learningnetwork.cisco.com/docs/DOC-10859

     

    HTH

  • I just had this same problem on routers - not switches. I tried to check what VLANs are on my three routers but couldn't find one. I thought we have root bridge on a switched network. Can we have root bridge on routers? Then please explain for me.

  • I am also not using switches to connect any of my routers.

  • you can use command "sh vlan-switch" and make sure you created the vlan
    when you assign one on the access port.

    Thx
    David Sudjiman
    www.davidsudjiman.info

    On 22/02/2011 12:01 AM, oncho wrote:
    > I just had this same problem on routers - not switches. I tried to check what VLANs are on my three routers but couldn't find one. I thought we have root bridge on a switched network. Can we have root bridge on routers? Then please explain for me.
    >
    >
    > Internetwork Expert - The Industry Leader in CCIE Preparation

    > http://www.internetworkexpert.com

    >

    > Subscription information may be found at:

    > http://www.ieoc.com/forums/ForumSubscriptions.aspx
  • I am setting up DMVPN using Cisco 2812 as HUB router and 1812 as Spoke router. Hub router connected with spoke routers and RTO value shown is 5000 with each spoke routers. Restart did not help and this was really working well in the test lab for 3 weeks.

    Clearing counters on spoke routers (wan interface and Tunnel interface ) reduce the RTO to 1300 and sometime less than due to neighbor connection over DMVPN. Then eigrp was able to update it routing table across the neighbours.

     

  • 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

    Once you setup EIGRP authentication as asked in the IGP part, you'll not get these messages again on router R6.

  • You can also receive this error if you leave out the broadcast tag on the frame-relay map statement. Just wanted to pass along this information. I kept getting these messages after a hasty frame-relay configuration. 

  • Your configuration might be right.usually you get this error if you are using frame-relay.Make sure fram-relay map is configured properly.here below is an example.

    Example:

    R1 Serial 1/0 AND R2 Serial 1/0 are connected directly and under lying layer 2 is frame-relay

    Configuration

    R1

    ipv6 unicast-routing

    ipv6 cef

     

    ipv6 router eigrp 10

     router-id 10.1.1.1

    no shutdown (by default IPv6 EIGRP Process would be shutdown)

     

    interface Loopback0

     ip address 10.1.1.1 255.255.255.255

     ipv6 address 2001:10:10:1::1/128

     ipv6 enable 

     ipv6 eigrp 10

     

    interface Serial1/0

     no ip address

     encapsulation frame-relay IETF

     ipv6 address FE80::1 link-local

     ipv6 address 2001:10:10:14::1/64

     ipv6 enable

     ipv6 eigrp 10

     clock rate 2000000

     frame-relay map ipv6 FE80::1 200 broadcast (If the following command is not given then the above "retry limit exceed" error comes)

     frame-relay map ipv6 FE80::2 200 broadcast (If the following command is not given then the above "retry limit exceed" error comes)

     frame-relay map ipv6 2001:10:10:14::2 200 broadcast

     frame-relay map ipv6 2001:10:10:14::1 200 broadcast

     no frame-relay inverse-arp

     

    R2

    ipv6 unicast-routing

    ipv6 cef

    frame-relay switching

    ipv6 router eigrp 10

     router-id 10.2.2.2

     no shutdown (by default IPv6 EIGRP Process would be shutdown)

     

    interface Loopback0

     ip address 10.2.2.2 255.255.255.255

     ipv6 address 2001:10:10:2::2/128

     ipv6 enable 

     ipv6 eigrp 10

     

    interface Serial1/0

     no ip address

     encapsulation frame-relay IETF

     ipv6 address FE80::2 link-local

     ipv6 address 2001:10:10:14::2/64

     ipv6 enable

     ipv6 eigrp 10

     clock rate 2000000

     frame-relay map ipv6 FE80::1 200 broadcast (If the following command is not given then the above "retry limit exceed" error comes)

     frame-relay map ipv6 FE80::2 200 broadcast (If the following command is not given then the above "retry limit exceed" error comes)

     frame-relay map ipv6 2001:10:10:14::2 200 broadcast

     frame-relay map ipv6 2001:10:10:14::1 200 broadcast

     frame-relay intf-type dce

     no frame-relay inverse-arp

     

    Conclusion

    It doesnt always happen beacuse of hardware issue or IOS issue."Retry Limit Exceeded" errorIndicates that EIGRP did not receive the acknowledgement from the neighbor for EIGRP reliable packets and that EIGRP already has tried to retransmit the reliable packet 16 times without any success.(It nearly takes 3 min to get this error and again the neighborship would be up) 

    * Here below check the flow chart why this error would come.

     

    Retry Limit Exceeded error possiblities 

     

    * If the broadcast command is not configured properly the above error comes. (Make sure frame-relay map for link-local-address of R1 & R2 with broadcast are configured on both sides ) 

     

    Regards

    Ajay Chakravarthy

  • So I came across this very annoying error as well today after I loaded the initial configs for this lab.  

    The scenario is R2 is the Hub and is forming EIGRP neighbor relationships with both spoke R1 & R3.

    R1 and R3 had formed a neighbor relationship with R2 BUT was trying to form Neighbor relationships with one another.  After doing some debugging I noticed it was trying to do this over the PVC connecting the two directly, DLCI 103 & DLCI 301.  

    The show frame map was as follows:

     

    Rack1R1#sh frame-relay map 

    Serial0/0 (up): ip 0.0.0.0 dlci 113(0x71,0x1C10)

                  broadcast,

                  CISCO, status defined, inactive

    Serial0/0 (up): ip 0.0.0.0 dlci 105(0x69,0x1890)

                  broadcast,

                  CISCO, status defined, active

    Serial0/0 (up): ip 0.0.0.0 dlci 104(0x68,0x1880)

                  broadcast,

                  CISCO, status defined, active

    Serial0/0 (up): ip 0.0.0.0 dlci 103(0x67,0x1870)

                  broadcast,

                  CISCO, status defined, active

    Serial0/0 (up): ip 183.1.123.2 dlci 102(0x66,0x1860), static,

                  broadcast,

                  CISCO, status defined, inactive

    Serial0/0 (up): ip 183.1.123.3 dlci 102(0x66,0x1860), static,

                  CISCO, status defined, inactive

     

    Both R1 and R2 all had similar “ ip 0.0.0.0” entries.

    I learned this is caused by AutoInstall over Frame Relay and after I performed a "wr mem" on the three routers and rebooted the issue was resolved.  No More "Retry Limit Exceeded"  ...   Brian McGahan describes the error here: 

    http://blog.ine.com/2008/06/29/understanding-frame-relay-mappings-to-0000/

     

    After Reboot:

    Rack1R1#sh frame-relay map 

    Serial0/0 (up): ip 183.1.123.2 dlci 102(0x66,0x1860), static,

                  broadcast,

                  CISCO, status defined, active

    Serial0/0 (up): ip 183.1.123.3 dlci 102(0x66,0x1860), static,

                  CISCO, status defined, active

Sign In or Register to comment.