EIGRP Holding time problem

Unanswered Question
Jul 10th, 2008

Jul 10 03:50:52: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.0.2.25 (Vlan1) is down: holding time expired

Jul 10 03:50:53: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.0.2.76 (Vlan1) is down: holding time expired

Jul 10 03:50:54: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.0.2.79 (Vlan1) is down: holding time expired

Jul 10 03:50:54: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.0.2.77 (Vlan1) is down: holding time expired

Jul 10 03:50:54: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.0.2.32 (Vlan1) is down: holding time expired

Jul 10 04:07:44: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.0.2.79 (Vlan1) is up: new adjacency

Jul 10 04:07:44: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.0.2.77 (Vlan1) is up: new adjacency

Jul 10 04:07:44: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.0.2.25 (Vlan1) is up: new adjacency

Jul 10 04:07:45: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.0.2.76 (Vlan1) is up: new adjacency

Jul 10 04:07:47: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.0.2.32 (Vlan1) is up: new adjacency

I have been receiving this error once a day, mostly early in the morning. I have 5 3560 configured as stub connected. My topology consists of a core 4506 doing intervlan routing network wide, and those 5 3560's running EIGRP are on a metro E ISP. Basically they carved out a layer 2 vlan for us and we just plug right into it. I am using VLAN 1(for now) as a transport vlan of the 3560's. Each of the 3560 have a few vlans and are doing intervlan routing for their location. Like i said they talk back to the 4506 with EIGRP. 3560's configured as a stub connected router. The reason i have them configured as a stub is because it seems to be a hub and spoke topology. Would this holding time problem be do to the STUB configuration? To my knowledge if a router is configured as a stub, then it doesn't expect to talk to any other router than the Hub (4506).

Here is a sh run from one of the 3560's...

ip routing

vlan 53

name ShenandoahDATA

!

vlan 54

name ShenandoahVoIP

!

interface FastEthernet0/1

switchport access vlan 54

switchport port-security mac-address 001e.4a60.0e48

spanning-tree portfast

!

interface FastEthernet0/2

switchport access vlan 53

switchport mode access

switchport voice vlan 54

switchport port-security mac-address 001e.13e6.05e9

spanning-tree portfast

!

interface FastEthernet0/3

shutdown

spanning-tree portfast

!

interface FastEthernet0/4

shutdown

spanning-tree portfast

!

interface FastEthernet0/5

shutdown

spanning-tree portfast

!

interface FastEthernet0/6

shutdown

spanning-tree portfast

!

interface FastEthernet0/7

shutdown

spanning-tree portfast

!

interface FastEthernet0/8

switchport access vlan 53

switchport mode access

switchport voice vlan 54

switchport port-security maximum 2

switchport port-security mac-address 0013.72d1.1498

switchport port-security mac-address 001e.13e5.f195

spanning-tree portfast

!

interface GigabitEthernet0/1

description Shenandoah WAN

switchport trunk encapsulation dot1q

switchport trunk allowed vlan 1

switchport mode trunk

!

interface Vlan1

ip address 10.0.2.77 255.255.248.0

!

interface Vlan53

description Shenandoah_DATA

ip address 10.0.53.1 255.255.255.0

ip helper-address 10.0.0.30

!

interface Vlan54

description Shenandoah_VOIP

ip address 10.0.54.1 255.255.255.0

!

router eigrp 100

network 10.0.0.0 0.0.255.255

auto-summary

eigrp stub connected

!

ip classless

ip route 0.0.0.0 0.0.0.0 10.0.0.1

no ip http server

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Kevin Dorrell Thu, 07/10/2008 - 04:42

The interesting bit is "once a day, mostly early in the morning". That implies it is not anything to do with he EIGRP timers themslves, otherwise it would be happeneing all the time.

Is it pssible that your VLAN 1 Spanning-Tree is reconverging once a day, maybe due to the root bridge getting rebooted. I guess I would check that the hub switch is actuall the root of VLAN, and if not, have a look through the logs of the switch that is actually the root.

Is it possible there is some link that gets saturated early in the morning, perhaps due to a server backup?

Kevin Dorrell

Luxembourg

cowetacoit Thu, 07/10/2008 - 04:54

Those are good points but as far as STP i would get alerts from all of my other switches as well. I'm just getting it on these 5 EIGRP 3560s. All of these sites are very small, less than 3 phones and 5 PC's. No back ups running on these links. the 4506 is configured as the root with priority 0. The only difference between these 5 switches are EIGRP and the Metro E ISP. They say nothing on their end of course.

Richard Burts Thu, 07/10/2008 - 04:50

Michael

I have looked at your config and do not see any obvious issues with it. I very much doubt that the issue of losing neighbor relationships is due to being configured as EIGRP stub. If it were an issue with EIGRP stub I would expect that it would happen more often than once a day. The error message about holding time expired indicates that the router has not received EIGRP hello messages for a period that exceeds the hold timer. I would think it is more likely that the issue is some event or some disruption on the Metro Ethernet. The fact that the neighbors were down for almost 17 minutes may support this theory.

Perhaps one way to test this would be to set up a long running ping from the core to one (or perhaps more) of the spoke routers. See if you lose ping packets at the time that the EIGRP neighbors drop.

[edit] I see Kevin's response and a spanning tree event is an interesting idea. But I have difficulty in thinking how spanning tree would cause a loss of connectivity from 3:50 to 4:07.

HTH

Rick

cowetacoit Thu, 07/10/2008 - 05:00

I'll get back with my ISP. I use to work for them so i know the process and how things are set up. I doubt it's STP either. I'm confident that i have EIGRP configured properly. The IOS on my core 4506 is extremely old and i need to update it. Could it be a possibility? I just can't schedule any downtime, of course it is used 24-7.

"spoke" 3560 log

Jul 10 03:50:51: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.0.0.1 (Vlan1) is down: holding time expired

Jul 10 04:07:45: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.0.0.1 (Vlan1) is up: new adjacency

cowetacoit Thu, 07/10/2008 - 05:14

I got it...ISP had maintenance at midnight to 1am. My NTP is off!!!!!!!!!!! Clocks are wrong. I jumped to conclusions i think because this happened a couple times last week. They would only go down for a couple seconds though.

Richard Burts Thu, 07/10/2008 - 11:26

Michael

The ISP having maintenance would certainly explain this outage. If you have been having other episodes lasting only a few seconds they might be something else. Perhaps they might be spanning tree related. Or they might be related to some kind of packet loss - I would wonder about momentary circuit congestion if they were not so early in the morning.

I had a similar issue with EIGRP neighbors flapping with EIGRP timer expiring in a network environment with high latency and occasional packet loss. We increased the EIGRP timers (both the hello and hold time timers) and the neighbors became much more stable. I do not know what you situation is for latency (but would assume that latency was not an issue) or packet loss. But you might try changing the EIGRP timers a bit and see if it becomes more stable.

HTH

Rick

cowetacoit Thu, 07/10/2008 - 11:36

ok, thanks for getting back with me. I'll keep an eye on it for a few days and see if the core reports anymore errors. If so i'll monitor all 5 switches by continuous ping. if no latency i'll adjust timers. Another thing to point out is when i was working for that ISP i set them up with a spanning tree ring for redundancy since they were a metro e provider with only vlans. one thing we did was configured BPDU Filter on all the ports that connected to customer switches. All of my 3560's at my current company are root bridges for their location because of this.

Actions

This Discussion