[f-nsp] Spanning tree on brocade

[Jethro R Binks]

Some thoughts;

"What happened" may be hard to determine at this point, but generally 
apart from the obvious causes (like cabling and config mistakes), one 
possible is that someone connected a device in a way that connected 
together two vlans together and caused the instability (you might never 
find that).  Or a device handling multiple VLANs failed in some way.

What's more interesting is how to protect yourself for the future.  At a 
minimum, if you are completely Brocade, ensure you are running 802.1w in 
each vlan on all the devices:

vlan xyz
 spanning-tree 802-1w

and on one device which you choose, specifically define it is to be the 
root bridge:

vlan xyz
 spanning-tree 802-1w
 spanning-tree 802-1w priority 0

You can also consider the following, which you will probably find in any 
generic spanning tree reference:

Where you have edge connections, consider explicitly set them to be edged 
with spanning-tree 802-1w admin-edge-port (which stops them becoming part 
of the spanning tree so cuts down on needless STP calculations when they 
come up and down).  Then enable stp-bpdu-guard on them so they will shut 
down if someone does something rash and creates a loop there, or tries to 
extend your network by connecting their own stp-aware devices.

For links between network devices, consider explicitly setting them to be 
p2p with spanning-tree 802-1w admin-pt2pt-mac.

Be aware that making changes, such as changing spanning tree type (from 1d 
to 1w or 1s) usually causes some initial disruption so you might want to 
plan out what you are going to change and where and get a downtime window 
where you can progress it out.  Don't do it until you are sure you know 
what connects to where and that there are no unknown parts.

If you want to give management something to do, ask them to support a 
policy that absolutely forbids anyone from extending the network (by 
adding hubs/switches for themselves) without authorisation, if you are in 
the sort of environment where that could cause you issues.  If you are 
aiming for an accurate predictable STP deployment, you really really want 
to know exactly what the network looks like and don't want someone else 
adding bits to it without you knowing.

And sometimes switches do go bad.  Really really bad.

Jethro.



On Wed, 18 May 2016, Nick Cutting wrote:

> No routing at all
> 
> The meltdown is almost certainly the result of 6 Fastirons, 2 turboIrons 
> running a combination of IEEE, 802.1w and No spanning tree at all. Ive 
> diagrammed this now for each vlan, and I have found some serious deisgn 
> issues.
> 
> MGT wanted me to figure out what happened, All I can think about is how 
> to fix this - i.e 801.w everywhere, on all vlans - It seems that this 
> runs as a per-vlan spanning tree flavor?
> 
> NickC
> 
> From: Nick Hilliard [mailto:nick at foobar.org]
> Sent: Wednesday, May 18, 2016 10:28 AM
> To: Eldon Koyle
> Cc: Nick Cutting; foundry-nsp
> Subject: Re: [f-nsp] Spanning tree on brocade
> 
> Eldon Koyle wrote:
> > That is _really_ old code on the turboiron. It may be the version they
> > shipped with, which was extremely buggy. You are correct that it is
> > routing code (TIR is routing, TIS is switching). Are you doing any
> > routing on that device?
> 
> old and buggy, but stp on 4.02.00c was fine. If there was an STP
> meltdown, it's more likely to have been the result of a network misconfig.
> 
> 7.3.00f was the next usable version of the tix code after 4.02.00c.
> Upgrading would be a really good idea, not least due to the unicast
> flooding problem in all versions of the turboiron code before 7.3
> (DEFECT000362191).
> 
> Nick
> 
> ________________________________
> 

.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
Jethro R Binks, Network Manager,
Information Services Directorate, University Of Strathclyde, Glasgow, UK

The University of Strathclyde is a charitable body, registered in
Scotland, number SC015263.