Dell OS10 Spanning-Tree: RSTP, Rapid-PVST and Root Bridge

Dell PowerSwitch OS10 ships with Rapid PVST+ (rapid per-VLAN spanning tree) enabled by default, but many engineers are unsure how to switch it to plain RSTP, force a root bridge, or verify which port ended up blocked. This article is a practical OS10 spanning-tree configuration guide: the exact commands to change STP mode, set root bridge priority, tune interfaces, and read show spanning-tree output, based on the Dell SmartFabric OS10 user guide and Dell Knowledge Base.

Why Spanning Tree Still Matters on OS10

Layer 2 networks have no TTL. An Ethernet frame with an unknown destination is flooded out of every port except the one it arrived on, and nothing in the frame header stops it from looping forever. If two switches are connected by more than one path, and no protocol logically blocks the redundant links, a single broadcast will multiply packet by packet until the switching fabric is saturated. CPU spikes to 100 percent, MAC address tables thrash between ports, and the whole VLAN goes dark within seconds. Spanning Tree Protocol exists to prevent exactly that: it elects one root bridge, builds a loop-free tree of forwarding paths toward that root, and places every redundant link into a blocking state until it is needed.

Dell OS10 supports three spanning-tree variants, and the choice you make is the first decision in any design. Picking the wrong mode, or running mismatched modes across a link, is one of the most common causes of "random" outages on enterprise switches. This guide walks through each mode, the exact configuration commands, the verification output you should expect, and the tuning knobs that matter in production.

OS10 Spanning-Tree Modes: Which One to Pick

OS10 supports three modes: RSTP (one spanning-tree instance for all VLANs), Rapid-PVST+ (one instance per VLAN, the default), and MST (multiple instances with a region). RPVST+ is the default on all OS10 switching platforms; switch to RSTP only when your whole layer-2 domain is single-VLAN or when peering with devices that only speak one common spanning tree.

RSTP (802.1w) replaced the original 802.1D timers with a proposal/agreement handshake between neighbours, so a topology change reconverges in sub-second time rather than the 30 to 50 seconds a classic STP listen-learn-forward cycle takes. It runs a single logical tree, so every VLAN shares the same active topology.

Rapid-PVST+ (RPVST+) runs one RSTP instance per VLAN. That means VLAN 10 can block on one uplink while VLAN 20 forwards on the same physical link — the classic reason to use it in campus networks where traffic for different VLANs should take different paths. The trade-off is scale: each VLAN that exists on a trunk consumes memory and CPU for its own instance, so on large topologies with hundreds of VLANs, RPVST+ becomes expensive.

MST (802.1s) solves the scale problem by mapping many VLANs into a small number of instances you define yourself, and by advertising a region name, revision and VLAN-to-instance hash that must match on every switch in the region. MST converges almost as fast as RSTP, keeps per-VLAN load balancing, and is the usual choice in large enterprise and service-provider access layers.

A common campus design: RPVST+ at the access layer, where each access switch carries only a handful of VLANs, and MST at the distribution and core, where VLAN counts are high. The two can interoperate only through careful mapping, so if you plan to mix them, decide the mapping up front rather than after roll-out.

Switching the Spanning-Tree Mode

Change the protocol mode in configuration mode:

OS10(config)# spanning-tree mode rapid-pvst
OS10(config)# spanning-tree mode rstp
OS10(config)# spanning-tree mode mst

A mode change is disruptive: every port recomputes its role and state, so any port that was blocking may briefly transition and any that was forwarding may be re-evaluated. On a production switch, plan the change during a maintenance window, and change one switch at a time so the rest of the topology keeps its existing tree while the changed node re-inserts itself. Before you commit, confirm the current mode with show spanning-tree brief so you know exactly what you are changing from, and note the current root bridge for each VLAN so you can verify the topology came back the same way.

If a switch in the tree speaks a different mode than its neighbour on the same link, the two interoperate in a compatibility mode called Common Spanning Tree, which behaves like plain 802.1D: slow convergence and loss of per-VLAN behaviour. That is usually not what you want, so treat mismatched modes as a misconfiguration and standardise across the whole layer-2 domain.

Configuring MST Region (If You Use MST)

All switches in the same MST region must share the region name, revision and instance-to-VLAN mapping:

OS10(config)# spanning-tree mode mst
OS10(config)# spanning-tree mst configuration
OS10(conf-mst)# instance 1 vlan 2-10
OS10(conf-mst)# revision 10
OS10(conf-mst)# name ExampleMSTregion

