Mailing List Archive

The bridge ID is the bridge priority in hex (default 0xFFFF) followed by
the chassis MAC. This is part of the STP specification. The lowest bridge
ID is chosen as the root bridge (so the lower the priority value the more
likely a device is to become the spanning tree root, and when the priority
is equal the lower chassis MAC wins).

"VLAN ID" is the VLAN ID for this STP instance (or, often 4094 for the
common STP instance in single spanning tree; look for "L2 VLAN ... are
members of single spanning tree" in the output).

"Root ID" is the bridge ID of the global STP root device

"Bridge Address" is the chassis MAC of the device you are connected to (not
the Bridge ID)

"Designated Bridge" is the bridge ID of the local root

"Designated Root" is the bridge ID of the global root for this instance


Note that to see rstp info, you need to do 'show 802-1w' which has similar
output to 'show span', but drops the redundant "Designated Root" column and
adds a "Role" column (which I find a lot easier to understand). STP and
RSTP are completely separate on these devices.

You might try looking at the output of 'show span detail' and 'show span
802-1w detail' to see if that clears anything up for you.

Also, the priority is entered in decimal in the config (so you will
probably see a line like: 'spanning tree ... priority 25077' for your
device with 61f5 in its bridge id).

--
Eldon Koyle

On Mon, May 16, 2016 at 2:58 PM, Nick Cutting <ncutting@edgetg.com> wrote:

> Hi I am trying to document the spanning tree domain on a brocade
> environment that has both TurboIron-X24’s and FCX-48G’s
>
>
>
> I’m traditionally a cisco guy so need some help in figuring out the show
> output of show span.
>
>
>
> Right now we have a mix of rapid spanning tree and classic, I need help in
> understand which is the mac address of the root bridge, the root ports and
> the terminology used in the output.
>
>
>
> For example – is the root ID a mac address and the vlan ID added in Hex?
> What is the designated bridge ? is this is the downstream switches bridge
> ID?
>
>
>
> I can’t seem to match the bridge ID and the Root ID to mac address tables
> on the switch – is anyone able to shed light on these relationships and
> describe what each of the terms means below?
>
>
>
> I’m guessing the first 4 digits of the DES root and DES Bridge are the
> priorities in HEX
>
>
>
>
>
> STP instance owned by VLAN 501
>
>
>
> Global STP (IEEE 802.1D) Parameters:
>
>
>
> VLAN Root Root Root Prio Max He- Ho- Fwd Last Chg
> Bridge
>
> ID ID Cost Port rity Age llo ld dly Chang cnt
> Address
>
> Hex sec sec sec sec
> sec
>
> 501 61f5000d662f3f40 6 1 ffff 20 2 1 15 133406 770
> 748ef86b37cd
>
>
>
> Port STP Parameters:
>
>
>
> Port Prio Path State Fwd Design Designated Designated
>
>
> Num rity Cost Trans Cost Root Bridge
>
>
> Hex
>
>
> 1 80 2 FORWARDING 3 4 61f5000d662f3f40
> ffff0024387826c0
>
> 2 80 2 BLOCKING 5 6 61f5000d662f3f40
> ffff002438780e80
>
> 5 80 2 FORWARDING 1 6 61f5000d662f3f40
> ffff748ef86b37cd
>
> 6 80 2 FORWARDING 4 6 61f5000d662f3f40
> ffff748ef86b37cd
>
> 11 80 2 BLOCKING 7 6 61f5000d662f3f40
> 8000748ef8f81bc0
>
> 12 80 2 BLOCKING 5 6 61f5000d662f3f40
> 8000748ef8f80e40
>
> 13 80 2 FORWARDING 2 6 61f5000d662f3f40
> ffff748ef86b37cd
>
> 14 80 2 FORWARDING 2 6 61f5000d662f3f40
> ffff748ef86b37cd
>
> 15 80 2 FORWARDING 2 6 61f5000d662f3f40
> ffff748ef86b37cd
>
> 16 80 2 FORWARDING 2 6 61f5000d662f3f40
> ffff748ef86b37cd
>
> 17 80 2 FORWARDING 3 6 61f5000d662f3f40
> ffff748ef86b37cd
>
> 18 80 0 DISABLED 0 0 0000000000000000
> 0000000000000000
>
> 19 80 2 FORWARDING 7 6 61f5000d662f3f40
> ffff748ef86b37cd
>
> 20 80 2 FORWARDING 9 6 61f5000d662f3f40
> ffff748ef86b37cd
>
> 21 80 2 FORWARDING 3 6 61f5000d662f3f40
> ffff748ef86b37cd
>
> 22 80 2 FORWARDING 3 6 61f5000d662f3f40
> ffff748ef86b37cd
>
> 23 80 2 BLOCKING 10 4 61f5000d662f3f40
> ffff0024387826c0
>
> 24 80 2 BLOCKING 10 4 61f5000d662f3f40
> ffff0024387826c0
>
>
>
>
>
>
>
>
>
> *Nick Cutting* | Network Engineer | Architecture & Standards Team|
> Office: 203-742-7856 | Fax: 203-742-7890
>
>
>
> [image: cid:image001.png@01D045E3.7FDE6B40]
>
>
>
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>

Thank you very much

The one concept I am still struggling with is a designated bridge – isn’t this just the local bridge address and the priority added to the beginning ?

Also – this looks like per-vlan spanning tree – as it has an instance for multiple VLans, however it is not pvst+ which is the hybrid of rapid and pvst ?

Am I right in saying that while a port is forwarding t5hat the Designated root column, and the Designated bridge column will always be the same, which is was you meant by redundant information?


Port Prio Path State Fwd Design Designated Designated
Num rity Cost Trans Cost Root Bridge
Hex
1/1/1 80 4 FORWARDING 1 0 61f5000d662f3f40 61f5000d662f3f40
1/1/2 80 0 DISABLED 0 0 0000000000000000 0000000000000000
1/1/3 80 0 DISABLED 0 0 0000000000000000 0000000000000000
1/1/5 80 0 DISABLED 0 0 0000000000000000 0000000000000000
1/1/7 80 0 DISABLED 0 0 0000000000000000 0000000000000000
1/1/9 80 4 FORWARDING 5 4 61f5000d662f3f40 ffff0024387826c0
1/1/11 80 4 FORWARDING 5 4 61f5000d662f3f40 ffff0024387826c0
1/1/13 80 4 FORWARDING 1 4 61f5000d662f3f40 ffff0024387826c0
1/1/15 80 0 DISABLED 0 0 0000000000000000 0000000000000000
1/1/16 80 4 FORWARDING 4 4 61f5000d662f3f40 ffff0024387826c0
1/1/17 80 4 FORWARDING 7 4 61f5000d662f3f40 ffff0024387826c0
1/1/18 80 0 DISABLED 0 0 0000000000000000 0000000000000000
1/1/20 80 0 DISABLED 0 0 0000000000000000 0000000000000000
1/1/21 80 4 FORWARDING 6 4 61f5000d662f3f40 ffff0024387826c0
1/1/22 80 0 DISABLED 0 0 0000000000000000 0000000000000000
1/1/23 80 4 FORWARDING 5 4 61f5000d662f3f40 ffff0024387826c0
1/1/24 80 0 DISABLED 0 0 0000000000000000 0000000000000000
1/1/26 80 0 DISABLED 0 0 0000000000000000 0000000000000000
1/1/27 80 0 DISABLED 0 0 0000000000000000 0000000000000000

Last question what is the difference between the Designated root, and the Root ID?

VLAN Root Root
ID ID Cost

501 61f5000d662f3f40 4

Thank you
From: ekoyle@gmail.com [mailto:ekoyle@gmail.com] On Behalf Of Eldon Koyle
Sent: Monday, May 16, 2016 6:56 PM
To: Nick Cutting
Cc: foundry-nsp@puck.nether.net
Subject: Re: [f-nsp] Spanning tree on brocade

The bridge ID is the bridge priority in hex (default 0xFFFF) followed by the chassis MAC. This is part of the STP specification. The lowest bridge ID is chosen as the root bridge (so the lower the priority value the more likely a device is to become the spanning tree root, and when the priority is equal the lower chassis MAC wins).
"VLAN ID" is the VLAN ID for this STP instance (or, often 4094 for the common STP instance in single spanning tree; look for "L2 VLAN ... are members of single spanning tree" in the output).
"Root ID" is the bridge ID of the global STP root device

"Bridge Address" is the chassis MAC of the device you are connected to (not the Bridge ID)
"Designated Bridge" is the bridge ID of the local root
"Designated Root" is the bridge ID of the global root for this instance


Note that to see rstp info, you need to do 'show 802-1w' which has similar output to 'show span', but drops the redundant "Designated Root" column and adds a "Role" column (which I find a lot easier to understand). STP and RSTP are completely separate on these devices.

You might try looking at the output of 'show span detail' and 'show span 802-1w detail' to see if that clears anything up for you.
Also, the priority is entered in decimal in the config (so you will probably see a line like: 'spanning tree ... priority 25077' for your device with 61f5 in its bridge id).
--
Eldon Koyle

On Mon, May 16, 2016 at 2:58 PM, Nick Cutting <ncutting@edgetg.com<mailto:ncutting@edgetg.com>> wrote:
Hi I am trying to document the spanning tree domain on a brocade environment that has both TurboIron-X24’s and FCX-48G’s

I’m traditionally a cisco guy so need some help in figuring out the show output of show span.

Right now we have a mix of rapid spanning tree and classic, I need help in understand which is the mac address of the root bridge, the root ports and the terminology used in the output.

For example – is the root ID a mac address and the vlan ID added in Hex? What is the designated bridge ? is this is the downstream switches bridge ID?

I can’t seem to match the bridge ID and the Root ID to mac address tables on the switch – is anyone able to shed light on these relationships and describe what each of the terms means below?

I’m guessing the first 4 digits of the DES root and DES Bridge are the priorities in HEX


STP instance owned by VLAN 501

Global STP (IEEE 802.1D) Parameters:

VLAN Root Root Root Prio Max He- Ho- Fwd Last Chg Bridge
ID ID Cost Port rity Age llo ld dly Chang cnt Address
Hex sec sec sec sec sec
501 61f5000d662f3f40 6 1 ffff 20 2 1 15 133406 770 748ef86b37cd

Port STP Parameters:

Port Prio Path State Fwd Design Designated Designated
Num rity Cost Trans Cost Root Bridge
Hex
1 80 2 FORWARDING 3 4 61f5000d662f3f40 ffff0024387826c0
2 80 2 BLOCKING 5 6 61f5000d662f3f40 ffff002438780e80
5 80 2 FORWARDING 1 6 61f5000d662f3f40 ffff748ef86b37cd
6 80 2 FORWARDING 4 6 61f5000d662f3f40 ffff748ef86b37cd
11 80 2 BLOCKING 7 6 61f5000d662f3f40 8000748ef8f81bc0
12 80 2 BLOCKING 5 6 61f5000d662f3f40 8000748ef8f80e40
13 80 2 FORWARDING 2 6 61f5000d662f3f40 ffff748ef86b37cd
14 80 2 FORWARDING 2 6 61f5000d662f3f40 ffff748ef86b37cd
15 80 2 FORWARDING 2 6 61f5000d662f3f40 ffff748ef86b37cd
16 80 2 FORWARDING 2 6 61f5000d662f3f40 ffff748ef86b37cd
17 80 2 FORWARDING 3 6 61f5000d662f3f40 ffff748ef86b37cd
18 80 0 DISABLED 0 0 0000000000000000 0000000000000000
19 80 2 FORWARDING 7 6 61f5000d662f3f40 ffff748ef86b37cd
20 80 2 FORWARDING 9 6 61f5000d662f3f40 ffff748ef86b37cd
21 80 2 FORWARDING 3 6 61f5000d662f3f40 ffff748ef86b37cd
22 80 2 FORWARDING 3 6 61f5000d662f3f40 ffff748ef86b37cd
23 80 2 BLOCKING 10 4 61f5000d662f3f40 ffff0024387826c0
24 80 2 BLOCKING 10 4 61f5000d662f3f40 ffff0024387826c0




Nick Cutting | Network Engineer | Architecture & Standards Team| Office: 203-742-7856<tel:203-742-7856> | Fax: 203-742-7890<tel:203-742-7890>

[cid:image001.png@01D045E3.7FDE6B40]


_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net<mailto:foundry-nsp@puck.nether.net>
http://puck.nether.net/mailman/listinfo/foundry-nsp

________________________________

So is this the root port (cisco terminology) – when the designated bridge is set to the root bridge’s priority+mac?

[cid:image002.png@01D1B01A.92E9D010]

From: ekoyle@gmail.com [mailto:ekoyle@gmail.com] On Behalf Of Eldon Koyle
Sent: Monday, May 16, 2016 6:56 PM
To: Nick Cutting
Cc: foundry-nsp@puck.nether.net
Subject: Re: [f-nsp] Spanning tree on brocade

The bridge ID is the bridge priority in hex (default 0xFFFF) followed by the chassis MAC. This is part of the STP specification. The lowest bridge ID is chosen as the root bridge (so the lower the priority value the more likely a device is to become the spanning tree root, and when the priority is equal the lower chassis MAC wins).
"VLAN ID" is the VLAN ID for this STP instance (or, often 4094 for the common STP instance in single spanning tree; look for "L2 VLAN ... are members of single spanning tree" in the output).
"Root ID" is the bridge ID of the global STP root device

"Bridge Address" is the chassis MAC of the device you are connected to (not the Bridge ID)
"Designated Bridge" is the bridge ID of the local root
"Designated Root" is the bridge ID of the global root for this instance


Note that to see rstp info, you need to do 'show 802-1w' which has similar output to 'show span', but drops the redundant "Designated Root" column and adds a "Role" column (which I find a lot easier to understand). STP and RSTP are completely separate on these devices.

You might try looking at the output of 'show span detail' and 'show span 802-1w detail' to see if that clears anything up for you.
Also, the priority is entered in decimal in the config (so you will probably see a line like: 'spanning tree ... priority 25077' for your device with 61f5 in its bridge id).
--
Eldon Koyle

On Mon, May 16, 2016 at 2:58 PM, Nick Cutting <ncutting@edgetg.com<mailto:ncutting@edgetg.com>> wrote:
Hi I am trying to document the spanning tree domain on a brocade environment that has both TurboIron-X24’s and FCX-48G’s

I’m traditionally a cisco guy so need some help in figuring out the show output of show span.

Right now we have a mix of rapid spanning tree and classic, I need help in understand which is the mac address of the root bridge, the root ports and the terminology used in the output.

For example – is the root ID a mac address and the vlan ID added in Hex? What is the designated bridge ? is this is the downstream switches bridge ID?

I can’t seem to match the bridge ID and the Root ID to mac address tables on the switch – is anyone able to shed light on these relationships and describe what each of the terms means below?

I’m guessing the first 4 digits of the DES root and DES Bridge are the priorities in HEX


STP instance owned by VLAN 501

Global STP (IEEE 802.1D) Parameters:

VLAN Root Root Root Prio Max He- Ho- Fwd Last Chg Bridge
ID ID Cost Port rity Age llo ld dly Chang cnt Address
Hex sec sec sec sec sec
501 61f5000d662f3f40 6 1 ffff 20 2 1 15 133406 770 748ef86b37cd

Port STP Parameters:

Port Prio Path State Fwd Design Designated Designated
Num rity Cost Trans Cost Root Bridge
Hex
1 80 2 FORWARDING 3 4 61f5000d662f3f40 ffff0024387826c0
2 80 2 BLOCKING 5 6 61f5000d662f3f40 ffff002438780e80
5 80 2 FORWARDING 1 6 61f5000d662f3f40 ffff748ef86b37cd
6 80 2 FORWARDING 4 6 61f5000d662f3f40 ffff748ef86b37cd
11 80 2 BLOCKING 7 6 61f5000d662f3f40 8000748ef8f81bc0
12 80 2 BLOCKING 5 6 61f5000d662f3f40 8000748ef8f80e40
13 80 2 FORWARDING 2 6 61f5000d662f3f40 ffff748ef86b37cd
14 80 2 FORWARDING 2 6 61f5000d662f3f40 ffff748ef86b37cd
15 80 2 FORWARDING 2 6 61f5000d662f3f40 ffff748ef86b37cd
16 80 2 FORWARDING 2 6 61f5000d662f3f40 ffff748ef86b37cd
17 80 2 FORWARDING 3 6 61f5000d662f3f40 ffff748ef86b37cd
18 80 0 DISABLED 0 0 0000000000000000 0000000000000000
19 80 2 FORWARDING 7 6 61f5000d662f3f40 ffff748ef86b37cd
20 80 2 FORWARDING 9 6 61f5000d662f3f40 ffff748ef86b37cd
21 80 2 FORWARDING 3 6 61f5000d662f3f40 ffff748ef86b37cd
22 80 2 FORWARDING 3 6 61f5000d662f3f40 ffff748ef86b37cd
23 80 2 BLOCKING 10 4 61f5000d662f3f40 ffff0024387826c0
24 80 2 BLOCKING 10 4 61f5000d662f3f40 ffff0024387826c0




Nick Cutting | Network Engineer | Architecture & Standards Team| Office: 203-742-7856<tel:203-742-7856> | Fax: 203-742-7890<tel:203-742-7890>

[cid:image001.png@01D045E3.7FDE6B40]


_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net<mailto:foundry-nsp@puck.nether.net>
http://puck.nether.net/mailman/listinfo/foundry-nsp

________________________________

Thank you -

Now – should I see a lower cost on a trunk link?

I still see a cost of 4 on a 2x10 trunk port (etherchannel/LAG) – is there somewhere I need to change a reference cost to accommodate for links larger than 10G?

Now I know that Port1 connected to a switch, that connects to the root bridge – How using the detail output can I know that this is true (if I had not traced the cables?)
STP instance owned by VLAN 501

Global STP (IEEE 802.1D) Parameters:

VLAN Root Root Root Prio Max He- Ho- Fwd Last Chg Bridge
ID ID Cost Port rity Age llo ld dly Chang cnt Address
Hex sec sec sec sec sec
501 61f5000d662f3f40 6 1 ffff 20 2 1 15 214685 770 748ef86b37cd

Does this also mean I’m running MST? – this only showed up under the detail section, and I see no config for MST.

#sh span detail vlan 501

======================================================================
VLAN 501 - MULTIPLE SPANNING TREE (MSTP) ACTIVE
======================================================================
Bridge identifier - 0xffff748ef86b37cd
Active global timers - None

Port 1 is FORWARDING
Port - Path cost: 2, Priority: 128, Root: 0x61f5000d662f3f40
Designated - Bridge: 0xffff0024387826c0, Interface: 64, Path cost: 4
Active Timers - Message age: 1
BPDUs - Sent: 579, Received: 215789
Port 2 is BLOCKING
Port - Path cost: 2, Priority: 128, Root: 0x61f5000d662f3f40
Designated - Bridge: 0xffff002438780e80, Interface: 64, Path cost: 6
Active Timers - Message age: 2
BPDUs - Sent: 541, Received: 216134
……
Port 23 is BLOCKING
Port - Path cost: 2, Priority: 128, Root: 0x61f5000d662f3f40
Designated - Bridge: 0xffff0024387826c0, Interface: 66, Path cost: 4
Active Timers - Message age: 1
BPDUs - Sent: 859, Received: 432688
Port 24 is BLOCKING
Port - Path cost: 2, Priority: 128, Root: 0x61f5000d662f3f40
Designated - Bridge: 0xffff0024387826c0, Interface: 66, Path cost: 4
Active Timers - Message age: 1
BPDUs - Sent: 859, Received: 432688

From: ekoyle@gmail.com [mailto:ekoyle@gmail.com] On Behalf Of Eldon Koyle
Sent: Monday, May 16, 2016 6:56 PM
To: Nick Cutting
Cc: foundry-nsp@puck.nether.net
Subject: Re: [f-nsp] Spanning tree on brocade

The bridge ID is the bridge priority in hex (default 0xFFFF) followed by the chassis MAC. This is part of the STP specification. The lowest bridge ID is chosen as the root bridge (so the lower the priority value the more likely a device is to become the spanning tree root, and when the priority is equal the lower chassis MAC wins).
"VLAN ID" is the VLAN ID for this STP instance (or, often 4094 for the common STP instance in single spanning tree; look for "L2 VLAN ... are members of single spanning tree" in the output).
"Root ID" is the bridge ID of the global STP root device

"Bridge Address" is the chassis MAC of the device you are connected to (not the Bridge ID)
"Designated Bridge" is the bridge ID of the local root
"Designated Root" is the bridge ID of the global root for this instance


Note that to see rstp info, you need to do 'show 802-1w' which has similar output to 'show span', but drops the redundant "Designated Root" column and adds a "Role" column (which I find a lot easier to understand). STP and RSTP are completely separate on these devices.

You might try looking at the output of 'show span detail' and 'show span 802-1w detail' to see if that clears anything up for you.
Also, the priority is entered in decimal in the config (so you will probably see a line like: 'spanning tree ... priority 25077' for your device with 61f5 in its bridge id).
--
Eldon Koyle

On Mon, May 16, 2016 at 2:58 PM, Nick Cutting <ncutting@edgetg.com<mailto:ncutting@edgetg.com>> wrote:
Hi I am trying to document the spanning tree domain on a brocade environment that has both TurboIron-X24’s and FCX-48G’s

I’m traditionally a cisco guy so need some help in figuring out the show output of show span.

Right now we have a mix of rapid spanning tree and classic, I need help in understand which is the mac address of the root bridge, the root ports and the terminology used in the output.

For example – is the root ID a mac address and the vlan ID added in Hex? What is the designated bridge ? is this is the downstream switches bridge ID?

I can’t seem to match the bridge ID and the Root ID to mac address tables on the switch – is anyone able to shed light on these relationships and describe what each of the terms means below?

I’m guessing the first 4 digits of the DES root and DES Bridge are the priorities in HEX


STP instance owned by VLAN 501

Global STP (IEEE 802.1D) Parameters:

VLAN Root Root Root Prio Max He- Ho- Fwd Last Chg Bridge
ID ID Cost Port rity Age llo ld dly Chang cnt Address
Hex sec sec sec sec sec
501 61f5000d662f3f40 6 1 ffff 20 2 1 15 133406 770 748ef86b37cd

Port STP Parameters:

Port Prio Path State Fwd Design Designated Designated
Num rity Cost Trans Cost Root Bridge
Hex
1 80 2 FORWARDING 3 4 61f5000d662f3f40 ffff0024387826c0
2 80 2 BLOCKING 5 6 61f5000d662f3f40 ffff002438780e80
5 80 2 FORWARDING 1 6 61f5000d662f3f40 ffff748ef86b37cd
6 80 2 FORWARDING 4 6 61f5000d662f3f40 ffff748ef86b37cd
11 80 2 BLOCKING 7 6 61f5000d662f3f40 8000748ef8f81bc0
12 80 2 BLOCKING 5 6 61f5000d662f3f40 8000748ef8f80e40
13 80 2 FORWARDING 2 6 61f5000d662f3f40 ffff748ef86b37cd
14 80 2 FORWARDING 2 6 61f5000d662f3f40 ffff748ef86b37cd
15 80 2 FORWARDING 2 6 61f5000d662f3f40 ffff748ef86b37cd
16 80 2 FORWARDING 2 6 61f5000d662f3f40 ffff748ef86b37cd
17 80 2 FORWARDING 3 6 61f5000d662f3f40 ffff748ef86b37cd
18 80 0 DISABLED 0 0 0000000000000000 0000000000000000
19 80 2 FORWARDING 7 6 61f5000d662f3f40 ffff748ef86b37cd
20 80 2 FORWARDING 9 6 61f5000d662f3f40 ffff748ef86b37cd
21 80 2 FORWARDING 3 6 61f5000d662f3f40 ffff748ef86b37cd
22 80 2 FORWARDING 3 6 61f5000d662f3f40 ffff748ef86b37cd
23 80 2 BLOCKING 10 4 61f5000d662f3f40 ffff0024387826c0
24 80 2 BLOCKING 10 4 61f5000d662f3f40 ffff0024387826c0




Nick Cutting | Network Engineer | Architecture & Standards Team| Office: 203-742-7856<tel:203-742-7856> | Fax: 203-742-7890<tel:203-742-7890>

[cid:image001.png@01D045E3.7FDE6B40]


_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net<mailto:foundry-nsp@puck.nether.net>
http://puck.nether.net/mailman/listinfo/foundry-nsp

________________________________

Now I have another switch – that has no IEEE spanning tree, No 802w, and no pvst configured.

however, it says it is enabled on the port??

10GigabitEthernet23 is up, line protocol is up
Hardware is 10GigabitEthernet, address is 748e.f821.57d3 (bia 748e.f821.57e9)
Configured speed 10Gbit, actual 10Gbit, configured duplex fdx, actual fdx
Member of L2 VLAN ID 501, port is untagged, port state is FORWARDING
BPDU guard is Disabled, ROOT protect is Disabled
Link Error Dampening is Disabled
STP configured to ON, priority is level0

Now – the loops prevention is on the otherside – and they are receiving BPDU’s on this switch – how can this be possible with no stp config?

Can someone please elaborate on the port level spanning tree?

Thanks !

I think I have found my answer – as this switch is not participating in spanning tree – I believe that :

STP configured to ON, priority is level0

Is forwarding the BPDU’s unmodified.

Would I be correct in this assumption? I see the correct Bridge ID’s as if this switch is not there.

From: Nick Cutting
Sent: Tuesday, May 17, 2016 3:26 PM
To: Nick Cutting; Eldon Koyle
Cc: foundry-nsp@puck.nether.net
Subject: RE: [f-nsp] Spanning tree on brocade

Now I have another switch – that has no IEEE spanning tree, No 802w, and no pvst configured.

however, it says it is enabled on the port??

10GigabitEthernet23 is up, line protocol is up
Hardware is 10GigabitEthernet, address is 748e.f821.57d3 (bia 748e.f821.57e9)
Configured speed 10Gbit, actual 10Gbit, configured duplex fdx, actual fdx
Member of L2 VLAN ID 501, port is untagged, port state is FORWARDING
BPDU guard is Disabled, ROOT protect is Disabled
Link Error Dampening is Disabled
STP configured to ON, priority is level0

Now – the loops prevention is on the otherside – and they are receiving BPDU’s on this switch – how can this be possible with no stp config?

Can someone please elaborate on the port level spanning tree?

Thanks !

So neither "show span" nor "show 802-1w" shows spanning tree running? Is
this turboiron running routing code or switch code? IIRC, the default is
single spanning tree on switch code and no spanning tree on routing code.

--
Eldon Koyle
On May 17, 2016 2:12 PM, "Nick Cutting" <ncutting@edgetg.com> wrote:

> I think I have found my answer – as this switch is not participating in
> spanning tree – I believe that :
>
>
>
> STP configured to ON, priority is level0
>
>
>
> Is forwarding the BPDU’s unmodified.
>
>
>
> Would I be correct in this assumption? I see the correct Bridge ID’s as if
> this switch is not there.
>
>
>
> *From:* Nick Cutting
> *Sent:* Tuesday, May 17, 2016 3:26 PM
> *To:* Nick Cutting; Eldon Koyle
> *Cc:* foundry-nsp@puck.nether.net
> *Subject:* RE: [f-nsp] Spanning tree on brocade
>
>
>
> Now I have another switch – that has no IEEE spanning tree, No 802w, and
> no pvst configured.
>
>
>
> however, it says it is enabled on the port??
>
>
>
> 10GigabitEthernet23 is up, line protocol is up
>
> Hardware is 10GigabitEthernet, address is 748e.f821.57d3 (bia
> 748e.f821.57e9)
>
> Configured speed 10Gbit, actual 10Gbit, configured duplex fdx, actual fdx
>
> Member of L2 VLAN ID 501, port is untagged, port state is FORWARDING
>
> BPDU guard is Disabled, ROOT protect is Disabled
>
> Link Error Dampening is Disabled
>
> * STP configured to ON, priority is level0*
>
>
>
> Now – the loops prevention is on the otherside – and they are receiving
> BPDU’s on this switch – how can this be possible with no stp config?
>
>
>
> Can someone please elaborate on the port level spanning tree?
>
>
>
> Thanks !
>
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>

I think its routing code:

Remote switches using FDP show it as a router and I have:

telnet@Turbo4 (config)#router ?
bgp Enable bgp
msdp Enable msdp
ospf Enable ospf
pim Enable pim
rip Enable rip
vrrp Enable vrrp
vrrp-extended Enable vrrp-extended
vsrp Enable vsrp

sh ver
SW: Version 04.2.00c Copyright (c) 1996-2010 Brocade Communications Systems, Inc.
Compiled on Jan 12 2011 at 19:46:00 labeled as TIR04200c
(5473051 bytes) from Primary TIR04200c.bin
Compressed Boot-Monitor Image size = 373767, Version:04.1.00T205 (grz04100)


As you all can probably guess – we had a bit of a spanning tree meltdown. I am trying to figure out what happened.
I get plenty of incorrect costs, and it is stable now and am trying to figure out what happened, what may have caused this.

I know we need to enable 802-1w everywhere and move the root bridges, but right now I’m in the audit phase and am trying to understand what happened.
The port-level spanning tree – when not running any form of spanning tree – does this forward unmodified BPDUs (i.e a cost of 0 as stated)

“STP configured to ON, priority is level0”

I cannot find what this does in any brocade documentation .

Also – any Ideas why a trunk does not lower the cost of the link? Or get treated as an aggregated link by STP?



From: ekoyle@gmail.com [mailto:ekoyle@gmail.com] On Behalf Of Eldon Koyle
Sent: Wednesday, May 18, 2016 2:03 AM
To: Nick Cutting
Cc: foundry-nsp
Subject: Re: [f-nsp] Spanning tree on brocade


So neither "show span" nor "show 802-1w" shows spanning tree running? Is this turboiron running routing code or switch code? IIRC, the default is single spanning tree on switch code and no spanning tree on routing code.

--
Eldon Koyle
On May 17, 2016 2:12 PM, "Nick Cutting" <ncutting@edgetg.com<mailto:ncutting@edgetg.com>> wrote:
I think I have found my answer – as this switch is not participating in spanning tree – I believe that :

STP configured to ON, priority is level0

Is forwarding the BPDU’s unmodified.

Would I be correct in this assumption? I see the correct Bridge ID’s as if this switch is not there.

From: Nick Cutting
Sent: Tuesday, May 17, 2016 3:26 PM
To: Nick Cutting; Eldon Koyle
Cc: foundry-nsp@puck.nether.net<mailto:foundry-nsp@puck.nether.net>
Subject: RE: [f-nsp] Spanning tree on brocade

Now I have another switch – that has no IEEE spanning tree, No 802w, and no pvst configured.

however, it says it is enabled on the port??

10GigabitEthernet23 is up, line protocol is up
Hardware is 10GigabitEthernet, address is 748e.f821.57d3 (bia 748e.f821.57e9)
Configured speed 10Gbit, actual 10Gbit, configured duplex fdx, actual fdx
Member of L2 VLAN ID 501, port is untagged, port state is FORWARDING
BPDU guard is Disabled, ROOT protect is Disabled
Link Error Dampening is Disabled
STP configured to ON, priority is level0

Now – the loops prevention is on the otherside – and they are receiving BPDU’s on this switch – how can this be possible with no stp config?

Can someone please elaborate on the port level spanning tree?

Thanks !

_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net<mailto:foundry-nsp@puck.nether.net>
http://puck.nether.net/mailman/listinfo/foundry-nsp
________________________________

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?

--
Eldon
On May 18, 2016 6:48 AM, "Nick Cutting" <ncutting@edgetg.com> wrote:

> I think its routing code:
>
>
>
> Remote switches using FDP show it as a router and I have:
>
>
>
> telnet@Turbo4 (config)#router ?
>
> bgp Enable bgp
>
> msdp Enable msdp
>
> ospf Enable ospf
>
> pim Enable pim
>
> rip Enable rip
>
> vrrp Enable vrrp
>
> vrrp-extended Enable vrrp-extended
>
> vsrp Enable vsrp
>
>
>
> sh ver
>
> SW: Version 04.2.00c Copyright (c) 1996-2010 Brocade Communications
> Systems, Inc.
>
> Compiled on Jan 12 2011 at 19:46:00 labeled as TIR04200c
>
> (5473051 bytes) from Primary TIR04200c.bin
>
> Compressed Boot-Monitor Image size = 373767, Version:04.1.00T205
> (grz04100)
>
>
>
>
>
> As you all can probably guess – we had a bit of a spanning tree meltdown.
> I am trying to figure out what happened.
>
> I get plenty of incorrect costs, and it is stable now and am trying to
> figure out what happened, what may have caused this.
>
>
>
> I know we need to enable 802-1w everywhere and move the root bridges, but
> right now I’m in the audit phase and am trying to understand what happened.
>
> The port-level spanning tree – when not running any form of spanning tree
> – does this forward unmodified BPDUs (i.e a cost of 0 as stated)
>
>
>
> “STP configured to ON, priority is level0”
>
>
>
> I cannot find what this does in any brocade documentation .
>
>
>
> Also – any Ideas why a trunk does not lower the cost of the link? Or get
> treated as an aggregated link by STP?
>
>
>
>
>
>
>
> *From:* ekoyle@gmail.com [mailto:ekoyle@gmail.com] *On Behalf Of *Eldon
> Koyle
> *Sent:* Wednesday, May 18, 2016 2:03 AM
> *To:* Nick Cutting
> *Cc:* foundry-nsp
> *Subject:* Re: [f-nsp] Spanning tree on brocade
>
>
>
> So neither "show span" nor "show 802-1w" shows spanning tree running? Is
> this turboiron running routing code or switch code? IIRC, the default is
> single spanning tree on switch code and no spanning tree on routing code.
>
> --
> Eldon Koyle
>
> On May 17, 2016 2:12 PM, "Nick Cutting" <ncutting@edgetg.com> wrote:
>
> I think I have found my answer – as this switch is not participating in
> spanning tree – I believe that :
>
>
>
> STP configured to ON, priority is level0
>
>
>
> Is forwarding the BPDU’s unmodified.
>
>
>
> Would I be correct in this assumption? I see the correct Bridge ID’s as if
> this switch is not there.
>
>
>
> *From:* Nick Cutting
> *Sent:* Tuesday, May 17, 2016 3:26 PM
> *To:* Nick Cutting; Eldon Koyle
> *Cc:* foundry-nsp@puck.nether.net
> *Subject:* RE: [f-nsp] Spanning tree on brocade
>
>
>
> Now I have another switch – that has no IEEE spanning tree, No 802w, and
> no pvst configured.
>
>
>
> however, it says it is enabled on the port??
>
>
>
> 10GigabitEthernet23 is up, line protocol is up
>
> Hardware is 10GigabitEthernet, address is 748e.f821.57d3 (bia
> 748e.f821.57e9)
>
> Configured speed 10Gbit, actual 10Gbit, configured duplex fdx, actual fdx
>
> Member of L2 VLAN ID 501, port is untagged, port state is FORWARDING
>
> BPDU guard is Disabled, ROOT protect is Disabled
>
> Link Error Dampening is Disabled
>
> * STP configured to ON, priority is level0*
>
>
>
> Now – the loops prevention is on the otherside – and they are receiving
> BPDU’s on this switch – how can this be possible with no stp config?
>
>
>
> Can someone please elaborate on the port level spanning tree?
>
>
>
> Thanks !
>
>
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>
>

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
_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp

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@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

________________________________

Nick Cutting wrote:
> No routing at all

the switching image might be a better option then.

> 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?

802.1w works well. If you have lots of vlans, you might want to run
MSTP instead - it scales better.

Nick

_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp

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@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.
_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp

You can run 802-1w either as a single instance or per-vlan.

Since all of our VLANs go the same way, we use 'spanning-tree single
802-1w' (which changes the single spanning tree instance to rstp) to
save some CPU. Then just make sure that 'spanning-tree' is enabled in
each VLAN, which will make them a member of the single spanning tree
instance. We also configure all of our edge ports with
"stp-bpdu-guard" and "spanning-tree 802-1w admin-edge-port", as Jethro
suggested.

How big of a meltdown was it? We have seen that deleting a VLAN can
cause brocade switches to move every port to blocking and restart the
entire STP process (this may only be with single spanning tree).
Also, loops can do unexpected things with single spanning tree since
not every port has every VLAN (another argument for 802-1w and setting
admin-edge-port anywhere you can).

--
Eldon

On Wed, May 18, 2016 at 8:37 AM, Nick Cutting <ncutting@edgetg.com> 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@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
>
_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp

It was a 4 hour layer2 loop.

I would rather per-vlan rapid everywhere – and this is general plan going forward.

One switch had no spanning tree at all – this is definitely the culprit (I will not find the trigger)

I’m going to add syslog to all devices to our syslog-ng server
Do I need to run a command to make sure spanning tree events are sent to the syslog?

Thank you all Brocade experts )


