4

We have about 30 switches (multiple vendors) in a network which consists of a main ring and several branches. A couple of the branches may have loops. Some of the switches are smart switches with RSTP enabled, most of the switches are either smart switches with RSTP disabled or dumb switches.

When the diameter of the RSTP-enabled switches is around 10, we're getting convergence times after a topology change of under a minute. As we increase the diameter the convergence time scales up dramatically, hitting 15-20 minutes as the diameter approaches 13 or 14. This looks like it might be a case of the network falling back to STP and the diameters being too large for the default STP settings on the switches. The same setup is being used for a different network and it rapidly converges in seconds.

Is there a way to isolate which switch might be causing the network to fall back to STP? Some of the switches provide more status details about the RSTP state (e.g. whether the port is RSTP/STP), but most of the switches provide very little diagnostic info.

| improve this question | |
  • Seriously, you should consider a different topology that decreases reliance on STP. Using distribution (no access switches connect to another access switch) and limiting any one VLAN to a single access switch (any one switch can have multiple VLANs, but those VLANs should not extend to any other access switches) are the best practices. – Ron Maupin♦ Mar 10 '17 at 18:57
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer. – Ron Maupin♦ Aug 17 '17 at 4:26
2

15 minute convergence? Ouch! ;) But yes, I agree with your suspicion - multiple 802.1D bridges scattered around the network could easily blow out convergence, as they block all ports other than root while in their Listening state - multiply this by a few boxes and you'll have quite a few topology state changes as the radius increases.

Firstly, if you're running STP, you need to run it on all switches period. Trying to diagnose whether BPDUs will be forwarded or dropped by switches with STP disabled is a path to madness.

If you have devices that don't support STP, either bin them, or move them out to the edges of the network where they can't interfere with the topology (eg: on a branch of the network with only 1 uplink and 1 downlink).

STP is hard to troubleshoot at scale because of the fact that there is really only unidirectional communication when everything is working - eg: BPDUs only travel out from the root of the tree, so it's hard to know the state of a downstream device from an upstream one. I would strongly suggest you print out a physical map of the network (or draw it), mark the root bridge and then connect to every adjacent bridge, marking out which is the root port (and speed), designated ports (and speed) and any blocked ports for each node.

Depending on the amount of information you can pull from each switch, you might be able to determine STP vs RSTP by the port costs associated to each interface - STP treats a 1Gbps interface as a port cost of 4 and RSTP treats them as a cost of 20,000 - this might give you a hint as to where the offending switches are.

| improve this answer | |
1

The default convergence time for 802.1D STP is 50 seconds. Something like 15-20 minutes is insanity. I agree with Ron in the comments - it sounds like you need a layer of distribution switches in your network to act as the STP roots for your VLANs. This helps keep things nice and orderly while ensuring that no loops occur.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.