Spanning Tree – Does the System ID Extension Affect Root Bridge Election?

spanning tree

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?

Best Answer

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.

Related Solutions

STP Root Bridge Election – How is the Root Bridge Elected?

Not sure how much you know about switching and spanning tree but basically when starting out all switches claim that they are the root. All switches send BPDUs (Bridge Protocol Data Unit) which contain a priority and the BID (Bridge ID).

The BID is 8 bytes long. 6 bytes is used for the MAC address of the bridge. 12 bits is used to indicate the VLAN, this is called extended system ID. 4 bits are used to set the priority. Lower priority means it is preferred compared to a higher. The priority is set in multiples of 4096.

If there is a tie in priority then the lowest MAC address will determine which bridge becomes the root.

To select the path to the root the cost to the root is calculated. As the BPDU travels from the root downstream the cost is increased INBOUND. 802.1D-1998 (legacy STP) had a cost of 19 for a FastEthernet interface. The newer standard 802.1D-2004 defines a cost of 200000 for FastEthernet.

If there is a tie in cost then choose the BPDU that came from the switch with lowest BID. If that is a tie as well (multiple links to same switch) port ID comes into play. The port ID is from the upstream switch as well and consists of a port priority and port ID which identifies the interface. The default port priority is 128.

There is a lot to spanning tree but these are the basic steps.

How long does it take to Elect a Root Bridge in STP

I don't think it's possible to give a definitive answer on this because it will depend on the switch architecture, CPU power, the distance between the switches, the topology, the speed of the links and so on. I assume the delay would be something like this if we have three switches daisy chained:

+----------+           +----------+           +----------+
|          |           |          |           |          |
|   SW1    +-----------+  SW2     +-----------+  SW3     |
|          |           |          |           |          |
+----------+           +----------+           +----------+

Assume that SW1 has the best BID so that it should be elected root. Also assume that all switches have just been booted up, the way STP works all will claim to be root until they have heard a better BPDU. All links are Gigabit.

STP process runs and generates BPDU
BPDU must be serialized on to the link (serialization delay)
BPDU must be propagated between switches (propagation delay)
Act on BPDU received, change port roles
Send out BPDU on designated ports

All in all it should be in the millisecond range. It will be variable based on the speed and distance of links between switches and how fast they can process BPDUs. STP is fast to act on things where links go down, the issue is if you have unidirectional links or "passive" failures like a converter that won't give link down.

Best Answer

Related Solutions

STP Root Bridge Election – How is the Root Bridge Elected?

How long does it take to Elect a Root Bridge in STP

Related Topic