From: ekoyle@gmail.com [mailto:ekoyle@gmail.com] On Behalf Of Eldon Koyle
Sent: Wednesday, May 18, 2016 12:10 PM
To: Nick Cutting
Cc: foundry-nsp
Subject: Re: [f-nsp] Spanning tree on brocade

You can run 802-1w either as a single instance or per-vlan.

Since all of our VLANs go the same way, we use 'spanning-tree single
802-1w' (which changes the single spanning tree instance to rstp) to
save some CPU. Then just make sure that 'spanning-tree' is enabled in
each VLAN, which will make them a member of the single spanning tree
instance. We also configure all of our edge ports with
"stp-bpdu-guard" and "spanning-tree 802-1w admin-edge-port", as Jethro
suggested.

How big of a meltdown was it? We have seen that deleting a VLAN can
cause brocade switches to move every port to blocking and restart the
entire STP process (this may only be with single spanning tree).
Also, loops can do unexpected things with single spanning tree since
not every port has every VLAN (another argument for 802-1w and setting
admin-edge-port anywhere you can).

--
Eldon

On Wed, May 18, 2016 at 8:37 AM, Nick Cutting <ncutting@edgetg.com><mailto:ncutting@edgetg.com%3e> 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@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
>

________________________________

All of your tips and best practices, none of which exist at present - will be going into a maintenance window.

