RSTP vs MSTP: Convergence, Instances and Migration

Classic 802.1D spanning tree converges in about 50 seconds — unacceptable for any modern network. RSTP (802.1w) fixes convergence with explicit port roles and handshakes; MSTP (802.1s) then solves RSTP's scaling problem by mapping many VLANs onto a few spanning tree instances, each with its own topology for load balancing. This guide contrasts the two, explains MST regions and the IST/MSTI model, and shows the Cisco commands to switch modes and build an MST region.

If you are choosing between them for a live campus or data center, the decision rarely comes down to raw speed — both converge in the sub-second range on modern hardware. It comes down to how many topologies you actually need, how much control-plane load your switches can absorb, and how much you care about per-VLAN forwarding paths. The rest of this article walks the protocol mechanics first, then the design and migration decisions.

What Problem Does Each Protocol Solve?

Every spanning tree variant answers the same question: how do I build a loop-free Layer 2 topology? They differ in how fast they react and how many independent topologies they maintain.

The important shift is that RSTP keeps the "one tree per VLAN" model but makes it converge fast, while MSTP breaks the "one tree per VLAN" assumption entirely and lets a single instance cover a whole group of VLANs.

Port Roles and States: What RSTP Changed

802.1D had five states (blocking, listening, learning, forwarding, disabled) and only two roles (root, designated). RSTP collapses the states to three and expands the roles to four, so a port can be in a non-forwarding state and still know why:

• Root port — the single port on a non-root bridge closest to the root.
• Designated port — the port on a segment that is closest to the root; one per segment.
• Alternate port — a discarding port that receives a superior BPDU from another bridge; it is a hot standby for the root port and can take over immediately.
• Backup port — a discarding port that receives a superior BPDU from itself (a redundant port on the same bridge); only occurs on shared-media segments or where two ports of one bridge connect.

States collapse to discarding (no learning, no forwarding), learning (populating the MAC table, not forwarding), and forwarding. Because the alternate/backup role already identifies a usable backup path, RSTP skips the listening state entirely and can move a port from discarding to forwarding without waiting for a timer.

How RSTP Converges: Proposal, Agreement and Sync

RSTP removes timer dependence with a two-way handshake that propagates outwards from the root. On a point-to-point link, the sequence is:

1. A bridge with a new or better root port marks all its non-edge ports as discarding (the "sync" step) and sends a Proposal flag on its designated port.
2. The neighbour receives the proposal, synchronises its own ports (blocking the ones that would create a loop), and answers with an Agreement flag.
3. On receiving the agreement, the proposing bridge immediately puts its port into forwarding — no forwarding delay timer.
4. The neighbour repeats the proposal/agreement cycle on its own downstream designated ports, so convergence sweeps the topology one hop at a time.

That is why RSTP convergence is measured in hundreds of milliseconds on a well-built point-to-point topology, and why the link type setting matters so much. A port configured as shared falls back to timer-based behaviour and loses the fast handshake. Junos and EOS auto-detect link type; some platforms and every half-duplex port default to shared, so verify it when a port takes seconds instead of milliseconds to come up.

Edge Ports, Link Types and Topology Change

