cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4006
Views
25
Helpful
16
Replies

EIGRP direct neighbors flapping

the-lebowski
Level 4
Level 4

Having a problem with a 2 neighrbors losing their EIGRP adjacency:

 

2951 gi0/11.2 >>>>>>>>>>> 3850 gi1/0/45

 

They are connected directly to each other but sometime last night it started to lose the adjacency.  I went as so far as to statically configure them as neighbors which didn't fix it.  The 2951 has 2 other EIGRP neighbors which it doesn't drop connectivity between, its just between itself and the 3850.   I do see the Q count as 1 on both sides and debug shows, what looks to me, like the 3850 stops sending packets back to the 2951.

 

I am also seeing weird routing issues on some of the VLANs on the 3850 as well, some are passing traffic while others aren't.  I tried power cycling the 3850 but it made no difference.  I have read all types of horror stories about 3850 bugs but no idea if this just another issue with a 3850.  Its currently on 16.3.6 and wondering if an upgrade might help at this point.  

 

router eigrp 3000
 distribute-list 90 out Tunnel1
 network 10.1.100.0 0.0.0.255
 network 10.1.200.0 0.0.0.255
 network 10.119.2.0 0.0.0.255
 redistribute static route-map lab
 neighbor 10.119.2.1 GigabitEthernet0/1.2
 eigrp router-id 10.119.2.2
router eigrp 3000
network 10.119.2.0 0.0.0.255 neighbor 10.119.2.2 Vlan2 eigrp stub connected summary snmp-server enable traps eigrp snmp-server enable traps ipsla snmp-server enable traps syslog
010173: Feb  7 20:27:21.553: EIGRP: Sending UPDATE on Gi0/1.2 - paklen 0 nbr 10.119.2.1, retry 5, RTO 5000 tid 0
010174: Feb  7 20:27:21.553:   AS 3000, Flags 0x1:(INIT), Seq 9164/124 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
010175: Feb  7 20:27:21.565: EIGRP: Received UPDATE on Gi0/1.2 - paklen 0 nbr 10.119.2.1
010176: Feb  7 20:27:21.565:   AS 3000, Flags 0x1:(INIT), Seq 124/0 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1, last received seq 124, out of sequence, this seq 124

010183: Feb  7 20:27:24.813: EIGRP: Received HELLO on Gi0/1.2 - paklen 26 nbr 10.119.2.1
010184: Feb  7 20:27:24.813:   AS 3000, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
010185: Feb  7 20:27:24.813: EIGRP: Received Peer Info from AS 203882497(10.119.2.1), old info, ignored
010186: Feb  7 20:27:25.217: EIGRP: Sending HELLO on Gi0/1.2 - paklen 20 nbr 10.119.2.1
010187: Feb  7 20:27:25.217:   AS 3000, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0

 

16 Replies 16

Hello,

 

post the full configs of both devices. Where is EIGRP AS 3111 amd IP 10.195.2.1 ?

Its all the same AS, just forgot to edit the instance and IPs.

AS 3000
2951: 10.119.2.2
3850 10.119.2.1

I would have to sanitize the **bleep** out of them..but if you want pertinent sections let me know and I will share them.

Hello,

 

anything mentioned in the EIGRP config would be relevant. You have static neighbors configured, but you also announce the directly connected interfaces, is there a reason for that ? Also, one side has an EIGRP router ID, the other one hasn't ? And one side is configured as EIGRP stub ? Why is that ? You would typically need that in a hub and spoke topology...

 

Is the line marked in bold a typo ?

 

router eigrp 3000
distribute-list 90 out Tunnel1
network 10.1.100.0 0.0.0.255
network 10.1.200.0 0.0.0.255
network 10.1119.2.0 0.0.0.255
redistribute static route-map lab
neighbor 10.119.2.1 GigabitEthernet0/1.2
eigrp router-id 10.119.2.2


router eigrp 3000
network 10.119.2.0 0.0.0.255
neighbor 10.119.2.2 Vlan2
eigrp stub connected summary
snmp-server enable traps eigrp
snmp-server enable traps ipsla
snmp-server enable traps syslog

