Losing all eigrp adjacencies

[ktwaddell]

Morning All,

I am putting in a new network and I am losing all eigrp adjacencies everytime a new neighbour joins or leaves on every switch in the group.

Config is very simple

spct-stjam-f02-cs1#sh runn | b router eigrp 90

router eigrp 90

network 10.202.128.0 0.0.31.255

network 172.16.0.0

redistribute ospf  1 metric 10000 100 255 1 1500

all switches on vlan 6 10.202.138.32/27

logs reports the holddown timer has the issue, but why would all adjacencies be reset because a switch comes or goes off line?

Thanks

Kev

[Giuseppe Larosa]

Hello Kev,

is a form of STP running on vlan 6?

if the addition or removal of an EIGRP neighbor means an STP topology change, STP has to recalculate.

With standard PVST the convergence time can be up to 50 seconds and during this time no user traffic including EIGRP messages are forwarded, so EIGRP holdtime expires after 15 seconds with default settings.

You should consider the use of Rapid PVST to achieve faster STP convergence ( sub-second is possible) to be enabled on all switches

Hope to help

Giuseppe

[ktwaddell]

Hi Giuseppe,

I knew I had missed something stupid but couldn't work it out, I have changed over to Rapid to all switches, I then rebooted one of the switches to se what happened and even though it didn't stop the network it still did this

ul 11 09:10:44.188: %DUAL-5-NBRCHANGE: EIGRP-IPv4 90: Neighbor 10.202.138.34 (Vlan6) is down: interface down

Jul 11 09:10:44.188: %DUAL-5-NBRCHANGE: EIGRP-IPv4 90: Neighbor 10.202.138.37 (Vlan6) is down: interface down

Jul 11 09:10:44.197: %DUAL-5-NBRCHANGE: EIGRP-IPv4 90: Neighbor 10.202.138.36 (Vlan6) is down: interface down

Jul 11 09:10:44.197: %DUAL-5-NBRCHANGE: EIGRP-IPv4 90: Neighbor 10.202.138.39 (Vlan6) is down: interface down

Jul 11 09:10:44.222: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan6, changed state to up

Jul 11 09:10:45.103: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/4, changed state to down

Jul 11 09:10:46.092: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/4, changed state to down

Jul 11 09:10:46.092: %DUAL-5-NBRCHANGE: EIGRP-IPv4 90: Neighbor 10.202.138.36 (Vlan6) is up: new adjacency

Jul 11 09:10:46.092: %DUAL-5-NBRCHANGE: EIGRP-IPv4 90: Neighbor 10.202.138.34 (Vlan6) is up: new adjacency

Jul 11 09:10:46.587: %DUAL-5-NBRCHANGE: EIGRP-IPv4 90: Neighbor 10.202.138.37 (Vlan6) is up: new adjacency

so it's bringing down the vlan interface now, any ideas?

Many Thanks

Kev

[ktwaddell]

NB

It did it again when the rebooted switch came back up

Jul 11 09:13:50.270: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan6, changed state to down

Jul 11 09:13:50.286: %DUAL-5-NBRCHANGE: EIGRP-IPv4 90: Neighbor 10.202.138.37 (Vlan6) is down: interface down

Jul 11 09:13:50.286: %DUAL-5-NBRCHANGE: EIGRP-IPv4 90: Neighbor 10.202.138.34 (Vlan6) is down: interface down

Jul 11 09:13:50.286: %DUAL-5-NBRCHANGE: EIGRP-IPv4 90: Neighbor 10.202.138.36 (Vlan6) is down: interface down

Jul 11 09:13:50.370: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan6, changed state to up

Jul 11 09:13:50.630: %DUAL-5-NBRCHANGE: EIGRP-IPv4 90: Neighbor 10.202.138.34 (Vlan6) is up: new adjacency

Jul 11 09:13:50.639: %DUAL-5-NBRCHANGE: EIGRP-IPv4 90: Neighbor 10.202.138.39 (Vlan6) is up: new adjacency

Jul 11 09:13:50.639: %DUAL-5-NBRCHANGE: EIGRP-IPv4 90: Neighbor 10.202.138.36 (Vlan6) is up: new adjacency

Jul 11 09:13:50.655: %DUAL-5-NBRCHANGE: EIGRP-IPv4 90: Neighbor 10.202.138.37 (Vlan6) is up: new adjacency

Jul 11 09:13:50.689: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/4, changed state to up

Jul 11 09:13:51.696: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/4, changed state to up

[Peter Paluch]

Hello Kev,

Are you running EIGRP on multilayer switches? If so then Giuseppe was right - your connection or disconnection of a switch speaking EIGRP causes STP to trip.

