Spanning Tree Protocol Explained: STP, RSTP, MSTP and Loop Protection

Spanning tree is the family of IEEE 802.1 protocols that stops Ethernet frames from circling forever when switches are wired with redundant links. Every bridge exchanges small messages called BPDUs, the network elects one root bridge, and each bridge blocks just enough ports that exactly one loop free path remains between any two points. When a link fails, a blocked port takes over.

Three generations matter today. Classic STP (IEEE 802.1D) took 30 to 50 seconds to recover from a failure. Rapid Spanning Tree (RSTP, first published as 802.1w in 2001) usually recovers in well under a second on point to point links. Multiple Spanning Tree (MSTP, first published as 802.1s in 2002) runs several trees so different VLANs can use different links. All of it now lives in IEEE 802.1Q, and none of it authenticates the messages it trusts, which is why edge port protections such as BPDU guard and root guard matter as much as the protocol itself.

This post goes one level deeper than our explainer on how Ethernet switching works, MAC learning and VLANs, which covers flooding and the forwarding table that spanning tree protects. It sits next to ARP and IPv6 Neighbor Discovery explained, which covers the other big class of layer 2 trust problems, and our VXLAN and EVPN explainer, which covers the routed fabrics many data centres use instead of spanning tree.

Key takeaways

• Ethernet frames have no hop count or time to live, so a physical loop lets broadcast, multicast and unknown unicast frames circulate and multiply until links and switch CPUs saturate. Spanning tree exists to turn a looped physical topology into a loop free logical tree.
• The algorithm comes from Radia Perlman's paper "An algorithm for distributed computation of a spanning tree in an extended LAN", published in ACM SIGCOMM Computer Communication Review, volume 15, issue 4, September 1985, pages 44 to 53.
• The lowest bridge ID wins the root election. A bridge ID is a priority followed by a MAC address, so the default priority of 32768 on every device means the oldest or lowest MAC address becomes root unless you set priorities on purpose.
• Each non root bridge picks one root port (cheapest path to the root). Each LAN segment gets one designated port. Everything else blocks. Ties break on bridge ID, then port ID.
• Classic STP timers default to a 2 second hello, a 20 second max age and a 15 second forward delay. A port waits through listening and learning, two forward delays, before forwarding. An indirect failure can take max age plus two forward delays: 50 seconds.
• RSTP replaced timer driven convergence with a proposal and agreement handshake on point to point links, added alternate and backup port roles, and treats edge ports as forwarding immediately. 802.1D-2004 removed classic STP and kept RSTP.
• MSTP maps groups of VLANs to a small number of spanning tree instances inside a region whose bridges share the same configuration name, revision level and VLAN to instance table.
• IEEE 802.1Q-2014 superseded 802.1D-2004, so today's normative home for RSTP and MSTP is 802.1Q. The current edition is 802.1Q-2022, published 22 December 2022, and its PDF is available at no cost through the IEEE GET program.
• BPDUs carry no authentication. Any device that can send frames to a switch port running spanning tree can try to claim root, flood topology changes or create a loop. Edge protections (BPDU guard, root guard, loop guard, edge ports and storm control) are the fix.
• On Linux, the kernel bridge implements classic 802.1D STP and leaves it off by default. RSTP and MSTP on Linux come from a user space daemon such as mstpd. NetworkManager turns STP on for new bridges by default.

Why Ethernet loops cause broadcast storms

An Ethernet switch, which the standards call a bridge, learns which MAC addresses live behind which port and floods frames it cannot place. Three kinds of frame are flooded out of every port in the VLAN except the one they arrived on: broadcasts (such as ARP requests and DHCP discovers), multicasts the switch has no specific state for, and unicast frames to a destination the switch has not learned yet. Flooding is how Ethernet finds things. It is also why a loop is so destructive.

Picture three switches, A, B and C, cabled in a triangle. A host on A sends one ARP broadcast. A floods it to B and to C. B floods its copy to C, and C floods its copy to B. C now sends B's copy back to A, and B sends C's copy back to A. A floods both back out again. Nothing in the Ethernet header records how many times the frame has been forwarded, so nothing stops it. The TRILL specification, RFC 6325, puts the core problem plainly: the Ethernet header "does not contain a hop count (or Time to Live (TTL)) field."

Three things go wrong at once:

1. Broadcast storm. Copies multiply with each lap. Within seconds the links run at line rate carrying the same few frames, and the switches' control plane CPUs, which must inspect broadcasts such as ARP and some multicast, saturate.
2. MAC table instability. The same source MAC address arrives on different ports as copies circle in both directions. The switch keeps moving the address between ports, so even unicast traffic is misdelivered or flooded.
3. Duplicate delivery. Hosts receive many copies of the same frame, which breaks protocols that do not expect duplicates and adds to the load.

IP has a time to live field and routers decrement it, so a routing loop eventually drains. A layer 2 loop never drains on its own. It stops only when someone breaks the loop, a port shuts down, or a protocol blocks a link. Spanning tree is that protocol.

How spanning tree prevents the loop

