Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

2950 Spanning-tree root problems in CAT5000 LAN

Status
Not open for further replies.

marks66

Technical User
Jun 7, 2001
65
GB
Hi,

I have recently upgraded some WS-C2950C-24 switches to version 12.1(9) to stop them constantly re-booting when snmp get commands are used.

There now seems to be another software bug, see debug below

Aug 6 10:42:31: STP: VLAN0026 we are the spanning tree root
Aug 6 10:42:33: STP: VLAN0016 we are the spanning tree root
Aug 6 10:42:33: STP: VLAN0020 we are the spanning tree root
Aug 6 10:42:35: STP: VLAN0006 we are the spanning tree root
Aug 6 10:42:36: STP: VLAN0014 new root is 8191, 0001.97a9.280d on port Fa0/25,
cost 27
Aug 6 10:42:36: STP: VLAN0016 new root is 8192, 0001.97ae.c40f on port Fa0/25,
cost 19
Aug 6 10:42:36: STP: VLAN0018 new root is 8191, 0001.97a9.2811 on port Fa0/25,
cost 27
Aug 6 10:42:37: STP: VLAN0019 we are the spanning tree root
Aug 6 10:42:37: STP: VLAN0021 we are the spanning tree root
Aug 6 10:42:38: STP: VLAN0026 new root is 8192, 0001.97a9.2819 on port Fa0/25,

The 2950s have a vlan priority in excess of 32768 and the root bridge has 8191.
The switches that have redundant links cause the whole LAN to stop periodically. Has anyone seen this and know the latest software that is bug free.

Cheers

Mark
 
Hi,

I would be most interested if you've got to the bottom of this yet. We have a Cat2900XL + Cat6509 environment which we have just added a number of Cat2950C-24s to. These are still at the buggy 12.0(5.3)WC1 pre-release from when we first installed them. We experienced your SNMP reboot issue with SNMP Gets from CiscoWorks.

We experienced a major loop condition which propagated from the Cat2950 and took the whole VTP domain out (60 VLANs across 120 switches).

We have a number of avenues to investigate:-

- UDLD mismatches - UDLD is off by default on the 2950 but on by default on chassis cats.In case of a unidirectional link occurring on a link having a blocked port, you have 50% chances of getting a bridging loop. This is the most dangerous possibility of STP failure, because the algorithm is not able to handle this situation at all.

- STP root problem - There is a current manufacturing field notice out on the Cat3550s where the BPDUs are corrupted leading to the device believing it is the root bridge. There has been a suggestion in some forums that this is also occurring on the 2950s.

- Still open caveat in 12.1(11) regarding dynamic address aging timers. We have seen addresses staying on both uplinks from the Cat2950 for upto 10 mins!! Whether this is was a symptom or a cause we are yet uncertain of.

None of these have proven possible to replicate in a lab environment... yet.

Frankly I resent upgrading for the sake of upgrading and as this is a stock Cisco line I quite often am left in this situation.

Regards,

Nick


 
No I have not got to the bottom yet. Latest suggestion from Cisco is to enable VTP pruning. I have not had the chance to try this. (They also say my Cat 5000s are very old!!)

I had the same problem with a 2950 which caused the whole VTP domain to fail. (26 Vlans over 60 switches) I have connected this 2950 with a single trunk and now it still tries to be the STP root but with no impact to the rest of the LAN.

Anyway:

UDLD is not available on the OLD 5000 series CATS. (We run CATOS 4.5.5)& all my trunks are ON and forced to 100/full so I don't think UDLD is the prob.

STP , it does look like the switch must miss some BPDUs for it to try and become the root, but there are no timers to help fix this.

I will try the VTP pruning, but I am not confident.

Cheers

Mark.Seaman@bat.com


 
Mark,

VTP pruning contains the issue to a certain extent but doesn't fix it. We are automatically pruning by default on all trunk links. We tried turning this off during our outage and it significantly impacted the rest of the VLANs.

We also found that the source eminated from a dual attached 2950C-24 on only one VLAN ( despite the fact that at least four VLANs were configured on the switch) and that by "manually pruning" ( CLEAR TRUNK VLAN ### etc) on one side only the problem was isolated. We then rebooted the switch and everything was fine.

Have you seen the number of Open caveats on the 12.1.11 code. Scary...

Regards,

Nick.Hancock@dsl.pipex.com
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top