Switches, Hubs, and Modems
cancel
Showing results for 
Search instead for 
Did you mean: 

BPDU question

SOLVED
Go to solution
Stuart Teo
Trusted Contributor

BPDU question

SwitchA---SwitchB---SwitchC

3 switches are connected as above. SwitchA & SwitchC has STP turned ON. SwitchB has STP turned OFF. Will SwitchA & SwitchC see each other's BPDUs?
If a problem can be fixed, there's nothing to worry. If a problem can't be fixed, worrying ain't gonna help. Bottom line: don't worry.
10 REPLIES
Ralph Bean_2
Trusted Contributor

Re: BPDU question

Hello Hwee Liang -

The answer depends upon the manufacturer and model of Switch and, sometimes, the firmware version.

In general, I recommend not having STP disabled on switches that are between other switches that have STP enabled.

If you have a compelling reason to disable STP on an intermediate switch in the way you describe, you can test the intermediate switch as follows. Either remove these three switches from your LAN or choose a "down" time when you can afford to have your LAN not working. Configure STP as you have described, with STP disabled in the middle switch. Disconnect these three switches from the rest of your LAN. Make sure that the only connection between the two STP switches is the non-STP switch. Do "show span" on the two switches that have STP enabled and see whether one of them lists the other as root bridge. If so, then the middle switch is forwarding the BPDUs. If the middle switch is not forwarding the BPDUs, then both will be Root.

Regards,
Ralph
Stuart Teo
Trusted Contributor

Re: BPDU question

I tested with 3 Procurve 4000m and they passed the BPDUs along. That's why I posted the question. Doesn't the standard say something about this? If it should or should not be passed?
If a problem can be fixed, there's nothing to worry. If a problem can't be fixed, worrying ain't gonna help. Bottom line: don't worry.
Ralph Bean_2
Trusted Contributor

Re: BPDU question

Hello Hwee Liang -

I am not highly familiar with the STP specs (802.1d, 802.1w, 802.1s), but those who are have told me that the specs assume that STP is always turned on.

Regards,
Ralph
OLARU Dan
Trusted Contributor

Re: BPDU question

IEEE 802.1D does not require that all bridges / switches in the LAN run STP. So non-STP switches will be transparent to BPDUs.

The problem with STP is that all network printers using powersave feature will be sluggish unless you change their port from "Norm" to "Fast" in STP configuration. With many printers (that may move around) maintaining this can be a hassle. The same problem can be seen in NetWare clients with "Norm" ports.

What I did was to periodically run STP for 2-3 hours after workhours, eliminate possible loops and then suspend STP.
Kevin Richter_1
Valued Contributor
Solution

Re: BPDU question

STP BPDUs are sent to a reserved multicast address (01-00-5E-80-00-00). Legacy bridges which do not support 802.1D STP will forward these multicast packets to all active interfaces (other than the port on which it was received.) This is also the expected behavior of an 802.1D capable bridge with STP disabled.

Therefore, with SwitchB running with STP off, A and C should see each other's BPDUs - which matches your observed behavior with the HP Procurve 4000M switch.

IEEE specs being typically inscrutable, I would recommend Annex F (labeled as informative) of the 802.1D document (1998 Edition). This may seem "outdated," but the relevant sections on forwarding of PDUs (including STP BPDUs) has not been significantly altered in the 802.1w or 802.1s revisions (2001 and 2002, respectively). The references here speak of filtering. If a bridge does not have a reason to filter (drop, discard or choose not to forward) the packet, then it will be forwarded.

OLARU Dan's comment correctly references another of the exact terms stated in Annex F: the non STP switches (and Legacy bridges) will be "transparent" to the BPDUs. His comments regarding "Norm" or normal versus "Fast" mode STP are useful in deploying and troubleshooting an STP implementation but not directly relevant to the BPDU question.
Check the cabling. Next, check the cabling again.
Stuart Teo
Trusted Contributor

Re: BPDU question

Hi Kevin,

Thanks for the answer. It's great to know that you're reading the forums.
If a problem can be fixed, there's nothing to worry. If a problem can't be fixed, worrying ain't gonna help. Bottom line: don't worry.
Stuart Teo
Trusted Contributor

Re: BPDU question

Reviving an old thread. I have the below setup:



5308 e.8.42 RSTP
|
|(vlan2)
|
4000 c.9.16 STP-off
|
|(vlan3)
|
5308 e.8.07 RSTP


It's interesting to note that both the 5308 think that they are root, suggesting that the 4000 isn't passing BPDUs. the VLAN shouldn't matter since the BPDU multicast frames would breach that partitioning, wouldn't it?
If a problem can be fixed, there's nothing to worry. If a problem can't be fixed, worrying ain't gonna help. Bottom line: don't worry.
OLARU Dan
Trusted Contributor

Re: BPDU question

Maybe 5300XLs run per-VLAN spanning tree by default. There should be some commands to make VLANs transparent to BPDUs.
Stuart Teo
Trusted Contributor

Re: BPDU question

Nope, the 5308s are not running MSTP. I'm sure of that.
If a problem can be fixed, there's nothing to worry. If a problem can't be fixed, worrying ain't gonna help. Bottom line: don't worry.
Kevin Richter_1
Valued Contributor

Re: BPDU question

5308 e.8.42 RSTP
|
|(vlan2)
|
4000 c.9.16 STP-off
|
|(vlan3)
|
5308 e.8.07 RSTP

RSTP BPDU's are multicasts. Since the 4000M has STP off, multicasts (as with broadcasts and all other traffic) will stay within the vlan. Traffic in vlan2 will not be heard in vlan3. The 5300's do not hear each other and therefore each sets itself as root.

If the links between the 5300's and 4000 each contained vlan2 AND vlan3, the 5300's would hear each other and negotiate for root.

If STP was enabled on the 4000M without changing the vlans on the links, it would communicate STP root information to all vlans since these switches use single instance STP. A root election would result in one of the 3 switches becoming root.
Check the cabling. Next, check the cabling again.