Spanning tree takes the graph of bridges and LAN segments and computes a tree: one path between every pair of points, no cycles. Redundant links stay cabled but are put into a blocking or discarding state, where they drop user frames and only listen for spanning tree messages. If an active link fails, the bridges recompute and unblock a redundant port. You get redundancy in cabling without loops in forwarding.

The cost is that redundant links carry nothing while they are blocked, and traffic follows the tree, not the shortest path. RFC 6325 lists the same objections: spanning tree "creates bottlenecks by concentrating traffic onto selected links", forwarding is "not pair-wise shortest path", and "VLANs can partition when the spanning tree reconfigures." Those limits are why MSTP, Shortest Path Bridging, TRILL and routed EVPN fabrics exist, and we cover them in the comparison table later.

Where spanning tree came from and where it lives today

Radia Perlman, then at Digital Equipment Corporation, published the distributed spanning tree algorithm in 1985. Crossref lists two records for the paper: the SIGCOMM '85 proceedings and the September 1985 issue of ACM SIGCOMM Computer Communication Review (volume 15, issue 4, pages 44 to 53). The IEEE turned the idea into IEEE 802.1D, the MAC bridges standard, and has revised and amended it many times since.

Timeline of spanning tree standards and alternatives

Dates below come from each standard's IEEE SA page (board approval and publication) and from the RFC Editor for IETF documents.

Two notes on the table. First, the IEEE SA page for 802.1D-2004 marks it "Superseded" by 802.1Q-2014; the Linux kernel's bridge documentation goes further and says 802.1D "has been officially withdrawn in 2022". Either way, if you want the normative text for RSTP or MSTP today, read 802.1Q, not 802.1D. Second, 802.1Q-2022 has a long list of amendments (802.1Qcj, Qcw, Qcz in 2023; Qdj and Qdx in 2024; Qdy in 2025), mostly for time sensitive networking and YANG models, so check the amendment list on the IEEE page before you assume a feature is in the base text.

How STP elects a root bridge and chooses port roles

Spanning tree runs the same deterministic comparison on every bridge. Because every bridge sees the same advertised values and applies the same tie breakers, they all converge on the same tree without a central controller.

Bridge IDs

Each bridge has an 8 byte bridge identifier: a 2 byte priority followed by a 6 byte MAC address. Lower is better. In current practice the 16 bit priority field is split into a 4 bit priority and a 12 bit system ID extension, which MSTP and per VLAN implementations use to carry the instance or VLAN number. That is why priorities on modern gear move in steps of 4096: the Open vSwitch database documentation says the RSTP priority "needs to be a multiple of 4096, otherwise it's rounded to the nearest inferior one", and mstpd skips the multiplication entirely and takes a value from 0 to 15, where 8 (8 x 4096 = 32768) is the default.

The default priority is 32768 nearly everywhere: the Linux kernel documentation, NetworkManager's bridge settings and Open vSwitch all use it. With every bridge at 32768, the tie breaker is the MAC address, and the bridge with the numerically lowest MAC becomes root. That is often the oldest switch in the building, which is exactly the one you do not want at the centre of the tree.

BPDUs: what bridges tell each other

Bridges exchange Bridge Protocol Data Units (BPDUs) sent to the reserved group address 01:80:C2:00:00:00. The Linux kernel documentation describes the bridge group address as a link local address of the form 01:80:C2:00:00:0X. A classic configuration BPDU is 35 bytes inside an 802.2 LLC header, and the Linux source (net/bridge/br_stp_bpdu.c) shows its layout field by field:

A TCN BPDU is just the first four bytes: protocol ID, version and type 0x80. The Wireshark STP dissector reference lists field names for all of this (for example stp.root.hw, stp.root.cost, stp.bridge.hw, stp.flags.tc, stp.flags.proposal, stp.flags.agreement, and for MSTP stp.config_name, stp.config_digest and stp.msti.root.hw) and says the dissector understands BPDU versions 0, 2, 3 and 4, the last being used by Shortest Path Bridging.

The four comparisons

When a bridge receives BPDUs, it ranks the information with a strict order. The first difference decides:

1. Lowest root bridge ID.
2. Lowest root path cost (the advertised cost plus the cost of the port it arrived on).
3. Lowest sender bridge ID.
4. Lowest sender port ID (port priority, then port number).

Using that order, the protocol fills three roles:

• Root bridge. At start up every bridge claims to be root. As soon as a bridge hears a BPDU with a lower root ID, it stops claiming and starts relaying the better information. Eventually every bridge agrees on the lowest bridge ID in the network.
• Root port. Each non root bridge picks the one port with the best path to the root. The root bridge has no root port.
• Designated port. On each LAN segment, the bridge offering the best path to the root owns the designated port for that segment, and it alone forwards onto that segment. All ports on the root bridge are designated.

Any port that is neither a root port nor a designated port blocks. In RSTP terms it becomes an alternate port (a backup path to the root through another bridge) or a backup port (a redundant connection to a segment this bridge already serves).

Path costs

