skip to content

Two MSTP switches share the same region name and VLAN-to-instance map yet act as separate regions; what is wrong, and what does the boundary do?

level: seniorimportance: nice to knowfreq 12%

answer

  1. three values define a region
  2. the number nobody watches
  3. a digest, not a list
  4. only one tree crosses
  5. boundary ports follow the CIST

basics

~20 s

An MSTP region needs a matching name, revision level and VLAN-to-instance digest, so a differing revision level is the usual culprit; at the boundary only the CIST crosses, and boundary ports forward or discard every VLAN together.

solid answer

~50 s

An MSTP region is defined by three values that must all match: the **region name**, the **revision level** and the **VLAN-to-instance map**, which bridges compare as a digest in their BPDUs. If the name and map really match, the **revision level** is the usual culprit; and because the digest covers the whole table, a map that differs in a VLAN nobody uses also splits the region. Each switch then forms its own region. Instances are confined to a region, so at the **boundary** only the **CIST** (the common and internal spanning tree, built from each region's instance 0) runs, and each region looks to the other like a single bridge. A boundary port's role and state for every instance follow its CIST role, so it forwards or discards **all** VLANs together. Per-instance load balancing collapses across the boundary and traffic can take long paths.

go deeper

for a junior

Recall that MSTP switches must agree on a region name, a revision level and a VLAN-to-instance map before they share instances.

for a middle

Explain why the map is compared as a digest of the whole table, and what the IST, the CST and the CIST each are.

for a senior

Diagnose a split region from its symptom, traffic taking a long path with no loop, and check the revision level and the advertised digest before the printed map.

for a principal

Own the change process: a region definition is shared state across every switch, so map edits need pre-planning, a single rollout and monitoring of the digest.

## How MSTP decides who is in a region **Multiple Spanning Tree Protocol (MSTP)**, IEEE 802.1s and now part of **IEEE 802.1Q**, groups VLANs into **instances** and runs one spanning tree per instance. Instances only make sense among switches that agree on which VLAN belongs to which instance, so MSTP defines a **region**: a set of connected switches that carry the same **MST configuration identifier**. Under the IEEE standard, that identifier has three parts, and **all three** must match: | Part | What it is | How it is compared | |---|---|---| | region name | an administrator-chosen text string | exact match | | revision level | an administrator-chosen number | exact match | | VLAN-to-instance map | which instance each VLAN ID belongs to | as a digest of the entire table, sent in every BPDU | Two consequences follow from the digest: - The map is compared **for every VLAN ID**, not only the VLANs in use. A VLAN mapped to instance 2 on one switch and left in instance 0 on another splits the region even if no port carries that VLAN. - An administrator reading two configurations side by side can easily miss a difference that the digest does not. ## Diagnosing the scenario Distribution switches **D1** and **D2** and access switch **S3** were configured as region `CAMPUS`, revision 3, with VLANs 1-100 in instance 1 (root D1) and VLANs 101-200 in instance 2 (root D2). After a change window, S3 behaves as a separate region although its name and map look identical. 1. Compare the **name**, including case and any trailing characters. 2. Compare the **revision level**. This is the classic culprit: someone edited S3, the procedure said to raise the revision, and S3 was the only switch that got the new number. 3. Compare the **digest** each switch advertises rather than the map as printed; it exposes differences in unused VLANs. 4. Fix the mismatch, and expect a brief reconvergence as S3 rejoins the region. ## What a region boundary does A **boundary port** connects a switch to a different region, or to a bridge running only RSTP or 802.1D. Across it: - **Instances do not cross.** Instance 1 and instance 2 exist only inside their region. - **Only the CIST crosses.** Inside a region, instance 0 is the **internal spanning tree (IST)**; joined with other regions and plain RSTP or 802.1D bridges through the **common spanning tree (CST)**, it forms the **common and internal spanning tree (CIST)**. - **A region looks like one bridge** to everything outside it, so the CST sees a few large virtual bridges rather than every switch. - **Boundary ports follow the CIST.** For every instance, a boundary port takes the role and state it has in the CIST, so it forwards or discards all VLANs at once. ## The symptom in the scenario With S3 in its own region, both of its uplinks are boundary ports. On the CIST, one uplink is root port and the other is alternate, and that decision now applies to **all 200 VLANs**: | VLANs | Intended uplink | Actual uplink after the split | |---|---|---| | 1-100 (instance 1) | toward D1 | the CIST root port | | 101-200 (instance 2) | toward D2 | the CIST root port, the same one | If the CIST root port is the uplink to D1, traffic for VLANs 101-200 reaches D1 and must cross the D1-D2 link to get to D2, loading a link the design meant to keep clear. Nothing is looping and nothing is down, which is why this failure is easy to miss. ## Avoiding it - Keep the region definition in one place and push it to every switch as a unit. - **Pre-map** planned VLAN ranges to instances before the VLANs exist, so creating a VLAN never requires a map edit. - Treat any map or revision change as a change to every switch in the region, rolled out together. - After any change, confirm that every switch reports the same region, and that boundary ports appear only where another region or a bridge without MSTP was expected. - Monitor the configuration digest, not only the name, when checking region membership.

  • How do you change the VLAN-to-instance map without splitting the region during the rollout?
    Any edit changes the digest, so until every switch carries the new map the edited ones form their own region and their boundary ports follow the CIST. Pre-mapping planned VLAN ranges avoids most edits; when one is needed, apply it to every switch in one maintenance window and expect a short reconvergence as they rejoin one region.
  • What is the IST, and how does it relate to the CIST?
    The IST is instance 0 inside an MSTP region and carries every VLAN not mapped to another instance. The CIST is that tree joined with other regions and with plain RSTP or 802.1D bridges through the common spanning tree, each region appearing as one virtual bridge. It is the only tree that crosses a region boundary.

saying these in an interview costs you the question

  • MSTP instances extend across region boundaries just as VLANs do.
  • Only the region name has to match for switches to share a region.
  • VLANs not in use are left out of the region comparison.
  • Raising the revision level on one switch is harmless bookkeeping.
  • Each MSTP instance sends its own BPDUs to neighbouring regions.