Static neighbors was just trying to fix the problem, it wasn't that way before this morning when I was trying to fix it.

This is part of a DMVPN cloud, 2951 is a spoke and the 3850 is downstream configured as a stub so that it will learn routes and not advertise anything back. Yes that is a typo and I will fix it now.   I tried moving the cable on the 3850 to a different port and the Q Count = 1 went away but its still flapping constantly.  

Feb  7 07:25:08.988: %DUAL-5-NBRCHANGE: EIGRP-IPv4 3000: Neighbor 10.119.2.2 (Vlan2) is up: new adjacency
*Feb  7 07:26:06.885: %DUAL-5-NBRCHANGE: EIGRP-IPv4 3000: Neighbor 10.119.2.2 (Vlan2) is down: holding time expired
*Feb  7 07:26:24.996: %DUAL-5-NBRCHANGE: EIGRP-IPv4 3000: Neighbor 10.119.2.2 (Vlan2) is up: new adjacency
*Feb  7 07:28:10.039: %DUAL-5-NBRCHANGE: EIGRP-IPv4 3000: Neighbor 10.119.2.2 (Vlan2) is down: holding time expired
*Feb  7 07:28:19.259: %DUAL-5-NBRCHANGE: EIGRP-IPv4 3000: Neighbor 10.119.2.2 (Vlan2) is up: new adjacency
*Feb  7 07:31:48.755: %DUAL-5-NBRCHANGE: EIGRP-IPv4 3000: Neighbor 10.119.2.2 (Vlan2) is down: holding time expired
*Feb  7 07:31:52.201: %DUAL-5-NBRCHANGE: EIGRP-IPv4 3000: Neighbor 10.119.2.2 (Vlan2) is up: new adjacency

grabonlee
Level 4
Level 4

Hello,

Could you remove the neighbor statements prior to implementing the debugging steps below:

 

1. Check the Interface counters on both switches for any flaps (error counts)

 

2. Do sh ip eigrp neighbors on both routers. If any has SRTT = 0, RTO = 5000, Q count = non-zero value. This indicates problem with neighbor relationship. Go back and check the Layer1/2 connectivity and ensure port and cables are good. Also check other EIGRP parameters are correct.

 

3. Do sh ip route x.x.x.x and look at the timer. If a zero timer, do debug ip routing to verify that the router is deleting the route and re-installing it. Also do a sh ip eigrp event on both routers to see which is constantly updating the other.

 

4. Reboot the 3850, if confirmed that there are no Layer 1/2 issues or EIGRP misconfiguration.

 

5. If nothing resolves after reboot, you might need a TAC ticket opened.

Counters aren't increasing on either end.  I removed the static neighbor references as well. 

 

3850 Input queue: 0/375/1767/0 (size/max/drops/flushes); Total output drops: 0
2951 Input queue: 0/75/1779/0 (size/max/drops/flushes); Total output drops: 24
3850#show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(3000)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 10.119.2.2 Vl2 12 00:00:46 1 4500 0 9524

2951#show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(3000)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 10.119.2.1 Gi0/1.2 12 00:01:38 32 648 0 487
1 10.1.2.1 Tu2 12 02:52:07 216 1296 0 33722
2 10.1.1.1 Tu1 12 1d08h 215 1290 0 62071

3850#show ip route 10.119.2.2 Routing entry for 10.119.2.0/24 Known via "connected", distance 0, metric 0 (connected, via interface) Redistributing via eigrp 3000 Routing Descriptor Blocks: * directly connected, via Vlan2 Route metric is 0, traffic share count is 1
2951#sho ip route 10.119.2.1 Routing entry for 10.119.2.0/24 Known via "connected", distance 0, metric 0 (connected, via interface) Redistributing via nhrp, eigrp 3000 Routing Descriptor Blocks: * directly connected, via GigabitEthernet0/1.2 Route metric is 0, traffic share count is 1

 

