8600 ist - STP + VLAN issues

[rosenheim]

Our topology consists of 2x8600's, plus several BS450 & 5510 stacks.
The 450 stacks have only one optical uplink are attached to a single 8600. The 5510 stacks are attaced to both 8600's in a SMLT topology.
We use a single STG, group 1. STP is disabled on the ist ports. Our VLAN's span stacks and 8600's - thus the ist trunk ports are memebers of these VLANs.

Occassionally we experience network connectivity disruption which we suspect are caused by broadcast storms.
Is there a basic flaw in our topology which makes it vulnerable? An older post recommended that IST trunks belong to their own VLANs; how can this be achieved when our VLANs span as described?

 

[HungryHouse]

The IST itself will travel over its own VLAN, however the physical Ethernet interfaces may very well be tagged to carry mutliple VLANs across them. This is most have done that I have seen without issue.
There could be several things causing your network connectivity outages, but to take a WAG, its best practice to have CP-limit disabled on the IST ports. Is it in your config?
-HH

 

[anthonyanderberg]

Your design sounds OK, lots of folks use something similar - but of course the devil is in the implementation details. Its generally best practice to enable fast-start spanning tree on any user ports, and to leave it off on uplink/backbone ports that you can control and protect in other ways (IST/SMLT).

I'd second HungryHourse's comments about CP-limit, although as I recall when a port is CP-limit disabled it won't come back on its own - the port has to be disabled and re-enabled manually.

Nortel has a good document called the "converged campus technical solution guide" that outlines many of their best practices.
Here's a URL to what I think is the most recent version:

http://www116.nortelnetworks.com/do...us/Converged_CampusTechnicalSolutionGuide.pdf

 

[rosenheim]

Thanks, HungryHouse & Anthony for your advice. CP-limit was defined from the start, of course. Will download the document now and study it. Cheers!

 

[Jynxx]

Put your IST L3 communication in it's own VLAN, so that the L3 route exchange is in it's own broadcast domain. So just the IST ports on both would be in that VLAN, and that is what you would use for attaching the IP addresses and route info.

In regards to SMLT, ensure that the SMLT ID's are the same on both ports on both cores. Once you verify that, though it should do it by default, ensure that STG is disabled. However you can enable it from the persective of the edge switch MLT ports that connect to the cores.

Not certain what version of code you have installed on the 8600's, but in the VLAN config of the ports that face the edge switches, ensure that LoopDetect is turned off.

On the edge switches, ensure that STP fast start is enabled for all user facing ports as mentioned.

If you also run VRRP on the cores, set the advertisement interval to 3, which will result in less VRRP transitions. Also ensure that your costs are different on each core.

 

[VOIPaintEASY]

do any of your uplinks to the 8600's get disabled by the CP-Limit setting? (are you sure this feature is enabled on the uplink ports?) I have found the default of 20,000 packets per second is too high and will swamp the whole network before it finally does any good. I would drop your uplinks to 5000 for broadcasts and multicasts. If things run ok for a few weeks drop it again to the lowest setting which if I recall is 1000. I have had expensive expierince with broadcasts bringing down our Nortel LAN. MAinly from cheap Netgear switches in offices and conf. rooms that get looped from port to port from a cabling mess. The new Baystack code had a BPDU feature to disable the ports just because of our problems and I pitched a huge bitch to Nortel and threatened to switch all closets to Cisco for their BPDU Guard function. In any event, if you set you CP-Limits low on the uplinks you should find out what uplink caused it. A word of caution. If you use Device Manager and the switch shuts down an uplink. It will not be red or administratively down when looking at the DM interface. You only see it in the switch logs or your log server if you output to syslog. (I highly recomend that by the way). If CP=Limit shuts down a port you must adminstatively disable, then re- enable it to get it back on its feet. We can talk via phone if you want.