Each port has a cost, usually derived from link speed. The Linux bridge derives the default cost from the link speed reported by ethtool, and the source (net/bridge/br_if.c) uses the older short scale: 100 for 10 Mb/s, 19 for 100 Mb/s, 5 for 1 Gb/s, 4 for 2.5 Gb/s, 3 for 5 Gb/s, 2 for 10 Gb/s and 1 for anything faster. The kernel caps manual costs at 65535. Later editions of the standard recommend a 32 bit long scale, commonly quoted as 20,000 for 1 Gb/s and 2,000 for 10 Gb/s, so faster links can still be told apart; check the cost table in your copy of 802.1Q before you rely on exact values. mstpd uses 0 to mean "derive automatically".

The scale matters when you mix implementations. If one bridge advertises short scale costs and its neighbour uses long scale, root path costs are not comparable and the tree may not be the one you designed. Pick one scale, set costs explicitly on important links, and check the advertised root path cost on every bridge after a change.

Worked example: electing a root and choosing ports

Four switches are cabled in a square with one diagonal: Core1 to Core2, Core1 to Access1, Core2 to Access2, Access1 to Access2, and Core1 to Access2. All links are 10 Gb/s with a long scale cost of 2,000. Priorities and MACs are:

Root election: Core1 has the lowest priority, so it wins even though Access1 has the lowest MAC. Without the explicit 4096, Access1 would be root because 00:1b:00:00:00:01 is the lowest MAC.

Root ports:

• Core2 reaches Core1 directly at cost 2,000. Root port: the link to Core1.
• Access1 reaches Core1 directly at 2,000, or via Access2 at 4,000. Root port: the link to Core1.
• Access2 reaches Core1 directly over the diagonal at 2,000, via Core2 at 4,000, or via Access1 at 4,000. Root port: the diagonal to Core1.

Designated ports per segment:

• Core1 to Core2, Core1 to Access1 and Core1 to Access2: Core1 is root, so its ports are designated on all three.
• Core2 to Access2: both ends advertise a root path cost of 2,000, so the tie moves to bridge ID. Core2 (8192) beats Access2 (32768), so Core2's port is designated and Access2's port is an alternate (blocked).
• Access1 to Access2: both advertise 2,000. Access1's bridge ID (32768 / 00:...:01) beats Access2's (32768 / 00:...:02) on MAC, so Access1's port is designated and Access2's end blocks.

Result: Access2 forwards only on the diagonal and holds two alternate ports. If the diagonal fails, Access2 picks the best alternate. Both alternates offer 4,000, so the tie goes to the lower sender bridge ID: Core2 (8192) beats Access1 (32768), and the link to Core2 becomes Access2's new root port.

Now change one thing: give Core2 a 1 Gb/s link to Access2 with cost 20,000. Nothing in the steady state changes, because that port was already blocked, but on diagonal failure Access2 would now compare 2,000 + 20,000 = 22,000 via Core2 against 4,000 via Access1, and pick Access1. Costs only matter on the paths the tree actually uses, which is why you should test failover rather than read the steady state alone.

Port states, timers and why classic STP was slow

Classic 802.1D defined five port states. The Linux bridge man page lists them with the numbers the kernel uses:

RSTP collapses disabled, blocking and listening into one state, discarding, so it has three: discarding, learning and forwarding. Port role (root, designated, alternate, backup) and port state are separate in RSTP, which is part of why it converges faster.

The three classic timers

The defaults and ranges above come from the Linux kernel documentation and br_private_stp.h. NetworkManager uses the same defaults: hello time 2, max age 20, forward delay 15. The defaults assume a network diameter of up to seven bridges; the timers were sized so that BPDUs could cross the whole network before anyone acted on stale information.

Worked example: classic convergence times

A new port comes up. It goes through listening for one forward delay and learning for another before it forwards: 15 + 15 = 30 seconds. For a PC that is 30 seconds without a network, long enough for DHCP clients to give up and for network boot to fail. This is the original reason "edge port" features exist.

An indirect link failure. Access2 loses its root port, but the failure is on a link two hops away, so Access2 does not see a link go down. It simply stops receiving fresh root information. It has to wait for that information to expire (up to max age, 20 seconds), then move an alternate port through listening (15 seconds) and learning (15 seconds). Total: 20 + 15 + 15 = 50 seconds of disruption for hosts behind it.

A direct link failure. If the bridge sees its own root port go down, it can skip the max age wait and start the alternate port immediately, so the outage is the 30 seconds of listening and learning.

Topology changes and MAC flushing

When a port moves to forwarding or a forwarding port fails, MAC addresses may now live behind different ports. Classic STP handles this with a topology change notification. The bridge that saw the change sends a TCN BPDU up its root port, every bridge on the way acknowledges it and relays it, and the root then sets the topology change flag in its configuration BPDUs for a while (the Linux bridge keeps it set for forward delay plus max age). While that flag is set, every bridge shortens its MAC ageing time so stale entries expire quickly. The Linux source sets ageing to twice the forward delay during a topology change, which is 30 seconds instead of the normal 300.