Does anyone have any experience with Broadcast storm control?

I see for iSCSI it is supposed to be turned off according to the "best practice FCX for iSCSI"

Rate Limiting
iSCSI traffic can generate bursts of heavy traffic that can be mistaken as traffic storms. The Brocade FCX provides ability to limit these storms on the switch, but in dedicated iSCSI SANs, as being configured through this document, this feature should not be enabled. By default, this feature is disabled which is why there is no need to enter any additional commands.

Syntax: [no] broadcast limit <num>
Syntax: [no] multicast limit
Syntax: [no] unknown
-unicast limit

However this same "best practice FCX for iSCSI" document recommends disabling spanning tree on host facing ports...which I do not want to do, happy with portfast instead.

http://community.brocade.com/dtscp75322/attachments/dtscp75322/ethernetswitches/2538/1/BrocadeFCX_iSCSI_SAN_ConfigGuide_GA-CG-285-00.pdf



-----Original Message-----
From: foundry-nsp [mailto:foundry-nsp-bounces@puck.nether.net] On Behalf Of Jethro R Binks
Sent: Wednesday, May 18, 2016 11:11 AM
To: foundry-nsp
Subject: Re: [f-nsp] Spanning tree on brocade

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@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.
_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp

_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp

We have the broadcast/multicast/unknown unicast limit configured on all of
our campus edge ports (IIRC, we set it to the minimum). The documentation
and the switch disagreed about the units (pps vs kbps, at least with the
last code version I checked), and I haven't actually tested to see that it
acts as expected; but I haven't noticed any problems because of it, either.

