What does a switch do with BPDUs when spanning tree is disabled?

[ame-it]

What does a switch do with BPDUs when spanning tree is disabled?

In an example with three bridges in a triange, if one has spanning tree disabled the other two do not see each other and therefore there is a loop.

does the switch act similar to a hub and broadcast the traffic?

regards

[Cliff Alligood]

BPDUs are not propagated beyond the LAN on which they originate, i.e. switches do not flood BPDUs. Your scenario highlights the importance of always running STP, if only for insurance.

See:

http://standards.ieee.org/getieee802/download/802.1D-1998.pdf

Section 8.3.2 for more info.

[milan.kulik]

Hi,

the IEEE documents supposes STP running on the switch.

But if there is no STP running the switch shouldn't recognize the special BPDU destination multicast address and handle the BPDU the same way as any other multicast (IMHO).

I haven't tested the behaviour but it should be easy to do - just connect two switches with VLAN1 only configured together, turn off STP for VLAN1 on one of them and connect a sniffer to any access port on the switch where no STP is running. You should be able to capture a BPDU is it is forwarded.

Regards,

Milan

[ipotts]

Hello,

I recently had a case with a Foundry XL where spanning tree was disabled, but it did not allow the BPDUs between two Ciscos to pass. I believe this was because switches have system MACs defined, and any traffic to these MACs is sent to the switch processor and are not forwarded. In Foundry's case it appears that disabling spanning tree does not remove this system MAC cam entry.

[milan.kulik]

Hi,

what about following trick:

Configure a 802.1q nonegotiate trunk on a line connecting your Cisco to the Foundry XL. Configure VLAN1 as native and the only allowed on the trunk.

The result will be that your Cisco will send untagged frames on the line (only native VLAN allowed), but each BPDU will be doubled - one sent to IEEE multicast address 01-80-c2-00-00-00, second to Cisco proprietary multicast address 01-00-0c-cc-cc-cd. Foundry switch might not know this Cisco address and forward the BPDU.

Regards,

Milan

[ame-it]

Yesterday we tested the concept in the lab with 3 cisco switches in a triangle. Turned spanning tree off on one of the none root switches switch_B. The sniffer showed BPDUs from the root MAC inbound to swtich_B on gi0/1 as expected but also BPDUs sourced from the switch_Bs MAC outbound on gi0/2.

Does this mean its passing the multicast address and re-writting the source MAC?

thanks for the info on Foundry.

[ipotts]

I saw this behaviour with a Supervisor 3 on a cat4K about a year ago, but I couldn't get a reasonable explanation for it.

For the Foundry XL we were running a trunk but there were multiple VLANs on it, and VLAN 1 was not the native VLAN, however the Cisco still sent vlan1 as a native 802.1D BPDU, and not as PVST. Thank you for the advice, but I am not able to make a change in this environment at this stage.

[milan.kulik]

Well, to the Foundry: I thought there had been no trunk between your Cisco and Foundry switches.

In the case of trunk connection:

The Network Supported Accounts - Best Practices (Cisco internal document) says:

"PVST+ interoperates with 802.1Q Mono Spanning Tree via the so-called Common Spanning Tree (CST) over an 802.1Q trunk. The CST is on always VLAN1 hence this VLAN needs to be enabled on the trunk to interoperate with other vendors (or recent Cisco acquisitions such as the CSS 11000). CST BPDUs are transmitted, always untagged, to the IEEE Standard Bridge-Group, (MAC Address 01-80-c2-00-00-00, DSAP 42, SSAP 42). For completeness of description, a parallel set of BPDUs are also transmitted the Cisco Shared Spanning Tree MAC address for VLAN1.

PVST+ tunnels PVST BPDUs across 802.1Q VLAN regions as multicast data. Cisco's Shared Spanning Tree BPDUs are transmitted with MAC address 01-00-0c-cc-cc-cd, (SNAP HDLC protocol type 0x010b), for each VLAN on a trunk. On the native VLAN BPDUs are untagged and for all other VLANs BPDUs are tagged."

So the Foundry switch should forward the Cisco PVST+ BPDUs (dest. address 01-00-0c-cc-cc-cd) tagged for each VLAN.

Regards,

Milan

[ipotts]

Hello,

The problem was on VLAN 1 only. The versions on the 6500s were 6.1.1d and 5.4.4. Perhaps the 5.4.4 is too old to have the dual BPDUs sent on vlan 1,

Thanks for your detailed response.

[milan.kulik]

Hi,

read bug CSCdz12481 description.

Regards,

Milan

[milan.kulik]

Read bug CSCdt84819 description.

It implies that switch is expected to pass the BPDUs when STP disabled on it.

Regards,

Milan