The region name is case-sensitive and limited in length; a single typo splits two physically connected switches into separate regions. When two MST regions meet, they see each other as one giant foreign bridge and the entire region collapses into a single Common Spanning Tree instance across the boundary — per-VLAN load balancing disappears and convergence slows dramatically. The revision number must match exactly too, even though it is just a label you choose; many teams increment it whenever they change the VLAN-to-instance mapping so the change is visible in configuration diffs. Any VLAN you do not explicitly map into an instance is automatically carried in instance 0 (the IST), which is also the instance whose topology determines the physical path between regions.

Forcing the Root Bridge

Set a low bridge priority on the switch that should be root. In Rapid-PVST mode this is done per VLAN:

OS10(config)# spanning-tree vlan 1 priority 4096

OS10 adds 1 to the configured value internally (VLAN 1 root priority shows as 4097 in output, because the bridge ID uses the extended system ID). For RSTP mode use spanning-tree priority without a VLAN, or rely on spanning-tree root primary equivalents where supported. For MST, the priority is set per instance instead of per VLAN:

OS10(config)# spanning-tree mst 0 priority 4096
OS10(config)# spanning-tree mst 1 priority 8192

Priority is only half of the bridge ID. The other half is the base MAC address, and the bridge with the lowest combined value wins. Because MAC addresses are effectively random, two switches configured with the same priority can disagree about who is root, and a reboot that changes nothing else can flip the election if the priority values are equal. Always make the root priority unique on the intended root, and set the intended backup root with the next-lowest value so the tree fails over predictably instead of electing whichever random MAC happens to be smallest.

The recommended pattern is a pair of distribution switches with priority 4096 and 8192: the first is primary root for one set of VLANs, the second is primary for the other set, giving you active/active load balancing. Never leave a priority of 32768 (the default) on a core switch in a network where an access switch has been tuned — the default makes the core forfeit the election to any device with a lower value.

Tuning Port Cost and Priority

Once the root is decided, the tree picks exactly one forwarding path from every non-root switch toward it. Cost is the primary tiebreaker: each port has a cost derived from its bandwidth, and the path with the lowest cumulative cost to the root wins. OS10 lets you override the automatic value when the calculated one does not match your intent:

OS10(conf-if-eth1/1/1)# spanning-tree cost 1000
OS10(conf-if-eth1/1/1)# spanning-tree vlan 10 cost 1000
OS10(conf-if-eth1/1/1)# spanning-tree vlan 10 port-priority 64

Lower cost makes a port more attractive, so lowering the cost on a 10G uplink you actually want to use pulls traffic onto it even if an alternate path has the same bandwidth. Port priority is the tiebreaker when two ports on the same switch have equal cost to the root; the lower port priority (or, failing that, the lower port number) becomes the root port and the other is blocked. On VLT or MLAG pair links you normally want the peer-link excluded from the tree entirely and the two member switches to appear as one bridge, which is why VLT must be designed alongside STP rather than after it.

Edge Ports and BPDU Guard

Ports connected to servers, workstations and access points should never expect BPDU frames. Marking them as edge ports lets RSTP skip the listening and learning phases entirely so the link comes up in forwarding state immediately:

OS10(conf-if-eth1/1/10)# spanning-tree portfast
OS10(config)# spanning-tree portfast bpduguard default
OS10(config)# spanning-tree portfast bpdufilter default

BPDU Guard is the safety net. If a BPDU is received on an edge port — for example, because someone plugged a rogue switch or a looped cable into a wall port — the port is error-disabled instead of joining the topology. Without BPDU Guard, that rogue switch can become root for the VLAN and pull all traffic through an access port, which is exactly how accidental root hijacks take down campus networks. BPDU Filter, by contrast, stops the switch from sending or processing BPDUs on the port; use it only where you fully control what is connected, because it can silence the detection that Guard relies on.

Verification Commands

Confirm the mode, root bridge and per-port state:

OS10# show spanning-tree active
OS10# show spanning-tree brief
OS10# show spanning-tree vlan 1
OS10# show running-configuration | grep spanning-tree

In the show spanning-tree active output check the Root ID line: We are the root of VLAN 1 confirms your priority took effect, and the Interface table shows FWD/BLK states per port. A typical healthy output looks like this:

VLAN 1
  Root ID    Priority  4097
             Address   e4:f0:04:11:22:33
             This bridge is the root
             Hello Time 2 sec  Max Age 20 sec  Forward Delay 15 sec
  Bridge ID  Priority  4097
  Interface        Role  State  Cost  Prio.Nbr  Type
  ethernet1/1/1    Desg  FWD    2000   128.1     P2P
  ethernet1/1/2    Desg  FWD    2000   128.2     P2P
  ethernet1/1/3    Desg  FWD    1900   128.3     P2P Edge
  ethernet1/1/4    Desg  BLK    2000   128.4     P2P