Can you post a diagram of your topology? Perhaps the STP needs to be tuned.

Best regards,

Peter

[ktwaddell]

Hi Peter,

Yes all devices are 3750's floor switches are ip base on a eigrp stub config and core switches are 3750x with IP Services running full EIGRP.

will try and upload a diagram for you

thanks

Kev

I am having problems trying to upload a picture

to be honest it's pretty simple

2 core switches with a link between them on vlan 6

4 floor switches with a link to both core switches also on vlan 6

does that help?

[Giuseppe Larosa · Accepted solution]

Hello Kev,

from the log messages it looks like that the only port in broadcast domain Vlan 6 is gi1/0/4 in this device, so when this port goes down  the SVI Vlan 6 goes down too, and when the port recovers the SVI becomes up/up again

May you post

show vlan 6

on the affected switch?

Are you sure that both uplinks, if this is an access switch, carry vlan 6 and are operational? ( I guess they are L2 trunks)

What is the switch that you have reloaded? one core switch or an access switch?

Hope to help

Giuseppe

[Peter Paluch]

Hello Giuseppe and Kev,

Giuseppe: There is a possibility that STP might have something to do with this. However, I do not see how the legacy STP could cause these issues. In legacy STP, unless the root port changes, connections or disconnections of other ports do not lead to STP blocking any other ports - there's no reason to do that. The ensuing topology change in STP merely causes unused entries from CAM tables to be flushed after 15 seconds - but that only causes temporary flooding and should not lead to a loss of connectivity.

With RSTP, it might be more convoluted and deploying it may actually worsen things if not done cautiously. Again, even with RSTP, unless the root port changes, no blocking of other ports will happen. However, if a new root port is detected, the Proposal/Agreement mechanism is invoked which will lead to all non-edge Designated ports being moved into Discarding state. If the ports towards EIGRP routers are not properly configured as edge ports, any Proposal/Agreement wave going through this switch will cut off the EIGRP routers for 30 seconds. This it, in my opinion, the greatest danger in plainly deploying RSTP without planning.

However, a connection of an EIGRP router should not cause a change in that switches' root port so nothing of what I just described should actually happen - unless, of course, the another EIGRP router happens also to be a switch (a multilayer switch, obviously).

It would help if we could see a picture of the L2/L3 topology including the types of devices used.

Best regards,

Peter

[ktwaddell]

Hi Giuseppe,

I have also been getting help from a friend and all along you have both been on the same lines, a sh vlan 6 on both core switches showned the floor switch on g1/0/4 was the root for vlan, it was by pure chance this was the one I kept rebooting for testing.

Changing the priority for vlan 6 on cs1 & cs2 has stopped the vlan from going down and tests have it working

Some good lessons learnt here for me, I am used to doing point to point when using L3 uplinks an never considered spanning tree messing me up.

Many Thanks

Kevin

[Peter Paluch]

Hi Kevin,

We're glad to know you were able to find a solution!

If possible, please be so kind as to mark this thread as resolved by clicking on the "Correct Answer" button displayed in Giuseppe's answers. He did correctly identify the root cause and focused you on the right track. This will help others with a similar issue to find solution more quickly.

Thanks!

Best regards,

Peter

[Giuseppe Larosa]

Hello Peter,

there is only one point that is not clear to me:

Even if the rebooted switch was the STP root bridge and it was inserted and removed many times, this should not cause the SVI Vlan 6 to go down on another switch like a core switch.

Not all events may have produced the same log messages I guess.

However, I'm happy that the original poster has solved his issue.

Hope to help

Giuseppe

[Peter Paluch · Accepted solution]

Hi Giuseppe,

My understanding is that with legacy STP, if the second switch that happened to be the root bridge for VLAN 6 was rebooted, it caused a change of the root port on the first switch (or the idea about who the root bridge is in the first place). Whenever a root port or the knowledge about a root bridge is changed, the STP resets the states of all ports. So with the change of the root port on the first switch, all ports were reset to the Listening state. As a consequence, there was no switchport with the VLAN 6 currently allowed by configuration and STP - and hence the SVI for VLAN 6 went down.

Best regards,

Peter

[ktwaddell]

Hi Guys

It was by pure chance the switch I was rebooting for testing was in fact the root bridge for vlan 6, also I made an error in that the 2nd core switch has no Vlan 6 link to the 1st core switch so rebooting the root bridge was bringing down Vlan 6 on both core switches.

I have now set it so core switch 1 is the root with core switch 2 being backup and put in a vlan 6 link between the core switches.

Many thanks for your help

Cheers

Kev