Potential spanning tree loop, UDLD etc.

Unanswered Question

I have 4 core 6500's that are connected in this fashion. A to B, B to C, C to D, and D to A. These core switches feed distribution switches in various wiring closets. Recently, I lost all connectivity to distribution switches off 6500 C intermittently during about a 7 hour interval. Finally at the 7th hour the connection on core 6500 A to core 6500 D logged a UDLD error and shut down with err-disabled. Since then all is stable. I theorize that during the 7 hour interval the connection was having problems, causing periodic spanning tree recalculation and temporary loss of connectivity. Now, how can I verify that there is indeed an issue on the link between core switch A and D? If there was periodic spanning tree recalculation, Why? Shouldn't UDLD have shut down the port earlier, preventing the possibility of periodic connectivity. If I shut/no shut the port UDLD err-disabled I am afraid that it might work for now, but cause the same problem again in the future. Is it possible there is no physical link problem but something else going on? Any opinions are appreciated. Thanks.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Kevin Dorrell Wed, 11/28/2007 - 07:28
User Badges:
  • Green, 3000 points or more

It sounds like the link was failing intermittently, and finally gave up. Your problem is now to identify which end of the cable, A or D, was at fault.

Do you have any spare ports on both switches and a cable run between them? If so, then it makes life easier. Create a spare unused VLAN, and configure your flaky ports as access ports on that VLAN. Disallow that VLAN on the other trunks. Then just connect the flaky ports together and watch to see if it fails. If the VLAN is not used anywhere else, you will not be disturbing any production traffic.

If it does fail, move the link at one end to a spare port, and see if that fails. If not, then reverse those positions. When you have found the port, replace the GBIC first. (Not because it is the likely cause of the failure, but because it is the least disruptive thing to change.) If that does not work, replace the offending card.

Kevin Dorrell


Thanks. I created a spare unused vlan. I then placed the flaky ports on this vlan and connected them together. This means I deleted all reference to trunk configuration on these ports and used this configuration:

Switch D

interface GigabitEthernet2/3


switchport access vlan 850

no ip address

Switch A

interface GigabitEthernet2/1


switchport access vlan 850

no ip address

I then activated the 2 ports. They came up and formed an ISL trunk and began participating in the spanning tree. (I use dot1q everywhere else.) So now, I have both ports configured for vlan 850 but they are a trunk. I am unsure about disabling the ports as I fear a spanning tree recalcuation that will cause a temporary outage while reconvergence takes place. But, I don't want to leave the configuration, as is, given the inconsistency that a trunk has been formed. Any thoughts?


This Discussion