--
Eldon
On May 24, 2016 3:16 PM, "Nick Cutting" <ncutting@edgetg.com> wrote:

> All of your tips and best practices, none of which exist at present -
> will be going into a maintenance window.
>
> Does anyone have any experience with Broadcast storm control?
>
> I see for iSCSI it is supposed to be turned off according to the "best
> practice FCX for iSCSI"
>
> Rate Limiting
> iSCSI traffic can generate bursts of heavy traffic that can be mistaken as
> traffic storms. The Brocade FCX provides ability to limit these storms on
> the switch, but in dedicated iSCSI SANs, as being configured through this
> document, this feature should not be enabled. By default, this feature is
> disabled which is why there is no need to enter any additional commands.
>
> Syntax: [no] broadcast limit <num>
> Syntax: [no] multicast limit
> Syntax: [no] unknown
> -unicast limit
>
> However this same "best practice FCX for iSCSI" document recommends
> disabling spanning tree on host facing ports...which I do not want to do,
> happy with portfast instead.
>
>
> http://community.brocade.com/dtscp75322/attachments/dtscp75322/ethernetswitches/2538/1/BrocadeFCX_iSCSI_SAN_ConfigGuide_GA-CG-285-00.pdf
>
>
>
> -----Original Message-----
> From: foundry-nsp [mailto:foundry-nsp-bounces@puck.nether.net] On Behalf
> Of Jethro R Binks
> Sent: Wednesday, May 18, 2016 11:11 AM
> To: foundry-nsp
> Subject: Re: [f-nsp] Spanning tree on brocade
>
> 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@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.
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>