The side effect: during a topology change, switches forget addresses faster and flood more unknown unicast traffic. One flapping port can keep a whole network in that state. Remember this, because it matters in the attack section.

What RSTP and MSTP changed

RSTP (802.1w, now in 802.1Q)

The IEEE abstract for 802.1w says it defines "the changes necessary to the operation of a MAC Bridge in order to provide rapid Spanning Tree reconfiguration capability." The key changes:

• Proposal and agreement. On a point to point link, a designated port that wants to forward sends a BPDU with the proposal flag. The neighbour puts its other non edge ports into discarding (a step called sync), then replies with agreement, and the designated port goes straight to forwarding. The handshake ripples outward one link at a time, at the speed of BPDU exchange rather than timers.
• Alternate and backup roles. A bridge keeps a precomputed alternate port. If the root port fails, the alternate becomes the root port and forwards immediately, with no listening or learning wait.
• Edge ports. A port that faces only end stations can be configured as an edge port and forwards as soon as the link is up. If it ever receives a BPDU, it loses edge status and takes part in spanning tree normally. mstpd also supports automatic edge detection (setportautoedge, default yes).
• Local hellos and faster failure detection. Every bridge sends BPDUs every hello time rather than only relaying the root's. Missing three hellos in a row ages out a neighbour's information, so detection takes about 6 seconds with defaults instead of 20.
• New topology change handling. Only non edge ports moving to forwarding trigger a topology change. The bridge that sees it flushes its own MAC entries on the affected ports and sets the topology change flag in its own BPDUs, so the flush spreads quickly without waiting for the root. Edge ports going up and down no longer cause network wide flushes.
• Backward compatibility. An RSTP port that hears version 0 BPDUs falls back to classic STP behaviour on that port, which also means slow convergence on that segment.