An edge port (Cisco's PortFast) is a port where no bridge can ever be expected — server NICs, printers, access points. Edge ports move to forwarding immediately and are not part of the handshake. If a BPDU arrives on an edge port, RSTP revokes the edge status and re-runs the normal election, which is exactly what BPDU Guard turns into a shutdown.

Topology change handling also changed. In 802.1D a topology change was flooded to the root and then back down the tree, so every bridge flushed its MAC table. In RSTP a bridge sets the TC flag and the TC-While-Timer instead, and only the affected bridges age MAC entries aggressively; in MSTP this happens per instance, so a change in instance 2 does not flush the forwarding table of instance 1's VLANs. That difference alone removes a lot of unnecessary flooding in a large campus.

RSTP: Fast Convergence, One Tree per VLAN (PVST+)

RSTP redefines port states as roles (root, designated, alternate, backup) and converges in the low hundreds of milliseconds on point-to-point links — no reliance on timers, using proposal/agreement handshakes and edge-port behavior instead. Cisco's rapid-PVST+ runs one RSTP instance per VLAN, which gives per-VLAN load balancing but burns CPU and BPDU overhead as the VLAN count grows:

Switch(config)# spanning-tree mode rapid-pvst
Switch(config)# spanning-tree vlan 10 priority 4096

In rapid-PVST+ every VLAN has its own instance, its own BPDUs and its own root. With 400 VLANs on a trunk, that is 400 BPDUs per hello interval on that link, and 400 separate state machines per switch. The costs are real: CPU, memory, and BPDU bandwidth on inter-switch links. The benefit is that VLAN 10 can be rooted on one distribution switch while VLAN 20 is rooted on the other, so both uplinks carry traffic.

MSTP: Many VLANs, Few Instances

MST (802.1s) maps groups of VLANs to a single MST instance (up to 65). Each instance computes its own spanning tree, so instance 1 can block one uplink while instance 2 blocks the other — load balancing with a fraction of the instances PVST+ needs. Instances live inside an MST region: switches with the same region name, revision number and VLAN-to-instance mapping.

The practical consequence is that you design the number of topologies you need instead of inheriting one per VLAN. A typical three-instance plan for a two-uplink access switch looks like this:

Two instances, two uplinks, and both carry production traffic — with a fraction of the BPDUs and state machines that 60 per-VLAN instances would require.

IST and MSTIs

Inside a region, the Internal Spanning Tree (IST, instance 0) is an RSTP instance that represents the whole region to the outside world — it is the only instance that exchanges BPDUs across the region boundary, which is why the entire region looks like one bridge to neighboring PVST+/RSTP networks. The remaining MSTIs are pure RSTP instances that never leave the region. MST runs RSTP internally, so you get rapid convergence and instance scaling.

Precisely: the CIST (Common and Internal Spanning Tree) is the union of the IST inside the region plus the spanning tree between regions. Outside the region, BPDUs carry only instance 0 information. Inside, each MSTI runs its own RSTP state machines and exchanges MSTP BPDUs that carry one MSTI configuration message per instance. A port that is a boundary port for the CIST carries BPDUs for all instances, but the topology inside the region is invisible to the outside.

MST Region Identity: Name, Revision and Mapping

Three attributes must match exactly on every switch for them to belong to the same region:

• Configuration name — a case-sensitive string, 32 characters maximum.
• Revision level — a 16-bit integer; bump it whenever you change the mapping.
• VLAN-to-instance mapping — the full table, including VLANs left in instance 0.

Switches compute an MD5 digest of the mapping and embed it in their BPDUs. If any one of the three differs — a trailing space in the name, a revision that was incremented on one switch but not its neighbour, one VLAN assigned to instance 3 instead of 2 — the switches recognise a mismatch, become boundary ports, and each side elects its own CIST root. The result looks like a working network with a mysteriously bad path, which is why a mapping audit is the first troubleshooting step.

Configuring an MST Region on Cisco

Switch(config)# spanning-tree mode mst
Switch(config)# spanning-tree mst configuration
Switch(config-mst)# name REGION-CORE
Switch(config-mst)# revision 1
Switch(config-mst)# instance 1 vlan 10,20
Switch(config-mst)# instance 2 vlan 30,40
Switch(config-mst)# exit

Every switch in the region must carry the identical name, revision and mapping — any difference and the switches split into separate regions at the boundary. Untagged VLANs stay on the CIST (instance 0); only VLANs explicitly mapped leave it. Set per-instance roots the same way as per-VLAN roots:

Switch(config)# spanning-tree mst 1 priority 4096
Switch# show spanning-tree mst configuration
Switch# show spanning-tree mst 1

Use spanning-tree mst 1 root primary and root secondary instead of hard-coded priorities if you would rather have the switch pick a value below the default 32768 automatically; primary sets 24576 (or 4096 if that is already taken) and secondary sets 28672.

Verifying MSTP Operation

Switch# show spanning-tree mst configuration
Name      [REGION-CORE]
Revision  1    Instances configured 3

Instance  Vlans mapped
--------  ---------------------------------------------------------------------
0         1-9,11-19,21-29,31-4094
1         10,20
2         30,40
-------------------------------------------------------------------------------

Switch# show spanning-tree mst 1

##### MST1    vlans mapped:  10,20
Bridge        address 001b.0d12.3400  priority  4096   (4096 sysid 1)
Root          address 001b.0d12.3480  priority  4096   (4096 sysid 1)
              this bridge is the root
Interface        Role Sts Cost      Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Gi1/0/1          Desg FWD 20000     128.1    P2p
Gi1/0/2          Desg FWD 20000     128.2    P2p

Read the output top to bottom: confirm the mapping table matches your design, confirm which bridge is root, then confirm roles and link type. If a port shows Shr instead of P2p, the fast handshake is not running on it and convergence will be slow. show spanning-tree mst configuration digest prints the MD5 digest so you can compare it character-by-character between two switches that refuse to form a region.

Migration and Interop Rules

• Migrate core first, then distribution, then access — changing STP type reconfigures the tree and can disrupt traffic.
• If the MST region meets a PVST+ cloud over a trunk, one side must be the root for all VLANs; the PVST+ simulation fails (root inconsistent) otherwise.
• PortFast, BPDU guard, root guard and loop guard keep working in MST mode.
• Change the revision and mapping only in a maintenance window; a mapping change alters forwarding paths for every mapped VLAN at once.
• Keep the same region configuration on switches that are added later — a new switch with default settings forms its own region and instantly becomes a boundary.

Edge protections apply identically in every mode — see PortFast, BPDU guard and root guard — and if you are still fighting Layer 2 loops, our LLDP vs CDP guide helps confirm what your neighbors actually are.

A Phased Migration Plan

1. Baseline. Record show spanning-tree root and show spanning-tree summary on every switch. You cannot prove a migration was safe without a before picture.
2. Decide the instance plan. Group VLANs by the forwarding path you want, not by department names. Two or three instances cover most designs.
3. Configure the mapping everywhere, still in rapid-PVST+. On Cisco you can pre-stage the MST configuration while running rapid-PVST+, then flip the mode one switch at a time.
4. Flip core switches to spanning-tree mode mst in a window, starting closest to the root. Expect a brief reconvergence as the region forms.
5. Flip distribution, then access. Each flip briefly re-elects the CIST root for the switches behind it.
6. Verify mapping, digest, roles and root for every instance; then set per-instance priorities to match your design.

Common Pitfalls

• Region split by a typo. The number one cause of "MST behaves oddly": different names, revisions or mappings across the same L2 domain.
• Forgetting unmapped VLANs. They land in instance 0 and inherit the CIST topology, which may be the opposite of what you intended for that traffic.
• Assuming instances are free. Each instance is a full RSTP state machine; dozens of them on an access stack re-introduce the CPU load MST was meant to remove.
• Mixing MST and PVST+ without a single root. The PVST+ simulation needs one side to own all VLANs; otherwise you get root-inconsistent ports and black-holed traffic.

If you need the exact per-switch mapping syntax and verification, see our walkthrough of Cisco MST region, instance and VLAN mapping configuration. For load-balancing design rules and how the root is chosen in the first place, read spanning tree root bridge election and design rules. When a migration goes wrong, the symptom-by-symptom flow in troubleshooting STP issues on Catalyst switches is the fastest way back. And if you are deciding whether to keep STP at all, spine-leaf versus three-tier STP blocking explains why modern leaf-spine fabrics route instead of block.

FAQ

Is MSTP faster than RSTP? No — both use the same RSTP state machines and handshake. MSTP converges about as fast as RSTP while maintaining fewer instances. It is a scaling improvement, not a speed improvement.

Can I run MST with less than three instances? Yes. Many production networks run a single instance (pure 802.1s with no load balancing) purely to collapse hundreds of per-VLAN BPDUs into one. Others use two or three for uplink utilisation.

What happens to VLAN 1 in MST? Unless you explicitly map it, VLAN 1 stays in instance 0, the CIST. On Cisco, the native VLAN on a trunk should also be left in instance 0 to avoid tagging surprises.

Do I need the same region name on switches separated by a routed link? No. The region is a Layer 2 domain concept; routed links terminate the spanning tree entirely.

How do I reset a mapping mistake? Fix the mapping on the offending switch, increment the revision if you want the change to be unambiguous, then re-verify the digest on both sides before trusting the topology.

原文链接：https://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/24248-147.html