EIGRP Retry limit exceeded?

All, I have seen when running hub-and-spoke topology where R2 is hub, and R1 and R3 are spokes, where R1 and R3 try to establish as eigrp neighbors. What are all the different ways to prevent this from happening? Spokes should not be able to bring EIGRP, keep it up, and maintain a stable adjacency should it?

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***
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

Comments

  • Usually when you see something like this, it means that the multicasts are going from one device to the other, but unicasts are not.  The adjacencies start when the router receives the multicast hellos, but the unicast communications never happen.  So the adjacency never gets fully established.  That's where the retry limit exceeded message comes from.

    Not exactly sure how this is happening in your setup, seeing as this is a serial connection and not an Ethernet connection.  Do you have any interesting configs on R2 that might be forwarding on the EIGRP multicasts that it receives?

     

  • I don't have any special configs on R2 that I am aware of? I have 'no ip split-horizon eigrp 100' configured on serial0/0 which is required to get routing updates from spoke to spoke, but for some reason R3 is tryinig to initate the eigrp neighborship, and R1 doesn't respond?

    5.0 VolII - Lab1 Configs:

    This is the hub

    Rack1R2#sh ip int brie | e unass
    Interface                  IP-Address      OK? Method Status                Protocol
    FastEthernet0/0            183.1.28.2      YES NVRAM  up                    up     
    Serial0/0                  183.1.123.2     YES NVRAM  up                    up     
    Loopback0                  150.1.2.2       YES NVRAM  up                    up     

    router eigrp 100
     redistribute bgp 200 route-map BGP-TO-EIGRP100
     network 150.1.2.2 0.0.0.0
     network 183.1.28.2 0.0.0.0
     network 183.1.123.2 0.0.0.0
     distribute-list prefix SUPP-AS254-ROUTES out Serial0/0
     no auto-summary
     eigrp router-id 150.1.2.2

    !
    interface Serial0/0
     ip address 183.1.123.2 255.255.255.0
     ip accounting precedence input
     ip accounting precedence output
     ip pim sparse-mode
     encapsulation frame-relay
     no ip split-horizon eigrp 100
     no ip mroute-cache
     frame-relay map ip 183.1.123.1 201 broadcast
     frame-relay map ip 183.1.123.3 203 broadcast
     no frame-relay inverse-arp
     frame-relay lmi-type cisco
    end

    Anyone see what is causing this?

    R3 is trying to initate the neighborship

    Rack1R3(config)#do sh ip int brie | e unass
    Interface                  IP-Address      OK? Method Status                Protocol
    FastEthernet0/0            204.12.1.3      YES NVRAM  up                    up     
    FastEthernet0/1            183.1.39.3      YES NVRAM  up                    up     
    Serial1/0                  183.1.123.3     YES NVRAM  up                    up     
    Serial1/1                  183.1.0.3       YES NVRAM  up                    up     
    Serial2/1                  183.1.23.3      YES NVRAM  administratively down down   
    Loopback0                  150.1.3.3       YES NVRAM  up                    up     

    router eigrp 100
     redistribute connected route-map CONN-TO-EIGRP100
     redistribute ospf 1 route-map OSPF-TO-EIGRP100
     network 183.1.123.3 0.0.0.0
     no auto-summary
     eigrp router-id 150.1.3.3
     redistribute eigrp 100 subnets route-map EIGRP100-TO-OSPF

    I am clueless as to how this is happening with this configuration. Curious as to how you might stop the muliticast be initiated to R1, from R3, so you didn't get this neighbor trying to build, and tear down, time and time again.

    -D

  • What does "show frame-relay map" show on the hub and spokes? Any unexpected mappings?

  • Darrell, that was it! Somehow I have had the incomplete error'd 0.0.0.0 frame-relay mappings, that was causing this behavior. Once I wrote mem, and reloaded I haven't gotten that error again.

    Rack1R1(config-if)#do sh frame map
    Serial0/0 (up): ip 0.0.0.0 dlci 113(0x71,0x1C10)
                  broadcast,
                  CISCO, status defined, active
    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, active
    Serial0/0 (up): ip 183.1.123.3 dlci 102(0x66,0x1860), static,
                  CISCO, status defined, active

    wr mem & reload

    Rack1R1(config)#do sh run int s0/0
    Building configuration...

    Current configuration : 230 bytes
    !
    interface Serial0/0
     ip address 183.1.123.1 255.255.255.0
     encapsulation frame-relay
     frame-relay map ip 183.1.123.2 102 broadcast
     frame-relay map ip 183.1.123.3 102
     no frame-relay inverse-arp
     frame-relay lmi-type cisco
    end

    ...now it brought another question to mind now, does anyone recall the short cut to changing the interface encapsulation from frame-relay to ppp, then reconfigure the interface in order to get the error'd 0.0.0.0 mappings to go away?

    Rack1R1(config-if)#int s0/0
    Rack1R1(config-if)#encap ppp
    Rack1R1(config-if)#shut
    .Aug 26 06:25:17.421: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 183.1.123.2 (Serial0/0) is down: interface down
    Rack1R1(config-if)#shut
    Rack1R1(config-if)#
    .Aug 26 06:25:20.357: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0, changed state to down
    Rack1R1(config-if)#
    .Aug 26 06:25:22.233: %LINK-5-CHANGED: Interface Serial0/0, changed state to administratively down
    Rack1R1(config-if)#interface Serial0/0
    Rack1R1(config-if)# ip address 183.1.123.1 255.255.255.0
    Rack1R1(config-if)# encapsulation frame-relay
    Rack1R1(config-if)# frame-relay map ip 183.1.123.2 102 broadcast
    Rack1R1(config-if)# frame-relay map ip 183.1.123.3 102
    Rack1R1(config-if)# no frame-relay inverse-arp
    Rack1R1(config-if)# frame-relay lmi-type cisco
    Rack1R1(config-if)#end

    still had the errors

    Rack1R1(config-if)#do sh frame map
    Serial0/0 (up): ip 0.0.0.0 dlci 113(0x71,0x1C10)
                  broadcast,
                  CISCO, status defined, active
    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, active
    Serial0/0 (up): ip 183.1.123.3 dlci 102(0x66,0x1860), static,
                  CISCO, status defined, active

    i tried this, but wasn't successful so had to reload. [:(] Knowing that time is very valuable in the lab, can someone tell me a short cut that works to keep from having to reload the routers to fix the error'd 0.0.0. frame mappings? What am i doing wrong? Please let me know...

     

  • I always had the best success clearing the 0.0.0.0 mappings by reloading the router.

    Some have reported using "default interface s0/0", and then reapplying the interface config.

    Some have reported using "encap ppp" followed by "encap frame-relay" - I never found consistent results other than a reload.

  • K, thanks Darrell...I tried to the wr mem, default interface s0/0, and copy start run, and that fixed it. I'll have to keep these two in mind, and if all else fails I will have to wr mem, and reload. Thanks for all your help.

    -Darrell

Sign In or Register to comment.