r1-3850-blr#sh mon cap CAP buf br
Starting the packet display ........ Press Ctrl + Shift + 6 to exit

  1   0.000000   10.119.2.1 -> 10.119.2.2   EIGRP 60 Update
  2   0.000032   10.119.2.1 -> 224.0.0.10   EIGRP 90 Hello
  3   0.000055   10.119.2.2 -> 10.119.2.1   EIGRP 64 Hello (Ack)
  4   0.000077   10.119.2.2 -> 10.119.2.1   EIGRP 1407 Update
  5   0.000104   10.119.2.2 -> 224.0.0.10   EIGRP 78 Hello
  6   0.000127   10.119.2.2 -> 224.0.0.10   EIGRP 78 Hello
  7   0.000149   10.119.2.1 -> 224.0.0.10   EIGRP 90 Hello
  8   0.000172   10.119.2.1 -> 10.119.2.2   EIGRP 60 Update
  9   0.000119   10.119.2.2 -> 10.119.2.1   EIGRP 64 Hello (Ack)
 10   0.000217   10.119.2.2 -> 10.119.2.1   EIGRP 1407 Update
 11   0.000244   10.119.2.1 -> 10.119.2.2   EIGRP 60 Hello (Ack)
 12   0.000267   10.119.2.2 -> 224.0.0.10   EIGRP 1391 Update
 13   0.000305   10.119.2.1 -> 10.119.2.2   EIGRP 60 Hello (Ack)
 14   0.000328   10.119.2.2 -> 224.0.0.10   EIGRP 1403 Update
 15   0.000355   10.119.2.1 -> 10.119.2.2   EIGRP 60 Hello (Ack)
 16   0.000398   10.119.2.2 -> 224.0.0.10   EIGRP 1332 Update
 17   0.000430   10.119.2.1 -> 10.119.2.2   EIGRP 60 Hello (Ack)
 18   0.000452   10.119.2.2 -> 224.0.0.10   EIGRP 315 Update
 19   0.000475   10.119.2.2 -> 10.119.2.1   EIGRP 315 Update
 20   0.000508   10.119.2.2 -> 10.119.2.1   EIGRP 315 Update
 21   0.000532   10.119.2.1 -> 10.119.2.2   EIGRP 60 Hello (Ack)
 22   0.000554   10.119.2.1 -> 224.0.0.10   EIGRP 90 Hello
 23   0.000577   10.119.2.2 -> 224.0.0.10   EIGRP 78 Hello
 24   0.000600   10.119.2.1 -> 224.0.0.10   EIGRP 90 Hello
 25   0.000623   10.119.2.2 -> 224.0.0.10   EIGRP 78 Hello
 26   0.000645   10.119.2.1 -> 224.0.0.10   EIGRP 90 Hello
 27   0.000668   10.119.2.2 -> 224.0.0.10   EIGRP 78 Hello
 28   0.000691   10.119.2.1 -> 224.0.0.10   EIGRP 80 Hello
 29   0.000713   10.119.2.2 -> 224.0.0.10   EIGRP 78 Hello
 30   0.000736   10.119.2.1 -> 224.0.0.10   EIGRP 80 Hello
 31   0.000759   10.119.2.2 -> 224.0.0.10   EIGRP 78 Hello
 32   0.000781   10.119.2.2 -> 224.0.0.10   EIGRP 78 Hello
 33   0.000804   10.119.2.1 -> 224.0.0.10   EIGRP 80 Hello
 34   0.000826   10.119.2.2 -> 224.0.0.10   EIGRP 78 Hello
 35   0.000849   10.119.2.1 -> 224.0.0.10   EIGRP 80 Hello
 36   0.000872   10.119.2.2 -> 224.0.0.10   EIGRP 78 Hello
 37   0.000894   10.119.2.1 -> 224.0.0.10   EIGRP 80 Hello
 38   0.000917   10.119.2.2 -> 224.0.0.10   EIGRP 78 Hello
 39   0.000949   10.119.2.1 -> 224.0.0.10   EIGRP 80 Hello
 40   0.000971   10.119.2.1 -> 224.0.0.10   EIGRP 80 Hello
 41   0.000994   10.119.2.2 -> 224.0.0.10   EIGRP 78 Hello

