3

In the STP Bridge ID (BID), the original, two-byte priority field was split into a four-bit configurable priority and twelve-bit System ID Extension (SIE) to represent the VLAN. Therefore, the priority is effectively configured priority + VLAN ID.
E.g. in Cisco IOS with default settings, those will be 32768 and 1, respectively, and the priority will display as 32769.

So it seems the split is effectively just a reduction in the priority bits, plus a handy place to stash the VLAN ID.
But in some sense, the SIE affects the real priority value. So is there any situation in which it actually has to be taken into account, in root bridge elections, designated port tiebreakers, etc.?

It seems like it wouldn't in PVST, because any comparison will be within the same VLAN, so the SIE will always be the same. But what about in MST or other variations of the standard? Will there ever be a BID comparison in which the SIE makes a difference?

Improve this question

2 Answers 2

Reset to default
6

Benjamin Dales answer is certainly correct for switches running standards based spanning tree. For switches using per VLAN STP however: yes, it can very well make a difference. Granted, under rather specific circumstances.

As you said, the bridge-id is basically made up of three parts: (priority + system id extension).mac-address, where the MAC address is just appended. The lowest bridge IDs wins the root bridge election. That being said, it is obvious that the priority must be the same on all routers in order for the extended system ID to actually make a difference.

Suppose a network just consisting of two switches. SW1 has a MAC address of 1 (just going to short that up here, suppose those were actually 48bit MAC addresses), SW2 has the MAC address 2. Both use the default priority (32768).

When running only PVSTP (no matter if rapid or not), the VLAN ID of that instance is used as extended system ID. In that case (for the sake of that example we're running in VLAN 1), the bridge IDs would be

SW1: 32769.1   (32768 + 1).MAC
SW2: 32769.2   (32768 + 1).MAC

Obviously SW1 will become root. Suppose now, SW2 was changed to MST mode and SW1 is still running RSTP. MSTP is fully backwards compatible to other spanning tree protocols. With MSTP, the extended system is becomes the MST instance number, as it would make no sense to use the VLAN here. Many VLANs can be mapped to a single instance. Just enabling MSTP without any configuration will create the MST instance 0 (!) and map all VLANs to it. Now the bridge IDs would look as follows:

SW1: 32769.1   (32768 + 1).MAC
SW2: 32768.2   (32768 + 0).MAC

Now, SW2 will be the winner of the election process, and it wins due to the lower extended system id. Hence the answer to your question is: yes, it could possibly affect root bridge election. The lowest possible VLAN number is 1, and the default MST instance is 0, resulting in the MST switch always winning root election with default settings. Also please have a look at Benjamins comment about spanning interoperability. I am currently not sure about the behavior (on BPDU sending level) when MSTP and PVSTP+ have to work together. I will add detailed information later, I have to try that in lab and inspect the BPDUs.

If you think about that for a minute, that makes perfect sense. MST + RPVSTP interoperability requires the root bridge to be within the MST domain. Sure you can manually tweak the priority, in which case you messed that up yourself. By default however, the switch in the MST domain will be selected as root bridge.

TL;DR and Summary:

If all switches are running (R)PVSTP or all switches are running MSTP, then no, it will not affect root bridge election. In a mixed environment, it certainly can.

One note, though: this discussion is certainly true for Cisco switches (more general, switches supporting per VLAN spanning tree), but not necessarily for other switches.

Improve this answer
3
  • Wow, that's a hell of a corner case - well spotted! ; ) Minor nit-pick though - I'm pretty certain that the IEEE BPDUs that get sent out of a switch running PVST+ will always use the System Extension of 1 regardless of the native VLAN on the port.
    – Benjamin Dale
    Commented Oct 25, 2016 at 5:25
  • My apologies - I have accidentally down-voted your answer, which was not my intention, and due to the amount of time that has passed, I cannot change my vote unless you edit the question. Can you just do a simple formatting edit and I will re-cast my vote?
    – Benjamin Dale
    Commented Oct 25, 2016 at 6:06
  • @BenjaminDale: Yes, it is a funny corner case we actually ran into. As of the interoperability I am honestly not sure about how the system extension is set. I have to try that in my lab and inspect the BPDUs. However, I edited the question and rephrased some sentences. The first one might have been a little offending, that was not my intention. Edited it now anyway :)
    – Daniel
    Commented Oct 27, 2016 at 2:16
3

In short, No - in MSTP, RSTP and STP the bridge priority is fixed to the configured value (e.g.: no additional VLAN-ID is added).

This is primarily because none of the IEEE-based standards acknowledge VLANs - all BPDUs are sent untagged - in the case of MSTP, MSTIs are linked to common VLAN groups, but are not influenced by the configuration of VLANs on underlying interfaces.

As you have surmised - in PVST, the VLAN-ID should be identical between nodes, so the priority will always be weighted towards the lowest configured bridge priority.

Improve this answer
1
  • 1
    At least for Cisco switches in rather specific circumstances, it very well can affect root bridge election. See my other answer below. Granted, that it will not affect election with standards based spanning tree, though. As the question was "ever affect" and he explicitly mentioned Cisco IOS, I felt I had to put my answer below.
    – Daniel
    Commented Oct 23, 2016 at 3:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.