Read it in this order: confirm the Root ID matches the switch you intend to be root, confirm the local bridge ID priority matches what you configured plus one, then walk the interface table looking for any port that is Forwarding when you expected it Blocked (a sign of a broken root or cost election) or Blocked when you expected Forwarding (a sign that a lower-cost path exists somewhere you did not plan for).

Reading show spanning-tree Output

Four fields carry almost all the diagnostic weight. The Root ID tells you which switch won the election and its priority; if it is not the switch you tuned, someone else has a lower priority or a lower MAC. Bridge ID is this switch's own identity. Role describes what the port does in the tree: Root (best path to the root), Designated (best path away from the root on a segment), Alternate (a backup path, blocked in RSTP), or Disabled. State is the data-plane effect — Forwarding or Blocking/Discarding. For MST, use show spanning-tree mst 0 and show spanning-tree mst configuration to see instance-level topology and the region digest, and confirm the digest matches on every switch in the region.

Two counters are worth watching over time: topology changes and the last-change time. A handful of topology changes during a maintenance window is expected; continuous changes every few seconds means a flapping link or a misconfigured edge port, and each change flushes MAC tables and briefly floods traffic. Raising the topology-change count is often the first symptom of an unstable access port long before users notice anything.

VLT Considerations

When OS10 switches run VLT, RSTP and RPVST+ are both supported, and Dell recommends making the VLT primary node the root bridge. Never run different STP modes on the two VLT peers - loops will appear because each switch computes a different topology. The VLT Interconnect (VLTi) carries control traffic and is kept out of the STP topology; if the peer-link fails and the backup link is active, the secondary switch stops forwarding on the VLT ports to avoid a split-brain loop, so always configure the VLT backup link with a management path that the peers can reach.

Because a VLT pair looks like one bridge to the rest of the network, you set the root priority on the VLT domain as a whole rather than fighting the election between the two peers. A common mistake is tuning priority on both peers independently and accidentally giving the secondary a lower value than the primary; the result is traffic for one VLAN taking the secondary's uplinks while another VLAN takes the primary's, which is survivable but makes troubleshooting far harder than it needs to be.

Troubleshooting Common Issues

The wrong switch becomes root. Check priorities on every switch (including access switches someone tuned by hand) and confirm the base MAC order. Reset the design across all VLANs, not just the one that is broken.

A port that should block is forwarding (loop). Usually a mode mismatch or a broken VLT peer-link. Confirm both ends run the same mode and that the VLTi is up with show vlt.

A port is stuck in error-disabled. BPDU Guard fired. Find out what is sending BPDUs — a rogue switch, a looped cable, or a virtual machine with bridging enabled — fix the source, then recover the port with shutdown / no shutdown.

Reconvergence is slow after a link flaps. The mode is likely falling back to compatibility (Common Spanning Tree) because of a mismatch, or the link is not being treated as point-to-point. Confirm with the port Type column showing P2P.

VLAN not converging at all after a mode change. In MST, confirm the VLAN is mapped into an instance and that the region digest matches everywhere. An unmapped VLAN silently joins instance 0, which can push traffic onto a path you did not plan.

Best Practices Checklist

1. Standardise one mode across the whole layer-2 domain; document the choice and the reason.
2. Set a unique root priority on the intended root and the next-lowest value on the backup root.
3. Never leave the default 32768 on a device that should or should not be root.
4. Enable PortFast and BPDU Guard on every access port; treat a BPDU on an edge port as an incident.
5. Use MST instances to keep per-VLAN load balancing without paying the cost of instance-per-VLAN.
6. Keep the VLTi out of the tree and set root priority on the VLT pair as a single bridge.
7. Monitor topology-change counters, not just port states — flapping shows up there first.

Related Guides on This Site

Spanning-tree usually follows a fresh switch build: see Dell OS10 factory reset and post-reset setup, the OS10 VLT peer-routing guide, and OS10 OOB management configuration. For tree design beyond one vendor, compare Cisco MST region, instance and VLAN mapping and the Juniper EX virtual chassis CLI guide, and when a VLT pair misbehaves, work through Dell OS10 VLT troubleshooting with show vlt.

原文链接：https://www.dell.com/support/kbdoc/en-us/000317735/smartfabric-os10-spanning-tree-protocol-with-vlt