Fast convergence depends on two conditions: links must be point to point (full duplex links are treated as point to point by default; mstpd's setportp2p defaults to auto), and both ends must speak RSTP or MSTP. Mixed networks behave like the slowest part.

MSTP (802.1s, now in 802.1Q)

The IEEE abstract for 802.1s says it allows "data traffic belonging to different VLANs to be allocated to different spanning trees". RSTP or classic STP build one tree for all VLANs, so a blocked link is blocked for everyone. MSTP builds several:

• Regions. Bridges belong to the same MST region only if they share three settings: the region configuration name, the revision level, and the VLAN to instance mapping table. The mapping is carried as a digest in every MST BPDU (Wireshark's stp.config_name, stp.config_revision_level and stp.config_digest). One mismatched VLAN mapping splits a region.
• CIST and IST. The Common and Internal Spanning Tree connects regions and single tree bridges together. Inside a region, the Internal Spanning Tree is the region's part of the CIST.
• MSTIs. Multiple Spanning Tree Instances run inside the region. Each instance carries a set of VLANs and has its own root, priorities and port states, so instance 1 can forward on link X while instance 2 forwards on link Y. mstpd's documentation describes 2 to 64 MSTIs in addition to the CIST. All instances share one BPDU per port, so the overhead does not grow with the number of VLANs.
• Hop count. Inside a region, BPDU information expires after a maximum hop count rather than message age, which mstpd exposes as setmaxhops.

The Linux bridge man page summarises the payoff: in the MST model "a bridge port can simultaneously forward one subset of VLANs, while blocking another."

Per VLAN spanning tree variants

Some switch families also offer proprietary per VLAN variants, which run a separate STP or RSTP instance for every VLAN and send a BPDU per VLAN per port. Wireshark dissects these too (its field list includes stp.pvst.origvlan). They give per VLAN load balancing like MSTP without region configuration, but the BPDU load and CPU cost scale with the number of VLANs, and they interoperate with standard bridges only through the common instance. If you run a multi vendor network, MSTP is the standard way to get the same result.

Attack history and abuse, conceptually

Spanning tree was designed for a cooperative network. BPDUs are not signed, there is no notion of which ports are allowed to send them, and every bridge believes the best information it hears. That is fine between switches you own. It is a problem on any port where someone else controls the device: user access ports, hypervisor hosts, lab benches, conference rooms and links to other organisations. The issues below are described by mechanism, fix and lesson, not as instructions.

Rogue root claims

The election rule is lowest bridge ID wins, and priority 0 is legal. A device that sends BPDUs with priority 0 and a low MAC address will out rank a root left at 32768, and often one set to 4096. Every bridge then rebuilds its tree around the new root. Two things follow. Paths change, so traffic between switches can be pulled through the rogue device's link, which turns a spanning tree problem into an interception problem. And the reconvergence itself causes outages, longer with classic STP.

The Linux kernel documentation describes root port guard for exactly this reason: on a port with it enabled, "If BPDU is received from a leaf (edge) port, it should not be elected as root port", which "prevents a hostile guest from rerouting traffic." The fix on switches is the same idea. Mark ports where the root should never appear (all access ports, and downlinks to switches you do not run) with root guard, so a superior BPDU puts that port into a blocked, root inconsistent state instead of moving the root. Combine it with deliberate priorities: primary root at the lowest value you use, a secondary root one step above, everyone else at default.

Lesson. The protocol trusts the best claim it hears, and nothing in a BPDU proves who sent it. Put your trust boundary at the port: decide which ports may ever carry root information.

BPDU floods and control plane exhaustion

BPDUs are sent to the CPU of every switch that runs spanning tree, so a port that sends them at high rate, or with ever changing contents, makes the switch do work on every frame. Combined with superior BPDUs, a flood can keep the tree recalculating. The general fix is to stop BPDUs at the edge (BPDU guard shuts the port on the first one) and to rate limit control plane traffic on the switch itself, which most managed switches support as control plane policing or protocol rate limits.

Lesson. Every parser that runs on the control plane is part of your availability budget. Rate limit what reaches it.

Topology change abuse

As the timers section showed, a topology change makes switches age MAC addresses quickly (classic STP) or flush them outright (RSTP). Until they relearn, frames to those addresses are flooded to every port in the VLAN. A device that generates topology changes repeatedly keeps the network in that state, which costs bandwidth and means more unicast traffic reaches hosts it was never meant for. Many networks do this to themselves without any attacker: a desktop port that is not marked as edge and flaps every time a laptop sleeps.

The fixes: mark host facing ports as edge ports, so their link changes do not raise topology changes under RSTP; and on links to other parties, use the standard restricted TCN behaviour, which mstpd exposes as setportrestrtcn and describes as restricting "the port's ability to propagate received topology change notification". Its sibling setportrestrrole restricts "the port's ability to take root role", which is the 802.1Q way to express root guard.

Lesson. Flooding is not only a performance event. While the MAC table is empty, unicast traffic behaves like broadcast.

Loops nobody intended

The most common spanning tree outage is not an attack. Someone plugs a small switch into two wall ports, or a hypervisor host bridges two uplinks, or a patch cable gets plugged into the same switch twice. If the looping device forwards BPDUs, spanning tree sees the loop and blocks a port. If it drops BPDUs (many unmanaged devices do, and so do host bridges with STP turned off), spanning tree sees nothing and the storm starts. BPDU guard stops the first case on an edge port. Storm control limits the damage in the second. Some switches also offer loop detection that sends a test frame and shuts a port if it comes back.

Lesson. Plan for loops that spanning tree cannot see.

Unidirectional links

If a fibre pair fails so that a port can receive but not transmit, its neighbour stops hearing BPDUs. A blocked port that stops hearing BPDUs eventually concludes the path is gone and becomes designated, which opens a loop. Loop guard handles this by keeping such a port blocked (in a loop inconsistent state) until BPDUs return, and RSTP's dispute mechanism catches some cases where a port receives inferior designated information while it believes it is designated. Link layer unidirectional detection protocols catch the physical fault directly.

Lesson. Absence of messages is not the same as absence of a path.

Protections, described by function

Every vendor names these features differently. Here is what each one does, so you can map it to whatever your platform calls it.

Two warnings about this table. BPDU filter is the most dangerous one: a port that neither sends nor processes BPDUs cannot detect a loop through it, so use it only where you have another loop prevention mechanism. And BPDU guard and root guard do different things: guard shuts the port on any BPDU, root guard allows BPDUs but refuses superior ones. Use guard on host ports and root guard where a downstream switch is expected.

Step by step: inspect and harden spanning tree on a Linux bridge

The Linux bridge is everywhere: hypervisor hosts, container hosts, home routers, lab machines and many appliance builds. The kernel's built in implementation is classic 802.1D STP. The kernel documentation explains that when STP is enabled the kernel calls /sbin/bridge-stp, and if that helper returns 0 the bridge is handed to a user space daemon (such as mstpd) instead. Newer kernels also offer an explicit stp_mode setting; the documentation notes it can only be changed while STP is off.

The commands below change networking on the host. Run them on a lab machine or over an out of band console, never over the bridge you are changing.

1. See what bridges exist and whether STP is on

# List bridges with details: stp_state, priority, timers, root_id
ip -d link show type bridge

# Port view: state (disabled, listening, learning, forwarding, blocking), cost, flags
bridge -d link show

# The same data through sysfs, useful in scripts
cat /sys/class/net/br0/bridge/stp_state        # 0 means STP is off
cat /sys/class/net/br0/bridge/root_id
cat /sys/class/net/br0/bridge/bridge_id
cat /sys/class/net/br0/bridge/root_port
cat /sys/class/net/br0/bridge/root_path_cost
cat /sys/class/net/br0/bridge/topology_change

If root_id equals bridge_id, this host thinks it is the root. On a hypervisor or container host plugged into a switched network, that usually means STP is on with the default priority and the host has a low MAC address, or that the upstream switch filters BPDUs. Either is worth fixing.

2. Decide whether the bridge should run STP at all

Most host bridges never form a loop: they have one uplink (or a bond) and virtual ports. The kernel default is STP off. NetworkManager, however, sets bridge.stp to TRUE by default, so a bridge created through it will run STP and send BPDUs to your upstream switch. If the switch port has BPDU guard, the switch will shut that port, which is a classic surprise after a host rebuild.

# NetworkManager: turn STP off on a single uplink host bridge
nmcli connection modify br0 bridge.stp no
nmcli connection up br0

# iproute2: turn STP off on a bridge created by hand
ip link set dev br0 type bridge stp_state 0

If the host bridge does have two uplinks that could form a loop, keep STP on and make sure the switch side is configured for it, or better, use a bond with LACP so there is one logical link and no loop.

3. If STP stays on, set priorities and timers on purpose

# Make sure this host never becomes root: use the worst priority step
ip link set dev br0 type bridge priority 61440

# Explicit costs on uplinks (kernel range 1 to 65535)
bridge link set dev eno1 cost 4
bridge link set dev eno2 cost 19

On a lab network where this host should be root, use a low priority such as 4096 instead, and set the switches above it to higher values.

4. Protect virtual and untrusted ports

# Shut a port if a BPDU arrives on it (BPDU guard)
bridge link set dev vnet0 guard on

# Never accept a root through this port (root port guard)
bridge link set dev vnet1 root_block on

# Check the flags took effect
cat /sys/class/net/br0/brif/vnet0/bpdu_guard
cat /sys/class/net/br0/brif/vnet1/root_block

The bridge man page notes that a port shut by guard "will be restarted if link is brought down, or removed and reattached", for example with ip link set dev eth0 down; ip link set dev eth0 up. With systemd-networkd, the per port [Bridge] section exposes UseBPDU= ("whether STP Bridge Protocol Data Units will be processed by the bridge port") and AllowPortToBeRoot=, both added in systemd version 223.

# /etc/systemd/network/30-vnet.network
[Match]
Name=vnet*

[Network]
Bridge=br0

[Bridge]
UseBPDU=no
AllowPortToBeRoot=no

5. Run RSTP or MSTP with mstpd when you need fast convergence

# After installing mstpd from your distribution, hand the bridge to it
mstpctl addbridge br0
mstpctl setforcevers br0 rstp

# Host facing ports: edge plus BPDU guard
mstpctl setportadminedge br0 vnet0 yes
mstpctl setbpduguard br0 vnet0 yes

# Port toward a switch you do not control: refuse root and TCNs from it
mstpctl setportrestrrole br0 eno2 yes
mstpctl setportrestrtcn br0 eno2 yes

# Inspect
mstpctl showbridge br0
mstpctl showport br0
mstpctl showportdetail br0 eno1

mstpd's README says it is "reported to be compliant" with an RSTP conformance test suite, with one stated exception, and warns that its MSTP code "is mainly untested". Use it for RSTP in production with that caveat in mind, and test MSTP carefully before you depend on it.

6. Watch BPDUs on the wire

# Show spanning tree frames with link layer headers
tcpdump -i eno1 -nn -e -v stp

# Or match the destination group address directly
tcpdump -i eno1 -nn -e ether dst 01:80:c2:00:00:00

In Wireshark, the display filter stp.flags.tc == 1 shows BPDUs with the topology change flag, and stp.root.hw shows who each bridge thinks is root. If you see more than one root MAC in a single VLAN over a few minutes, or topology change flags that never stop, investigate.

Open vSwitch

Open vSwitch disables both protocols by default. Its database reference says STP and RSTP "are mutually exclusive. If both are enabled, RSTP will be used", and that bond, internal and mirror ports do not take part. The RSTP edge setting is rstp-port-admin-edge (default false) with rstp-port-auto-edge (default true).

Step by step: managed switches, by category

Managed switches fall into a few categories: campus access switches, campus distribution or core switches, data centre top of rack switches, and small business or "smart" switches with a web interface. The command syntax differs, but the safe defaults are the same. The block below is vendor neutral pseudo configuration that shows intent, not any product's syntax.

# 1. One mode everywhere. Prefer RSTP; use MSTP where you need per VLAN paths.
spanning-tree mode rstp            # or: mst

# 2. Deterministic roots, set on purpose.
core-1:          spanning-tree priority 4096
core-2:          spanning-tree priority 8192
everything else: leave at 32768

# 3. Every host facing port: edge + BPDU guard + storm control.
interface range access-ports
  spanning-tree edge
  spanning-tree bpdu-guard enable
  storm-control broadcast level 1%
  storm-control multicast level 5%

# 4. Downlinks to switches you do not run: root guard (restricted role).
interface downlink-to-tenant
  spanning-tree root-guard

# 5. Switch to switch uplinks: point to point, loop guard.
interface range uplinks
  spanning-tree link-type point-to-point
  spanning-tree loop-guard

# 6. MSTP only: identical region settings on every switch in the region.
spanning-tree mst configuration
  name CAMPUS-A
  revision 3
  instance 1 vlan 10-19
  instance 2 vlan 20-29

What to check by category:

• Campus access switches. Every user port should be edge with BPDU guard. Confirm how a guard triggered port recovers (manual or after a timer) and that it raises a log or trap. Set storm control on broadcast and multicast; percentages depend on link speed and normal traffic, so measure first.
• Distribution and core. These hold the root and secondary root priorities. Check that root guard is on downlinks to any switch outside your control, and loop guard on inter switch links.
• Top of rack in a data centre. Host ports should be edge with BPDU guard even if servers use bonds, because a misconfigured host bridge can loop. Many modern fabrics run routed links between switches (see the comparison below), so spanning tree may only be a safety net on host ports.
• Smart and small business switches. Check the default mode (some still ship with classic STP) and whether BPDU guard exists at all. If it does not, prefer loop detection plus storm control on access ports.

After any change, verify on every switch: the root bridge ID, the root port, which ports are alternate, the count of topology changes and the time since the last one. A rising topology change counter is the earliest warning of a flapping port.

Comparison: STP, RSTP, MSTP, per VLAN variants and loop free designs

Decision guide

The EVPN specification still mentions spanning tree, which is a useful reminder. RFC 7432 defines an Ethernet segment identifier type for hosts that reach the provider edge through a bridged LAN running MSTP: the provider edge builds the identifier from the root bridge MAC address and priority of the region's internal spanning tree, learned by listening to BPDUs, without running MSTP itself. Even in fabrics that do not run spanning tree between switches, customer and host facing edges still meet it.

Common mistakes

• Leaving root election to chance. With every bridge at 32768, the lowest MAC wins. Set a primary and secondary root explicitly and write them down.
• Running STP on host bridges that do not need it. A NetworkManager bridge defaults to STP on. On a single uplink host this only adds a 30 second forwarding delay at boot and risks tripping BPDU guard upstream.
• Using BPDU filter as a quick fix. It silences the messages that detect loops. A port with BPDU filter and a looped device behind it will storm.
• Forgetting edge ports. Without edge configuration, every desktop that sleeps raises a topology change under RSTP, flushing MAC tables across the VLAN and causing flooding.
• Mismatched MST regions. A single VLAN mapped to a different instance on one switch changes the configuration digest and splits the region, which changes the tree in ways that are hard to see.
• Mixing path cost scales. Short scale and long scale costs in the same network make root path costs incomparable. Set costs explicitly on important links.
• Mixing classic STP into an RSTP network. One legacy bridge forces the segments it touches into slow behaviour. Find it by looking for version 0 BPDUs in a capture.
• Disabling spanning tree because the fabric is routed. A routed fabric protects switch to switch links. Host facing ports can still loop through a misconfigured server, so keep BPDU guard and storm control at the edge.
• Not alerting on topology changes. A topology change counter that keeps rising is the cheapest early warning you have. Graph it.
• Assuming storm control prevents loops. It limits the damage. It does not remove the loop.

FAQ

What is the difference between STP and RSTP?

Classic STP (802.1D) moves ports through listening and learning on timers, so a failure can take 30 to 50 seconds to recover. RSTP (802.1w, now part of 802.1Q) uses a proposal and agreement handshake on point to point links, precomputed alternate ports and edge ports, so it usually recovers in well under a second. RSTP is backward compatible with STP per port.

Is spanning tree still used in 2026?

Yes. It runs on most campus and branch switching, on many top of rack host ports, and in Linux and virtual switches. Data centre fabrics increasingly route between switches with EVPN and VXLAN instead, but they still need loop protection on host facing ports. The IEEE keeps maintaining it inside 802.1Q, whose next revision has an active project approved on 5 June 2023.

How is the root bridge chosen?

The bridge with the lowest bridge ID becomes root. The bridge ID is the priority followed by the MAC address, so priority decides first and the MAC address breaks ties. Priority is usually set in steps of 4096, and the default is 32768.

What does BPDU guard do?

BPDU guard shuts down a port as soon as it receives any spanning tree BPDU. It belongs on ports that should only ever connect to end hosts. On Linux the equivalent is bridge link set dev PORT guard on, and the kernel logs "BPDU received on blocked port" when it triggers.

What is the difference between BPDU guard and root guard?

BPDU guard rejects all BPDUs by shutting the port. Root guard accepts normal BPDUs but blocks the port if it receives a superior one that would move the root. Use BPDU guard on host ports and root guard on ports facing switches you do not control.

Why does my port take 30 seconds to come up?

That is two classic forward delays: 15 seconds in listening and 15 in learning. Configure the port as an edge port, or move to RSTP, and host ports will forward as soon as the link is up.

What is MSTP used for?

MSTP lets different groups of VLANs follow different spanning trees, so a link blocked for one group can forward for another. It needs every switch in a region to share the same region name, revision number and VLAN to instance mapping.

Does the Linux bridge support RSTP?

The in kernel bridge implements classic 802.1D STP. RSTP and MSTP come from a user space daemon such as mstpd, which the kernel hands control to through the /sbin/bridge-stp helper or the newer stp_mode setting. Open vSwitch includes its own STP and RSTP.

Can spanning tree be attacked?

Yes, because BPDUs are not authenticated. A device on a port running spanning tree can claim to be root, flood BPDUs or trigger topology changes. The protections are BPDU guard and edge ports on host ports, root guard on ports facing other switches, control plane rate limits and deliberate root priorities.

What replaces spanning tree in modern data centres?

Routed designs. Leaf and spine fabrics route between switches so IP time to live ends any loop, and EVPN with VXLAN carries layer 2 segments over that routed underlay where applications need them. Shortest Path Bridging and TRILL tried to bring shortest path forwarding to layer 2 itself but saw limited deployment.

Where Safeguard fits

Safeguard does not configure switches, monitor BPDUs, detect loops or scan switch firmware, and it will not tell you where your root bridge is. The fit is indirect and narrow. Spanning tree on hosts and virtual switches depends on ordinary open source software: the Linux kernel bridge, iproute2, mstpd, Open vSwitch, NetworkManager and systemd-networkd. Those packages ship inside the hypervisor images, container host images and appliance builds you deploy, and they receive fixes like any other component. Safeguard can scan those images and their SBOMs, show which projects carry a given version of Open vSwitch or iproute2, match them against known vulnerabilities, and open upgrade pull requests where you build the image yourself. Network automation code that writes switch configuration (Python libraries, Ansible collections and the like) is also ordinary software with dependencies, and the same scanning applies. For the switch operating system itself, the fix has to come from the switch vendor.

Software supply chain hygiene still matters for a layer 2 protocol because the code that sends and parses BPDUs on hosts and virtual switches is open source that gets rebuilt and redeployed with every image. The fit is indirect, and it covers only the software you build and ship, not switch firmware or a vendor's network operating system.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

These demos show dependency, image and remediation workflows, not switch configuration or loop detection. You can download Safeguard and follow the CLI docs to try them on your own projects.

This demo sets up the Safeguard runner on your own machine, approves it with its device code and scans from the terminal. Pointed at a hypervisor or container host image that bundles Open vSwitch, iproute2, mstpd and NetworkManager, the same scan lists the packages and versions inside it and their known vulnerabilities, so you know which images to rebuild when an advisory for one of them lands.

Click through it at your own pace, or open it full screen.

This demo is a real CLI session: ask it to fix the lodash CVE in a repository and watch it read the finding and the advisory, ask before each command, move lodash to 4.17.21, run npm install and npm test with your approval, and push nothing. The same approve each step flow applies when you bump a dependency in a network automation repository that renders switch or host bridge configuration.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. You can then ask which of your projects ship a given package version, such as a specific Open vSwitch release, and get the answer from your own scan data rather than from memory.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Crossref record: Perlman, "An algorithm for distributed computation of a spanning tree in an extended LAN", ACM SIGCOMM Computer Communication Review 15(4), September 1985
• IEEE SA: IEEE 802.1D-1990, Media Access Control (MAC) Bridges
• IEEE SA: IEEE 802.1D-1998, MAC Bridges
• IEEE SA: IEEE 802.1t-2001, Technical and Editorial Corrections
• IEEE SA: IEEE 802.1w-2001, Rapid Reconfiguration
• IEEE SA: IEEE 802.1s-2002, Multiple Spanning Trees
• IEEE SA: IEEE 802.1D-2004, MAC Bridges
• IEEE SA: IEEE 802.1Q-2005, Virtual Bridged Local Area Networks
• IEEE SA: IEEE 802.1aq-2012, Shortest Path Bridging
• IEEE SA: IEEE 802.1Q-2014, Bridges and Bridged Networks
• IEEE SA: IEEE 802.1Q-2022, Bridges and Bridged Networks
• IEEE SA: P802.1Q revision project (PAR approved 5 June 2023)
• Linux kernel documentation: Ethernet Bridging (STP, netlink attributes, STP mode)
• bridge(8), Linux manual page (iproute2)
• ip-link(8), Linux manual page (iproute2)
• Linux kernel source: net/bridge/br_stp.c
• Linux kernel source: net/bridge/br_stp_bpdu.c
• Linux kernel source: net/bridge/br_private_stp.h
• Linux kernel source: net/bridge/br_if.c (default port costs)
• Linux kernel source: net/bridge/br_sysfs_if.c (port sysfs attributes)
• Linux kernel source: net/bridge/br_sysfs_br.c (bridge sysfs attributes)
• mstpd project README
• mstpd: mstpctl(8) manual
• Open vSwitch: ovs-vswitchd.conf.db(5), STP and RSTP columns
• NetworkManager reference manual: bridge settings
• systemd.network(5): Bridge section options
• Wireshark display filter reference: Spanning Tree Protocol (stp)
• RFC 6325: Routing Bridges (RBridges): Base Protocol Specification, July 2011
• RFC 7348: Virtual eXtensible Local Area Network (VXLAN), August 2014
• RFC 7432: BGP MPLS-Based Ethernet VPN, February 2015
• RFC 8365: A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN), March 2018

Last reviewed: 23 October 2026. IEEE 802.1Q is under revision and Linux bridge options change between kernel and iproute2 releases; check the pages above for the versions you actually run.