Anyone have good way to prevent looped uplinks creating BPDU storms? 2

[VOIPaintEASY]

I am not talking about Spanning tree loop from 1 port to another on the same switch. We have 9 floors with a closet that have Baystack 460/ 470 stacks or 8300’s. The scenario is if you take a Netgear switch (the cheap 4 or 8 port type that people put in their office to run 2-3 PC’s.) and uplink it to your closet stack or switch. Then on the cheap netgear loop a cable from one port to another. It starts flooding the single uplink to your production network with broadcast or multicast BPDU packets. THis happens under desks on occasion. Problem is, you can take down the WHOLE dam network by creating the BPDU storm. What starts happening next is the MLT or SMLT uplinks start disabling because of CP-Limit’s get him. Problem is it likely takes down multiple uplinks to critical stacks or in our case SMLT uplinks to data center 8300’s. Yes, the ports do what they are supposed to but the aftermath is downtime and outage. I know the new 470 BOSS code has the BPDU limit function and I use it but the 8300’s in our closets and data center don’t. We had a bad outage last week again as a result of this.

 

[rizzah1977]

Maybe not really helpfull on short term, but you can limit the network damage to make vlan's.. While i say this, im thinking .. well your not new to this .. so you probably thought of this yourself too

grtz
Peter

 

[VOIPaintEASY]

YEs, we have voice and data VLANs. It dont help much as it disable the MLT/ SMLT uplinks to the stacks. So, the whole stack is useless. More important it sends these broadcasts everywhere including data center swithces, etc.

 

[Alainv]

I guess you have 8600's in the core since you mention SMLT?
If yes, try the slpp feature in versionn 4.1.1.

If you are using SMLT with 8300, I don't know when it will be integrated in that platform...

 

[Kwazzy]

We have stopped the BPDU broadcasts by Enabled STP on the STG level, and disabling STP on the port level. We do this only to the uplink trunks.

This was recommended by Nortel a while back to prevent us from looping the BPDU packets. I feel your pain, but this has worked for us.

 

[Kwazzy]

Let me explain it this way:

You may know this, but for others who do not, it may be useful.

Copied from Howstuffworks.com (easier to explain than to type in my own words.)

Each switch begins a discovery process to choose which network paths it should use for each segment. This information is shared between all the switches by way of special network frames called bridge protocol data units (BPDU). The parts of a BPDU are:
Root BID - This is the BID of the current root bridge.
Path cost to root bridge - This determines how far away the root bridge is. For example, if the data has to travel over three 100-Mbps segments to reach the root bridge, then the cost is (19 + 19 + 0) 38. The segment attached to the root bridge will normally have a path cost of zero.
Sender BID - This is the BID of the switch that sends the BPDU.
Port ID - This is the actual port on the switch that the BPDU was sent from.
All of the switches are constantly sending BPDUs to each other, trying to determine the best path between various segments. When a switch receives a BPDU (from another switch) that is better than the one it is broadcasting for the same segment, it will stop broadcasting its BPDU out that segment. Instead, it will store the other switch's BPDU for reference and for broadcasting out to inferior segments, such as those that are farther away from the root bridge.

What happens when you disable at the port level, you are keeping STP alive on the vlan but you are limiting the broadcast of the BPDU packet from forwarding on. A BPDU packet will flood ALL ports in the same STG of a switch. Regaurdless of the setup at the vlan level.

If you want to keep STP alive on the edge to prevent the users from looping your network, but you want to stop the broadcasts from your known uplinks. (Those are the ports you have control of so you do not need to worry about looking there... unless you do not fully understand STP.)

Here is the example that I have seen this:

____ ____
| | | |
|8600|----|edge|
| |----| A |
---- ----
|
____
| |
|edge| __________
| B |----|User Loops|
---- ----------

Edge "B" will send its BPDU loop from the user back to the core and the core will send it out both links to "A". (The two links are not MLT but separate VLANs) "A" will return the two packets it recieved from 8600 to back off the interface opposite it recieved it on. This single act just doubled the broadcast. It happens because this is not a segment broadcast, but a STP broadcast for discovery. This is where the BPDU packet is killing you. These packets will continuosly double every time it hits the loop. Until the CPU gives up and locks the switch. Normally within seconds of the first BPDU. If you stop the loop at the port level, this will prevent re-broadcast the BPDU packets out. The BPDU packets will hit the 8600, but not reflood out its ports. It will stop at the port level on the 8600. If you leave it at the end user, you should see a port that is in the STP Blocked state. And limiting the BPDU broadcasts from hitting the rest of the network.

 

[VOIPaintEASY]

Kwazzy,

Do you run SMLT uplinks to the 8600's (1 to each from a stack or closet switch?

 

[Kwazzy]

The links we ran were independant trunk links going to different vlans. So at the time they were separate links going to two different 8600 chassis's. This setup was prior to SMLT option.

They are now an SMLT setup to the edge for the redundancy.

 

[SwitchBhoy]

Hi VOIPaintEASY

In an SMLT enviroment the solution to your problem is SLPP (simple loop protection protocol). it was designed exaclty to solve this type of issue, i.e. loops on the edge switch or misconfiguration of MLT links on the edge switch.

SLPP operates on the 8600 and is transparent to the egde switch. The protocol works by TX SLPP hello packets out of all the SMLT ports on the 8600. Under normal operation the port will TX slpp packets but will never recieve a SLPP hello packet. This is because under normal operation the packets "die" on the edge switch. However if a loop exists on the edge, the TX hello sent down one SMLT port will be RX on the neighbouring 8600 SMLT port. Upon recieving a set number of hello frame (configurable) the 8600 will shutdown it's port and therefore break the loop and protect he network from the mis-configuration at the edge.SLPP is supported from the 4.1 release onwards.

There is a second solution to your problem if you don't want to upgrade. Which basically mimics the behaviour of SLPP. Create a control vlan on the SMLT ports of the 8600 but not on the IST link but a seperate dedicated interswitch link (10/100mbs port). Also create the vlan on the edge switch. Within this control vlan enable VRRP and enable CP-limit on the SMLT ports. The VRRP hello frames will now act as the SLPP hello frames. If a loop occurs on the edge switches the VRRP packets will start looping with the control vlan, resulting in the CP-limit kicking and shutdown the offending port and protecting the rest of the network.

 

[repaRU]

If Netgear switch support STP protocol it must prevent organizing loop when two ports of switch is interconnected.
In other case switch not support STP protocol and BPDU can’t flood Ethernet segment. Or STP protocol realization is not correct and STP protocol must be disabled on this switch globally or other switch only on connected port.

Try on other switch disabling STP protocol and limiting broadcast and multicast packets at very low rate (1-2%).

If connection between switch is SMLT not use recommendation above.