Already rebooted the 3850 and it made no difference.  Moved the cable to a different port on the 3850 to no avail as well.  Been on the phone with TAC this entire time to no avail as well.  

 

I figured I would post here while I wait on the call.  :) 

Tried bring up EIGRP neigbhor with a brand new 9300 and the 3805 and the same problem there, just flapping away.  Did this on a different vlan as well.  So I would think the problem is with the 3850 itself.  :( 

Hi

 

The show ip route should be for an advertised route and not the connected interfaces that the adjacencies are established on. You would not see any timer on the connected interfaces.

 

Also what is the output of the debug ip routing and sh ip eigrp events? If it's the 3850 constantly updating, then the issue is with it. 

The interfaces between the two are running at 1Gbps?

3850#show ip route 10.0.5.1
Routing entry for 10.0.5.0/24
  Known via "eigrp 3000", distance 90, metric 2134016, type internal
  Redistributing via eigrp 3000
  Last update from 10.119.2.2 on Vlan2, 00:03:30 ago
  Routing Descriptor Blocks:
  * 10.119.2.2, from 10.119.2.2, 00:03:30 ago, via Vlan2
      Route metric is 2134016, traffic share count is 1
      Total delay is 50030 microseconds, minimum bandwidth is 3000 Kbit
      Reliability 255/255, minimum MTU 1400 bytes
      Loading 64/255, Hops 3

 

3850# show log
Syslog logging: enabled (0 messages dropped, 1 messages rate-limited, 7 flushes, 0 overruns, xml disabled, filtering disabled)

Active Message Discriminator:
nolog     msg-body       drops    flapping




No Inactive Message Discriminator.


    Console logging: level debugging, 2074 messages logged, xml disabled,
                     filtering disabled, discriminator(nolog),
                     0 messages rate-limited, 8524 messages dropped-by-MD
    Monitor logging: level debugging, 2049 messages logged, xml disabled,
                     filtering disabled, discriminator(nolog),
                     0 messages rate-limited, 8524 messages dropped-by-MD
        Logging to: vty2(1256)
    Buffer logging:  level debugging, 2074 messages logged, xml disabled,
                    filtering disabled, discriminator(nolog),
                     0 messages rate-limited, 8524 messages dropped-by-MD
    Exception Logging: size (4096 bytes)
    Count and timestamp logging messages: disabled
    File logging: disabled
    Persistent logging: disabled

No active filter modules.

    Trap logging: level informational, 9132 message lines logged
        Logging Source-Interface:       VRF Name:

Log Buffer (4096 bytes):
l192  0 1048578

*Feb  7 08:55:15.386: RT: updating rip 10.193.0.0/16 (0x0)  :
    via 192.0.2.9 Vl192  0 1048578

*Feb  7 08:55:15.386: RT: updating rip 192.0.2.0/29 (0x0)  :
    via 192.0.2.9 Vl192  0 1048578

*Feb  7 08:55:15.386: RT: updating rip 72.1.90.0/28 (0x0)  :
    via 192.0.2.9 Vl192  0 1048578

*Feb  7 08:55:15.387: RT: updating rip 72.1.90.0/29 (0x0)  :
    via 192.0.2.9 Vl192  0 1048578

*Feb  7 08:55:15.387: RT: updating rip 192.0.2.1/32 (0x0)  :
    via 192.0.2.9 Vl192  0 1048578

*Feb  7 08:55:15.388: RT: updating rip 192.0.2.16/29 (0x0)  :
    via 192.0.2.9 Vl192  0 1048578

*Feb  7 08:55:15.388: RT: updating rip 72.1.90.16/29 (0x0)  :
    via 192.0.2.9 Vl192  0 1048578

*Feb  7 08:55:15.389: RT: updating rip 192.0.2.17/32 (0x0)  :
    via 192.0.2.9 Vl192  0 1048578

*Feb  7 08:55:15.390: RT: updating rip 192.0.2.24/29 (0x0)  :
    via 192.0.2.9 Vl192  0 1048578

*Feb  7 08:55:15.391: RT: updating rip 192.0.2.25/32 (0x0)  :
    via 192.0.2.9 Vl192  0 1048578

*Feb  7 08:55:15.392: RT: updating rip 192.0.2.32/29 (0x0)  :
    via 192.0.2.9 Vl192  0 1048578

*Feb  7 08:55:15.393: RT: updating rip 192.0.2.33/32 (0x0)  :
    via 192.0.2.9 Vl192  0 1048578

*Feb  7 08:55:15.393: RT: updating rip 192.0.2.40/29 (0x0)  :
    via 192.0.2.9 Vl192  0 1048578

*Feb  7 08:55:15.394: RT: updating rip 192.0.2.41/32 (0x0)  :
    via 192.0.2.9 Vl192  0 1048578

*Feb  7 08:55:15.394: RT: updating rip 192.0.2.48/29 (0x0)  :
    via 192.0.2.9 Vl192  0 1048578

*Feb  7 08:55:15.394: RT: updating rip 10.255.197.48/28 (0x0)  :
    via 192.0.2.9 Vl192  0 1048578

*Feb  7 08:55:15.394: RT: updating rip 192.0.2.49/32 (0x0)  :
    via 192.0.2.9 Vl192  0 1048578

*Feb  7 08:55:15.395: RT: updating rip 192.0.2.56/29 (0x0)  :
    via 192.0.2.9 Vl192  0 1048578

*Feb  7 08:55:15.395: RT: updating rip 192.0.2.57/32 (0x0)  :
    via 192.0.2.9 Vl192  0 1048578

*Feb  7 08:55:15.395: RT: updating rip 192.0.2.72/29 (0x0)  :
    via 192.0.2.9 Vl192  0 1048578

*Feb  7 08:55:15.395: RT: updating rip 192.0.2.73/32 (0x0)  :
    via 192.0.2.9 Vl192  0 1048578

*Feb  7 08:55:15.396: RT: updating rip 10.255.196.176/28 (0x0)  :
    via 192.0.2.9 Vl192  0 1048578

*Feb  7 08:55:15.396: RT: updating rip 10.255.196.192/28 (0x0)  :
    via 192.0.2.9 Vl192  0 1048578

*Feb  7 08:55:18.283: %DUAL-5-NBRCHANGE: EIGRP-IPv4 3000: Neighbor 10.119.200.2 (Vlan200) is down: holding time expired
*Feb  7 08:55:21.842: %DUAL-5-NBRCHANGE: EIGRP-IPv4 3000: Neighbor 10.119.200.2 (Vlan200) is up: new adjacency
*Feb  7 08:55:56.294: %DUAL-5-NBRCHANGE: EIGRP-IPv4 3000: Neighbor 10.119.2.2 (Vlan2) is down: holding time expired
*Feb  7 08:56:05.139: %DUAL-5-NBRCHANGE: EIGRP-IPv4 3000: Neighbor 10.119.2.2 (Vlan2) is up: new adjacency
*Feb  7 08:56:05.610: RT: updating eigrp 10.193.0.0/16 (0x0)  :
    via 10.119.2.2 Vl2  0 1048578

*Feb  7 08:56:05.611: RT: rib update return code: 17
*Feb  7 08:56:05.612: RT: updating eigrp 10.192.0.0/16 (0x0)  :
    via 10.119.2.2 Vl2  0 1048578

*Feb  7 08:56:05.614: RT: rib update return code: 17
*Feb  7 08:56:05.615: RT: updating eigrp 10.102.0.0/16 (0x0)  :
    via 10.119.2.2 Vl2  0 1048578

*Feb  7 08:56:05.617: RT: rib update return code: 17
*Feb  7 08:56:05.620: RT: updating eigrp 10.0.2.0/24 (0x0)  :
    via 10.119.2.2 Vl2  0 1048578

*Feb  7 08:56:05.621: RT: rib update return code: 17
*Feb  7 08:56:05.880: RT: updating eigrp 10.82.0.0/16 (0x0)  :
    via 10.119.2.2 Vl2  0 1048578

*Feb  7 08:56:05.880: RT: rib update return code: 17
*Feb  7 08:56:05.881: RT: updating eigrp 10.131.0.0/16 (0x0)  :
    via 10.119.2.2 Vl2  0 1048578

*Feb  7 08:56:05.881: RT: rib update return code: 17
*Feb  7 08:56:05.882: RT: updating eigrp 10.129.0.0/16 (0x0)  :
    via 10.119.2.2 Vl2  0 1048578

*Feb  7 08:56:05.882: RT: rib update return code: 17
*Feb  7 08:56:05.889: RT: updating eigrp 10.120.0.0/16 (0x0)  :
    via 10.119.2.2 Vl2  0 1048578

*Feb  7 08:56:05.890: RT: rib update return code: 17
*Feb  7 08:56:06.158: RT: updating eigrp 10.196.0.0/16 (0x0)  :
    via 10.119.2.2 Vl2  0 1048578

*Feb  7 08:56:06.158: RT: rib update return code: 17

 

3850#show ip eigrp events
Event information for AS 3000:
1    08:57:56.154 Poison squashed: 10.119.200.0/24 reverse
2    08:57:56.154 Ignored route, dup routerid int: 10.119.2.1
3    08:57:56.151 Change queue emptied, entries: 1
4    08:57:56.151 Metric set: 10.196.0.0/16 metric(Infinity)
5    08:57:56.151 Route installing: 10.196.0.0/16 10.119.2.2
6    08:57:56.151 Find FS: 10.196.0.0/16 metric(Infinity)
7    08:57:56.151 Rcv update met/succmet: metric(3072) metric(2816)
8    08:57:56.151 Rcv update dest/nh: 10.196.0.0/16 10.119.2.2
9    08:57:56.151 Metric set: 10.196.0.0/16 metric(Infinity)
10   08:57:56.151 Ignored route, inaccessible: 10.255.196.176/28 metric(Infinity)
11   08:57:56.151 Ignored route, inaccessible: 10.255.196.192/28 metric(Infinity)
12   08:57:56.150 Metric set: 10.82.0.0/24 metric(2304768)
13   08:57:56.150 Update reason, delay: new if delay(Infinity)
14   08:57:56.150 Update sent, RD: 10.82.0.0/24 metric(Infinity)
15   08:57:56.150 Update reason, delay: metric chg delay(Infinity)
16   08:57:56.150 Update sent, RD: 10.82.0.0/24 metric(Infinity)
17   08:57:56.150 Route installed: 10.82.0.0/24 10.119.2.2
18   08:57:56.150 Route installing: 10.82.0.0/24 10.119.2.2
19   08:57:56.150 Find FS: 10.82.0.0/24 metric(Infinity)
20   08:57:56.150 Rcv update met/succmet: metric(2304768) metric(2304512)
21   08:57:56.150 Rcv update dest/nh: 10.82.0.0/24 10.119.2.2
22   08:57:56.150 Metric set: 10.82.0.0/24 metric(Infinity)
23   08:57:56.131 Change queue emptied, entries: 21
24   08:57:56.131 Metric set: 10.82.0.0/17 metric(2304768)
25   08:57:56.131 Update reason, delay: new if delay(Infinity)
26   08:57:56.131 Update sent, RD: 10.82.0.0/17 metric(Infinity)
27   08:57:56.131 Update reason, delay: metric chg delay(Infinity)
28   08:57:56.131 Update sent, RD: 10.82.0.0/17 metric(Infinity)
29   08:57:56.131 Route installed: 10.82.0.0/17 10.119.2.2
30   08:57:56.131 Route installing: 10.82.0.0/17 10.119.2.2
31   08:57:56.130 Find FS: 10.82.0.0/17 metric(Infinity)
32   08:57:56.130 Rcv update met/succmet: metric(2304768) metric(2304512)
33   08:57:56.130 Rcv update dest/nh: 10.82.0.0/17 10.119.2.2
34   08:57:56.130 Metric set: 10.82.0.0/17 metric(Infinity)
35   08:57:56.130 Metric set: 10.102.11.0/24 metric(2305024)
36   08:57:56.130 Update reason, delay: new if delay(Infinity)
37   08:57:56.130 Update sent, RD: 10.102.11.0/24 metric(Infinity)
38   08:57:56.130 Update reason, delay: metric chg delay(Infinity)
39   08:57:56.130 Update sent, RD: 10.102.11.0/24 metric(Infinity)
40   08:57:56.130 Route installed: 10.102.11.0/24 10.119.2.2
41   08:57:56.130 Route installing: 10.102.11.0/24 10.119.2.2
42   08:57:56.130 Find FS: 10.102.11.0/24 metric(Infinity)
43   08:57:56.130 Rcv update met/succmet: metric(2305024) metric(2304768)
44   08:57:56.130 Rcv update dest/nh: 10.102.11.0/24 10.119.2.2
45   08:57:56.130 Metric set: 10.102.11.0/24 metric(Infinity)
46   08:57:56.130 Metric set: 10.102.5.0/24 metric(2305024)
47   08:57:56.130 Update reason, delay: new if delay(Infinity)
48   08:57:56.130 Update sent, RD: 10.102.5.0/24 metric(Infinity)
49   08:57:56.130 Update reason, delay: metric chg delay(Infinity)
50   08:57:56.130 Update sent, RD: 10.102.5.0/24 metric(Infinity)
51   08:57:56.130 Route installed: 10.102.5.0/24 10.119.2.2
52   08:57:56.130 Route installing: 10.102.5.0/24 10.119.2.2
53   08:57:56.130 Find FS: 10.102.5.0/24 metric(Infinity)
54   08:57:56.130 Rcv update met/succmet: metric(2305024) metric(2304768)
55   08:57:56.130 Rcv update dest/nh: 10.102.5.0/24 10.119.2.2
56   08:57:56.130 Metric set: 10.102.5.0/24 metric(Infinity)
57   08:57:56.130 Metric set: 10.240.0.0/22 metric(2305024)
58   08:57:56.130 Update reason, delay: new if delay(Infinity)
59   08:57:56.130 Update sent, RD: 10.240.0.0/22 metric(Infinity)
60   08:57:56.130 Update reason, delay: metric chg delay(Infinity)
61   08:57:56.130 Update sent, RD: 10.240.0.0/22 metric(Infinity)
62   08:57:56.130 Route installed: 10.240.0.0/22 10.119.2.2
63   08:57:56.130 Route installing: 10.240.0.0/22 10.119.2.2
64   08:57:56.130 Find FS: 10.240.0.0/22 metric(Infinity)
65   08:57:56.130 Rcv update met/succmet: metric(2305024) metric(2304768)
66   08:57:56.130 Rcv update dest/nh: 10.240.0.0/22 10.119.2.2
67   08:57:56.130 Metric set: 10.240.0.0/22 metric(Infinity)
68   08:57:56.130 Metric set: 10.254.0.0/24 metric(2305024)
69   08:57:56.130 Update reason, delay: new if delay(Infinity)
70   08:57:56.130 Update sent, RD: 10.254.0.0/24 metric(Infinity)
71   08:57:56.130 Update reason, delay: metric chg delay(Infinity)
72   08:57:56.129 Update sent, RD: 10.254.0.0/24 metric(Infinity)
73   08:57:56.129 Route installed: 10.254.0.0/24 10.119.2.2
74   08:57:56.128 Route installing: 10.254.0.0/24 10.119.2.2
75   08:57:56.128 Find FS: 10.254.0.0/24 metric(Infinity)
76   08:57:56.128 Rcv update met/succmet: metric(2305024) metric(2304768)
77   08:57:56.128 Rcv update dest/nh: 10.254.0.0/24 10.119.2.2
78   08:57:56.128 Metric set: 10.254.0.0/24 metric(Infinity)
79   08:57:56.128 Metric set: 10.210.0.0/23 metric(2305024)
80   08:57:56.128 Update reason, delay: new if delay(Infinity)
81   08:57:56.128 Update sent, RD: 10.210.0.0/23 metric(Infinity)
82   08:57:56.128 Update reason, delay: metric chg delay(Infinity)
83   08:57:56.128 Update sent, RD: 10.210.0.0/23 metric(Infinity)
84   08:57:56.128 Route installed: 10.210.0.0/23 10.119.2.2
85   08:57:56.128 Route installing: 10.210.0.0/23 10.119.2.2
86   08:57:56.128 Find FS: 10.210.0.0/23 metric(Infinity)
87   08:57:56.128 Rcv update met/succmet: metric(2305024) metric(2304768)
88   08:57:56.128 Rcv update dest/nh: 10.210.0.0/23 10.119.2.2
89   08:57:56.128 Metric set: 10.210.0.0/23 metric(Infinity)
90   08:57:56.128 Metric set: 10.208.0.0/23 metric(2305024)
91   08:57:56.128 Update reason, delay: new if delay(Infinity)
92   08:57:56.128 Update sent, RD: 10.208.0.0/23 metric(Infinity)
93   08:57:56.128 Update reason, delay: metric chg delay(Infinity)
94   08:57:56.128 Update sent, RD: 10.208.0.0/23 metric(Infinity)
95   08:57:56.128 Route installed: 10.208.0.0/23 10.119.2.2
96   08:57:56.128 Route installing: 10.208.0.0/23 10.119.2.2
97   08:57:56.128 Find FS: 10.208.0.0/23 metric(Infinity)
98   08:57:56.128 Rcv update met/succmet: metric(2305024) metric(2304768)
99   08:57:56.128 Rcv update dest/nh: 10.208.0.0/23 10.119.2.2
100  08:57:56.128 Metric set: 10.208.0.0/23 metric(Infinity)

Hi

 

Did you notice this in the sh ip eigrp events?

 

2 08:57:56.154 Ignored route, dup routerid int: 10.119.2.1

 

Seems you have a conflict. I would suggest configuring a static router-id.

There isn't a conflict that I can see. 

 

I configured each router with a router-id.  

3850: 10.119.2.1   > changed to 1.1.1.1

2951: 10.119.2.2

 

I changed the router-id on the 3850 to 1.1.1.1 and show ip eigrp events shows the same with the new router-id:

 

Event information for AS 3000:
1    10:46:31.105 Poison squashed: 10.119.200.0/24 reverse
2    10:46:31.105 Ignored route, dup routerid int: 1.1.1.1

I upgraded the code to 16.06.04a as well to no avail. 

 

Not to push it, but did you issue clear ip eirgp AS_Num after changing the route-id?

Are the flushed routes external or internal?

 

I would suggest looking at :

1. Show ip eigrp topology  or for a specific network x.x.x.x - This tells you if you see the expected routes and from who it is being originated

 

2. Check you redistribution

 

3. Check your distribute-list

 

I just wonder if you are seeing a "war" between two EIGRP nodes injecting an external route for the involved prefix or the result of a route filter applied outbound on local node on interface receiving the unwanted update.

 

EIGRP router-id is placed in a field of external EIGRP routes and allows for a consistency checks before accepting an external route.

 

 

I think you are on the right track about the 'war' or 'race' condition.  I shut down the busiest vlans over there and let EIGRP run without issue.  Brought up those vlans 1 by 1 and now EIGRP has been stable for the past 25 minutes and no dup ID in the logs.  

 

EIGRP-IPv4 Neighbors for AS(3000)
H   Address                 Interface              Hold Uptime   SRTT   RTO  Q  Seq
                                                   (sec)         (ms)       Cnt Num
1   10.119.200.2            Vl200                    13 00:26:41  654  3924  0  472
0   10.119.2.2              Vl2                      11 00:26:41    5   100  0  10680

 

Thanks for the update. If all is well, mark as "helpful", so as to help others in the future.

 

One thing though, did you get a log of the topology for each network as I suggested? That would help you investigate what router was originating the routes and if it was the right router. Maybe could have been another upstream device redistributing same networks. Just do a complete check of configs, as this would limit the possibility of such happening again. Probably best to stick with static router ids.

 

Cheers

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: