skip to content

Why can a spanning-tree bridge priority be set only in multiples of 4,096, and what do the low 12 bits of the field carry?

level: middleimportance: should knowfreq 24%

answer

  1. two octets, split unevenly
  2. four bits you can set
  3. twelve bits name the tree
  4. why 32,769 shows up

basics

~20 s

Since IEEE 802.1t, the 16-bit priority field is split: only its top 4 bits are configurable, so priority moves in steps of 4,096, and the low 12 bits form a system ID extension carrying the VLAN or instance number.

solid answer

~50 s

The bridge ID begins with a 16-bit priority field. The original 802.1D allowed any value from 0 to 65,535, which is still the base range in RFC 4188. IEEE 802.1t reserved the low 12 bits as a **system ID extension**, so a switch running a separate tree per VLAN, or per MSTP instance, can give each tree a distinct bridge ID while using one MAC address; the extension holds the VLAN or instance number. Only the top 4 bits stay configurable, so priority moves in steps of 2^12 = 4,096: sixteen values from 0 to 61,440, exactly the list RFC 4188 gives for 802.1t bridges. That is why a switch at the IEEE default 32,768 shows 32,769 in VLAN 1's tree and 32,778 in VLAN 10's. Every bridge in one tree carries the same extension, so it never decides an election.

go deeper

for a junior

Recall that the default priority is 32,768, that configurable values move in steps of 4,096, and that a displayed 32,769 simply means default priority plus VLAN 1.

for a middle

Explain the split of the 16-bit field into 4 configurable bits and a 12-bit system ID extension, why that yields steps of 4,096, and why the extension never decides an election.

for a senior

Read displayed priorities fluently, pick primary and secondary values on the 4,096 grid, and explain how per-tree bridge IDs let you place different roots for different VLAN groups.

for a principal

Weigh the trade the extension made, a coarser priority grid against distinct bridge IDs per tree from one address, and what multiplying trees per switch costs in operational complexity.

## The field before and after 802.1t A spanning-tree **bridge ID** is 8 octets: a 2-octet **priority field** followed by the bridge's 6-octet MAC address (RFC 4188, `BridgeId`). The lowest bridge ID wins the root election, so the priority field is the operator's lever. How those 16 priority bits are used changed with the IEEE 802.1t amendment: | Bits of the priority field | Original 802.1D | With the 802.1t system ID extension | |---|---|---| | top 4 bits | part of the priority | the configurable **priority** | | low 12 bits | part of the priority | the **system ID extension** | | configurable values | 0 to 65,535 | 0 to 61,440 in steps of 4,096 | RFC 4188 records both. Its `dot1dStpPriority` object has the base range 0 to 65,535, and its text adds that "on bridges supporting IEEE 802.1t or IEEE 802.1w, permissible values are 0-61440, in steps of 4096"; its compliance section lists the sixteen values one by one. The split itself is the IEEE's: its text is not reproduced in the RFC, which only restates the resulting values. ## Why the split was needed A single switch can take part in several spanning trees at once: - with **per-VLAN spanning tree**, an implementation choice that runs one tree per VLAN; - with **MSTP**, the IEEE's multiple spanning tree protocol, which runs one tree per instance, each serving a group of VLANs. Each tree needs its own bridge ID, because each tree runs its own root election. Before 802.1t, the obvious way to make the IDs distinct was a different MAC address per tree, which consumes a block of addresses per switch. The extension makes the IDs distinct for free: keep one MAC address and put the tree's number in the low 12 bits. Twelve bits matches the 12-bit VLAN identifier of an 802.1Q tag, so any VLAN number fits; under MSTP the IEEE fills the field with the instance number instead. The bridge ID itself stays 8 octets, so the BPDU format did not have to change; only the meaning of the priority bits did. ## The arithmetic 1. The configurable part is the top 4 bits of a 16-bit field, so one step is 2^12 = **4,096**. 2. Four bits give 2^4 = **16 values**: 0, 4,096, 8,192, and so on up to 15 x 4,096 = **61,440**. 3. The IEEE default priority is **32,768**, which is 8 x 4,096, the middle of the range, hexadecimal `0x8000`. 4. The value a switch displays for one tree is priority plus extension: 32,768 + 1 = **32,769** in VLAN 1, 32,768 + 10 = **32,778** in VLAN 10. 5. In hexadecimal the split is visible: 32,769 is `0x8001` and 32,778 is `0x800A`, the leading `8` being the configurable priority and the last three digits the VLAN. 6. A value such as 30,000 is not a multiple of 4,096, so a bridge using the extension cannot take it; the legal neighbours are 28,672 (7 x 4,096) and 32,768. ## What the extension does and does not do in an election The extension sits inside the priority field, so it is part of the number being compared. It still never changes the outcome of an election: - every bridge in one VLAN's tree puts the **same** VLAN number in its extension, so the extension is equal across all the candidates; - equal parts cannot separate two bridge IDs, so the comparison effectively runs on the configurable priority bits and then on the MAC address; - a lower VLAN number does **not** make a switch more likely to become root, because bridges in different VLANs' trees are never compared with each other. ## Practical consequences - **Read displayed values correctly.** A switch showing 32,769 in VLAN 1 has not been tuned; it is at the default. - **Choose values on the 4,096 grid.** A primary root at 24,576 and a secondary at 28,672 sit one step apart and both beat the default 32,768. - **Per-tree tuning is possible.** Because each tree has its own bridge ID, a switch can be given a low priority in some VLANs' trees and a higher one in others, a way of spreading root roles that belongs to per-VLAN and multiple spanning tree design. - **Zero is legal.** Priority 0 is the lowest value, but it does not make a root unbeatable: another bridge at priority 0 with a lower MAC address still wins.

  • What happens if you try to set a bridge priority of 30,000 on a switch that uses the system ID extension?
    A compliant bridge refuses it. RFC 4188 states that bridges supporting 802.1t or 802.1w accept only 0 to 61,440 in steps of 4,096, and 30,000 is not on that grid. The nearest legal values are 28,672, which beats the default, and 32,768, the default itself.
  • Two switches both show priority 32,778 in one VLAN's spanning tree. Which becomes root of that tree?
    The one with the lower MAC address. Both values decode to the default 32,768 plus VLAN 10, so the priority fields are identical and the comparison falls through to the 6-octet MAC address. The VLAN number in the extension never separates two bridges in the same tree.

saying these in an interview costs you the question

  • The 4,096 step is a vendor limitation rather than part of the IEEE standard.
  • The low 12 bits of the priority field hold part of the MAC address.
  • A switch showing 32,769 has been tuned one step better than the default.
  • The system ID extension lets a switch in a lower-numbered VLAN win the root election.
  • Every current bridge still accepts any priority from 0 to 65,535.