Escolar Documentos
Profissional Documentos
Cultura Documentos
Understanding MSTP
MSTP
22 Understanding
Posted by Petr Lapukhov, 4xCCIE/CCDE in Switching
Feb
75 Comments
Introduction
Over time I was thinking of putting together the two blog posts made in the past about MSTP and adding
more clarification for MSTP multi-region section. This new blog post recaps the information posted previously and
provides more details this time. Additionally, it discusses some MSTP design-related questions. Both single-region
and multiple-region MSTP configurations are reviewed in the post. The reader is assumed to have good
understanding of classic STP and RSTP protocols as well as Ciscos PVST/PVST+ implementations.
Table of Contents
Due to the large size of the document, a table of contents is provided for the ease of navigation.
Historical Review
Logical and Physical Topologies
Implementing MSTP
Caveats in MSTP Design
MSTP Single-Region Configuration Example
Common and Internal Spanning Tree (CIST)
Common Spanning Tree (CST)
Mapping MSTIs to CIST
MSTP Multi Region Design Considerations
Interoperating with PVST+
Scenario 1: CIST Root and CIST Regional Root
Scenario 2: MSTIs and the Master Port
Scenario 3: PVST+ and MSTP Interoperation
Conclusions
Further Reading
Historical Review
In the beginning, there was IEEE STP protocol, which was preceded by DEC and IBM STP variants. All of them
utilized the same logic originally proposed by Radia Perlman in 80s, while she was working in DEC. The IEEE version
was adapted for use with multiple VLANs using 802.1q frames tagging. A shared spanning-tree, sometimes called
Mono Spanning Tree (MST) by Cisco, or more often Common Spanning Tree (CST) was used to create a single
loop-free topology. The drawback of this approach is inability to perform VLAN traffic engineering across redundant
links: if a link is blocked, it is blocked for all VLANs. Another issue related to STP construction more traffic is
forwarded over the links closer to the root bridge, which puts higher demand on the root bridge resources both in
terms of CPU and links capacity utilization.
To overcome these limitations, Cisco introduced proprietary Per-VLAN Spanning Tree Protocol (PVST), using
separate STP instance per VLAN. Initially, PVST was created to be used with Ciscos proprietary ISL encapsulation
only, but the later PVST+ version allowed for tunneling PVST BPDUs over 802.1q trunks and IEEE STP domains.
PVST allowed for using different logical topology with every VLAN, enhancing basic Layer 2 traffic engineering. Every
VLAN may use its own root bridge and forwarding topology allowing for more fair resource utilization. This method
has some limitation as it does not deal with the actual network link capacities and utilization, but rather statistically
multiplexes VLANS to different topologies. However, this is the limitation inherent to any load-balancing method based
on STP. The main problem of PVST was that with the number of VLANs growing, PVST becomes a waste of switch
resources and management burden. This is because the number of different logical topologies is usually much
smaller than the number of active VLANs.
blog.ine.com/2010/02/22/understanding-mstp/
1/20
4/7/14
Understanding MSTP
With time, PVST adopted fast-convergence properties introduced by IEEE RSTP protocol, but the core feature of
keeping a separate copy of STP per VLAN did not change. Seeing the problems associated with PVST approach,
Cisco came with idea of decoupling the concepts of STP instances and VLANs. The initial implementation was called
MISTP (Multiple Instances Spanning Tree) and later evolved into IEEE 802.1s standard called MSTP (Multiple
Spanning Trees Protocol).
Instead of running an STP instance for every VLAN, MSTP runs a number of VLAN-independent STP instances
(representing logical topologies) and then administrator maps each VLAN to the most appropriate logical topology
(STP instance). The number of STP instances is kept to minimum (saving switch resources), but the network capacity
is utilized in more optimal fashion, by using all possible paths for VLAN traffic.
The switch logic for VLAN traffic forwarding has changed a little bit. In order for a frame to be forwarded out of a port,
two conditions must be met: first, VLAN must be active on this port (e.g. not filtered) and second, the STP instance
the VLAN maps to, must be in non-discarding state for this port. The second property is normally enforced
automatically, as MAC addresses are not learned on discarding ports. It is worth reminding that due to multiple logical
topologies active on a port, the port could be blocking for one instance and forwarding for another (note that in
(R)PVST+ a port is either forwarding or discarding for a VLAN). The figure below demonstrates six VLANs using two
MSTP instances, thus reducing the number of STP trees that would be required with PVST from 6 to 2.
blog.ine.com/2010/02/22/understanding-mstp/
2/20
4/7/14
Understanding MSTP
Implementing MSTP
The following is a set of implementation-related questions that a theoretical implementation needs to address:
Logical Topology Calculation. How to build multiple STP instances (logical topologies) in a single physical
topology? Should we run multiple STP instances sending their BPDUs independently? If yes, then how would
we distinguish every instances BPDUs? VLAN tags cannot be utilized for that purpose, as STPs are no bound
to VLANs anymore.
Information Distribution. What protocol should be used to distribute VLAN to instance mapping tables
among switches? Should VLAN IDs be placed in BPDUs along with respective instance numbers?
Consistency Check. How to ensure the VLANs to instance mapping is consistent across all switches? That
is, how would a switch know that another switch maps VLAN X to the same instance?
MISTP vs MSTP
Original Cisco MISTP pre-standard implementation was sending separate BPDUs for each instance. Every BDPU
contained instance number and a list of VLANs, mapped on sending switch to this particular instance that allowed
for consistency check between the switches. The table mapping VLANs to instance numbers has to be configured on
each switch separately. There was no automated mechanism to distribution VLAN to instance mappings between the
switches.
The final implementation adopted by the IEEE 802.1s standard made this mechanics more elegant and simple.
Before we process with discussing IEEEs implementation, lets define MSTP region as a collection of switches,
sharing the same view of physical topology partitioning into set of logical topologies. For two switches to become
members of the same region, the following attributes must match:
Configuration name.
Configuration revision number (16 bit value).
The table of 4096 elements that map the respective VLANs to STP instance numbers.
The IEEE 802.1s implementation does not send BDPUs for every active STP instance separately, nor does it
encapsulate VLAN numbers list configuration messages. Instead, a special STP instance number 0 called Internal
Spanning Tree (IST aka MSTI0, Multiple Spanning Tree Instance 0) is designated to carry all STP-related
information. The BPDUs for IST contain all standard RSTP-style information for the IST itself, as well as carry
additional informational fields. Among those fields are configuration name, revision number and a hash
valuecalculated over VLANs to MSTI mapping table contents. Using just this condensed information switches may
detect mis-configuration in VLAN mappings by comparing the hash value received from the peer with the local value.
M-Records
blog.ine.com/2010/02/22/understanding-mstp/
3/20
4/7/14
Understanding MSTP
By default, all VLANs are mapped to the IST. This represents the case of classic IEEE RSTP with all VLANs sharing
the same spanning-tree. Other MSTP instances could be enabled, and they are referred to as Multiple Spanning
Tree Instances (MSTIs). Every MSTI assign its own priorities to the switches and use its own link costs to come up
with a private logical topology, separate from the IST. Since MSTP does not send MSTIs information in separate
BPDUs, this information is piggybacked into the ISTs BPDUs using special M-Record fields (one for every active
MSTI). Using TLVs (Type-Length-Value) those fields carry root priority, designated bridge priority, port priority and
root path cost among others.
STP Dispute
Cisco switches has long time been implementing LoopGuard feature that allows for blocking the non-designated port
when it loses the flow of STP BPDUs. This is helpful for detecting unidirectional link (normally on fiber optical links)
and preventing Layer 2 loops that could go undetected by STP. Ciscos implementation of MSTP allows for detecting
unidirection condition, by comparing the downstream port state reported in BPDUs. If the upstream switch sends
superior root bridge information to the downstream bridge but receives the BPDUs with Designated bit set, the
upstream switch concludes that the downstream does not hear its BPDUs. The upstream switch then blocks the
downstream port and marks it as STP dispute link.
blog.ine.com/2010/02/22/understanding-mstp/
4/20
4/7/14
Understanding MSTP
In this topology, VLANs are manually pruned on trunks. Since the filtering is not consistent with the respective MSTI
blocking decisions, VLAN2s traffic is blocked between SW1 and SW2. To avoid this situation, do not use static VLAN
pruning method of distributing VLANs across trunks when you have MSTP enabled. A situation equivalent to the one
described is when ports connecting the switches are access ports. MSTP runs on these ports and have logical
topologies either blocking or forwarding on the ports. Depending on VLANs to MSTI mapping, a given VLAN could be
blocked on the access ports due to MSTP decision even though the access VLANs are different, they use the same
STP. To avoid this problem, do not run MSTP on access-ports and use them for connecting stub devices only
e.g. hosts and leaf switches.
The topology has the following VLANs: 1, 10, 20, 30, 40, 50, 60. Our goals for this scenario are:
Make VLANs 10,20,30 follow the link from SW3 to SW1.
Make VLANs 40,50,60 follow the link from SW3 to SW2.
If any of the above links fail, the affectred VLANs should fall-back to the other link.
To accomplish this, we create two MSTIs number 1 and 2. SW1 will be the root for instance 1 and SW2 will be the
root for instance 2. As for the IST (MSTI0), we make SW3 the root switch for it (though its not recommended to
assign root roles to access switches). As for VLAN to MSTI mappings, VLAN 1 will remain mapped to the IST.
Remaining VLANs 10, 20 and 30 would map MSTI1, while VLANs 40, 50 and 60 would map to MSTI2. Here is the
blog.ine.com/2010/02/22/understanding-mstp/
5/20
4/7/14
Understanding MSTP
configuration:
SW1:spanning-tree mode mst!spanning-tree mst configuration name REGION1 instance 1 vlan 10, 20, 30
instance 2 vlan 40, 50, 60!! Root for MSTI1!spanning-tree mst 1 priority 8192!interface
FastEthernet0/13 switchport trunk encapsulation dot1q switchport mode trunk!interface FastEthernet0/16
switchport trunk encapsulation dot1q switchport mode trunkSW2:spanning-tree mode mst!spanning-tree mst
configuration name REGION1 instance 1 vlan 10, 20, 30 instance 2 vlan 40, 50, 60!! Root for MSTI
2!spanning-tree mst 2 priority 8192!interface FastEthernet0/13 switchport trunk encapsulation dot1q
switchport mode trunk!interface FastEthernet0/16 switchport trunk encapsulation dot1q switchport mode
trunkSW3:spanning-tree mode mst!spanning-tree mst configuration name REGION1 instance 1 vlan 10, 20,
30 instance 2 vlan 40, 50, 60!! Root for the IST!spanning-tree mst 0 priority 8192!interface
FastEthernet0/13 switchport trunk encapsulation dot1q switchport mode trunk!interface FastEthernet0/16
switchport trunk encapsulation dot1q switchport mode trunk
The following show commands will demonstrate the effect our configuration has on traffic forwarding:
[REGION1]Revision 0
Instances configured
1-9,11-19,21-29,31-39,41-49,51-59,61-40941
10,20,302
40,50,60--------------
vlans mapped:
0019.5684.3700 priority
1-9,11-19,21-29,31-39,41-49,51-59,61-4094Bridge
32768 (32768 sysid 0)Root
port
0012.d939.3700 priority
200000
Cost
internal cost
hello time 2 , forward delay 15, max age 20, max hops
20Interface
Role Sts
128.15
128.18
128.18
40,50,60Bridge
128.15
cost
200000
this
port
6Configured
Fa0/16
address
128.15
P2pFa0/16
128.18
filter: disable
(default)Boundary : internal
61-40941
128.15
----------------------------0
Desg FWD 200000
1-9,11-19,21128.15
port guard :
(default)
(default)Boundary : internal
128.15
bpdu
Prio.Nbr Vlans mapped-------- ---- --- --------- -------- --Root FWD 200000
128.18
10,20,302
128.18
1-9,11-19,21-29,31-39,41-49,51-59
128.18
40,50,60
The link cost values are much higher than the default STP costs (IEEE standard values), and MSTIx is called MSTx
(e.g. IST is MST0). Aside from that, note the term Regional Root which is to be explained in details below.
blog.ine.com/2010/02/22/understanding-mstp/
6/20
4/7/14
Understanding MSTP
When multiple regions connect together, every region needs to construct its own IST and all regions should build one
common CIST spanning across the regions. To see how this is accomplished, first have a look at the structure of
MSTP BPDU. On the figure below, notice MSTP uses protocol version 3 as opposed to RSTPs version 2. Version 4
is reserved to SPT Shortest Path Tree new loop prevention and packet bridging standard defined in emerging
IEEE 802.1aq document.
blog.ine.com/2010/02/22/understanding-mstp/
7/20
4/7/14
Understanding MSTP
The MSTP BPDU contains two important block of information. One, highlighted in red, is related to CIST Root and
CIST Regional Root election. As you will see later, CIST Root is elected among all regions and CIST Regional Root is
elected in every region. The green block outlines the information about CIST Regional Root (which becomes the IST
Root in presence of multiple regions). The CIST Internal Root path cost is the intra-region cost to reach the CIST
Regional Root. It is important to keep in mind that IST Root = CIST Regional Root in case where multiple regions
interoperate. This transformation is explained further in the text. Now, to define the CIST Root and CIST Regional
Root roles:
CIST Root is the bridge that has the lowest Bridge ID among ALL regions. This could be a bridge inside a
region or a boundary switch in a region.
CIST Regional Root is a boundary switch elected for every region based on the shortest external path cost
to reach the CIST Root. Path cost is calculated based on costs of the links connecting the
regions,excluding the internal regional paths. CIST Regional Root becomes the root of the IST for the given
region as well.
8/20
4/7/14
Understanding MSTP
blog.ine.com/2010/02/22/understanding-mstp/
9/20
4/7/14
Understanding MSTP
CST is the construct where MSTP interoperates with the IEEE STP/RSTP regions as well. The legacy switch regions
join their STP instance with the CST and perceive MSTP regions as transparent virtual bridges, staying unaware of
their internal topology. Thus, connecting to IEEE STP/RSTP domains extended the CST. MSTP discovers the
appropriate STP version on a boundary link by listening to external and switches to the respective mode of
operations (e.g. RSTP/STP). It may happen so that a switch with the lowest Bridge ID belongs to a RSTP/STP region.
This situation results in all MSTP regions electing local CIST Regional Roots and considering the new CIST Root
located outside MSTP domain.
The second level of CIST hierarchy consists of the various MSTP regional ISTs. Every MSTP region builds IST
instance using the internal path costs and following the optimal internal topology, using the CIST Regional Root as
the IST Root. The changes to CST may affect the ISTs in every region, as those changes may result in re-electing of
the new CIST Regional Roots. Changes to the regions internal topologies normally do not affect the CST, unless
those changes partition the region.
10/20
4/7/14
Understanding MSTP
Ethernet is known for its broadcast nature that tends propagating faults across the whole Layer 2 domain. There are
tree main problems with Ethernet that affect MSTP designs:
Unknown unicast flooding results in traffic surges under topology changes. Those are either result of
asymmetric routing or persistent topology changes. Every topology change causes massive invalidation of
MAC address tables and unicast traffic flooding. This process is the result of Ethernet topology unawareness
the bridges dont know MAC addresses location.
Broadcast and Multicast flooding. This is a separate problem as many core protocols (ARP, IGP, PIM) rely on
multicasting or broadcasting. Those packets should be delivered to every node in a broadcast domain and
under intense load network could be congested at every point.
Spanning-Tree Convergence. MSTP uses RSTP procedure for STP re-negotiation. Since it is based on
distance-vector behavior, it is prone to some convergence issues, such as counting to infinity (old information
circulation). This is especially noticeable in larger topologies with 10+ switches and under special conditions,
such as failure of the root bridge.
The concept of MSTP region allows for bounding STP re-computations. Since MSTIs in every region are
independent, any change affecting MSTI in one region will not affect MSTIs in other regions. This is a direct result of
the fact that M-Record information is not exchanged between the regions. However, the CIST recalculations affect
every region and might be slow converging. This is why it is a good idea not to map any VLAN to CIST and avoid
connecting MSTP regions to IEEE STP domains.
Topology changes in MSTP are treated the same way as in RSTP. That is, only non-edge links going to forwarding
state will cause a topology change and the switch detecting the change will flood this information through the domain.
However, single physical link may be forwarding for one MSTI and blocking for another. Thus, a single physical
change may have different effect on MSTIs and the CIST. Topology changes in MSTIs are bounded to a single
region, while topology changes to the CIST propagate through all regions. Every region treats the TC notification
from another region as external and applies them to CIST-associated ports only.
A topology change to CST (the tree connecting the virtual bridges) will affect all MSTIs in all regions and the CIST.
This is due to the fact that new link becoming forwarding between the virtual bridges may change all paths in the
topology and thus require massive MAC address re-learning. Thus, from the standpoint of topology change,
something happening to the CST will have most massive impact of flooding in the set of interconnected MSTP
regions.
The above observations advise a good design rule for MSTP networks separate meshy topologies in their own
regions and interconnect regions using sparse mesh, keeping in mind balance between redundancy and topology
changes effect. This is an adaptation of well-know design principle separate complexity from complexity to keep
networks more stable and isolate fault domains. In addition, exposing a lot of links to CST will reduce your loadbalancing choices, as CST supports only one STP instance. You want to avoid designs like the one diagrammed
below, which effectively disabled load balancing on the mesh of links that belong to CST. The reason is that now the
full-mesh of links belongs on CST and it elects only one unblocked path between the two regions.
blog.ine.com/2010/02/22/understanding-mstp/
11/20
4/7/14
Understanding MSTP
Even though region partitioning offers better fault isolation it still does not eliminate well-known Ethernet issues such
as unicast and broadcast flooding. Those may still occur and disrupt network connectivity. For example, unicast
flooding could be caused by unidirectional traffic and broadcast flooding may be a result of transient bridging loops
when a root bridge fails. Transient bridging loops are reality with RSTP/MSTP especially in larger topologies due to
various synchronization problems resulting in count to infinity behavior. This problem is especially dangerous when a
root bridge crashes and the remaining topology contains loops old information may circulate until its aged out using
hop counting (counting to infinity).
12/20
4/7/14
Understanding MSTP
MSTP domain (either a single region or multiple regions) contains the root bridge for ALL VLANs. This means
the CIST Root Bridge ID is better than any PVST+ STP root Bridge ID. If there is only one MSTP region
connecting to PVST+ domain, then all boundary ports on the virtual-bridge will be unblocked and could be
used by PVST+ trees. This is the preferred design, as administrator can manipulate uplink costs on the
PVST+ side and obtain optimal traffic engineering results. On the figure below, VLANs 2 and 3 have their STP
costs adjusted so that they select different uplinks connected to MSTP regions boundary ports. Since the
CIST Root is inside the MSTP region, both boundary ports are non-blocking designated and thus the load
balancing scheme works fine.
PVST+ domain contains the root bridges for ALL VLANs. This is only true is all PVST+ root bridges Bridge IDs
for all VLANs are better than the MSTP CIST Root Bridge ID. This is not the preferred design, since all MSTIs
map to CIST on the border link, and you cannot load-balance the MSTIs as they enter the PVST+ domain.
Cisco implementation does not support the second option. MSTP domain should contain the bridge with the best
Bridge ID, to ensure that the CIST Root is also the root for all PVST+ trees. In any other case, the MSTP border
switch will complain and place the ports that receive superior BPDUs from PVST+ region in root-inconsistent state. To
fix this issue, ensure that PVST+ domain does not have any bridges with Bridge IDs better than the CIST Root Bridge
ID.
And lastly a few words on MSTP and PVST interoperations. The operate in exactly the same manner and follow the
same rules as PVST+ interoperation, just ISL is used for trunking encapsulation.
blog.ine.com/2010/02/22/understanding-mstp/
13/20
4/7/14
Understanding MSTP
SW1:spanning-tree mode mst!! Minimum Priority among all bridges!spanning-tree mst 0 priority
4096!spanning-tree mst configuration name REGION1 exitSW2:spanning-tree mode mstspanning-tree mst
configuration name REGION234 exit!! SW2 priority is less than SW4s, but it has better cost to CIST
Root!spanning-tree mst 0 priority 16384!! This is the active boundary port!interface FastEthernet 0/13
spanning-tree mst 0 cost 50!interface FastEthernet 0/14 spanning-tree mst 0 cost 200!interface
FastEthernet 0/16 spanning-tree mst 0 cost 100SW3:spanning-tree mode mstspanning-tree mst
configuration name REGION234 exit!interface FastEthernet 0/16 spanning-tree mst 0 cost 100!interface
FastEthernet 0/19 spanning-tree mst 0 cost 10SW4:spanning-tree mode mstspanning-tree mst configuration
name REGION234 exit!! SW4 has better IST priority but higher cost to the CIST Root!spanning-tree mst 0
priority 8192!interface FastEthernet 0/13 spanning-tree mst 0 cost 100!interface FastEthernet 0/16
spanning-tree mst 0 cost 10!interface FastEthernet 0/19 spanning-tree mst 0 cost 10
vlans mapped:
20Interface
----- --------------------------------Fa0/13
Desg FWD 200000
128.16
P2pFa0/19
1-4094Bridge
address 0019.55e6.6800
hello time 2 ,
128.21
128.15
P2pFa0/14
P2p
SW1 says it is the CIST Root Bridge and all of its ports are unblocked (designated). The bridge priority is set to 4096
this will allow us to distinguish this switch in the show outputs below. The ports are not marked as boundary, since
SW1 is not receiving any BPDUs on these ports all downstream ports suppress sending their own BPDUs since
blog.ine.com/2010/02/22/understanding-mstp/
14/20
4/7/14
Understanding MSTP
SW1 is the root bridge. You may confirm this using the following debugging commands:
SW1#debug spanning-tree mstp bpdu receive MSTP BPDUs RECEIVEd dump debugging is onSW1#
Next try dumping the BPDUs being sent by SW1. Notice that they all have Mum_mrec set to zero which means zero
M-records. SW1 claims itself as the CIST Root and CIST Regional root on all ports. The cost to both roots is set to
zero.
SW1#debug spanning-tree mstp bpdu transmit MSTP BPDUs TRANSMITted dump debugging is onMST[0]:-TX
Fa0/13 BPDU Prot:0 Vers:3 Type:2MST[0]:
CIST_root: 4096.0019.55e6.d380 Cost
Role
:0MST[0]:
:0llMST[0]:
:0MST[0]:
V3_len:64
Role
:0MST[0]:
: Desg
Reg_root :
Role
:0MST[0]:
4096.0019.55e6.d380 Port_ID:32789MST[0]:
:0MST[0]:
CIST_root:
Bridge_ID:
V3_len:64
vlans mapped:
sysid 0)
port
1-4094Bridge
Fa0/13
path cost
20Interface
P2pFa0/19
128.16
P2p Bound(RSTP)Fa0/16
128.21
4096 (4096
hello time 2 , forward delay 15, max age 20, txholdcount 6Configured
15, max age 20, max hops
address 001b.8f0c.2a00
128.15
P2p
Desg FWD 10
P2p
SW2 is the CIST Regional Root Bridge (CIST Root) with the priority value of 16384. SW2 learns that SW1 is the CIST
Root with the priority value of 4096. The boundary root port is Fa 0/13, elected based on regular STP rules (shortest
path, lowest upstream port priority). The other boundary uplink is blocking. Both ports show up as Boundary since
they face the other MSTP domain. Of course, SW2 is the Regional Root due to the fact that is has the shortest path
to the CIST Root. Dump the BPDUs being sent by SW2:
SW2#debug spanning-tree mstp bpdu transmit MSTP BPDUs TRANSMITted dump debugging is onMST[0]:-TX
Fa0/16 BPDU Prot:0 Vers:3 Type:2MST[0]:
CIST_root: 4096.0019.55e6.d380 Cost
Role
:50MST[0]:
Bridge_ID:16384.0019.564c.c580 Port_ID:32786MST[0]:
:0MST[0]:
V3_len:64
Role
:16384.0019.564c.c580 Cost
Bridge_ID:16384.0019.564c.c580 Port_ID:32789MST[0]:
:0MST[0]:
:50MST[0]:
Reg_root
SW2 only sends BPDUs out of its designated ports that are Fa 0/16 and Fa 0/19. The output also signifies that SW2
announces SW1 as the CIST Root and itself as the regional root. Notice the CIST External Root Path Cost and the
CIST Regional Root Cost. Now, check the MSTI0 statistics on SW3:
blog.ine.com/2010/02/22/understanding-mstp/
15/20
4/7/14
Understanding MSTP
vlans mapped:
sysid 0)
port
priority
hops 18Operational
1-4094Bridge
address 000c.85be.c680
Fa0/19
path cost
4096 (4096
hello time 2 , forward delay 15, max age 20, txholdcount 6Configured
20Interface
rem
hello
Prio.Nbr
128.16
P2pFa0/19
Root FWD 10
128.19
Altn
P2p
SW3 sees SW1 as the CIST Root and SW2 as the CIST Regional Root. Since SW2 is also the root for IST, SW3
needs to select the root port to reach it. It selects the link via SW4 as our cost manipulations made this path more
preferred. The internal cost to reach the CIST Regional root is 10+10=20. The CIST External Root Path Cost is 50,
as it is not incremented when transported from SW2.
vlans mapped:
sysid 0)
port
priority
hops 19Operational
1-4094Bridge
address 000d.2840.ab00
Fa0/16
path cost
4096 (4096
hello time 2 , forward delay 15, max age 20, txholdcount 6Configured
20Interface
rem
hello
Prio.Nbr
128.13
Desg FWD 10
P2p Bound(RSTP)Fa0/16
128.19
Root FWD 10
128.16
Altn
P2pFa0/19
P2p
SW4 has lower bridge priority than SW2, but it is not elected as the CIST Regional Root, for SW4 path cost to the
CIST Root is worse. Notice the External and Internal root path costs values 50 and 10 respectively. Pay attention to
the fact that SW4s port Fa 0/13 is marked as alternate and blocking while the root port toward the CIST Regional
Root is unblocked.
SW1:vlan 10,20SW2, SW3 & SW4:vlan 10,20!spanning-tree mst configuration instance 1 vlan 10, 20
We are concerned with the show commands for new MSTI 1 in REGION 234. Notice that we didnt do any path
manipulations and simply mapped the new VLANs to MSTI 1. It was not even necessary creating new VLANs, the
configuration would work without VLANs every existing as MSTIs are separated from the VLANs.
vlans mapped:
10,20Bridge
address 001b.8f0c.2a00
128.15
P2p Bound(RSTP)Fa0/14
Desg FWD 200000
128.18
128.16
P2p
128.21
P2p
There is no Regional Root for MSTI1. Just regular root, which is the root of MSTI, elected using the regular STP
rules. In our case, the root is SW4 and the root port is Fa 0/19. Next note the special Master Port. This is the uplink
port of CIST Regional Root. All MSTIs map to CIST here, and follow the single path. This port is also forwarding and
blog.ine.com/2010/02/22/understanding-mstp/
16/20
4/7/14
Understanding MSTP
provides the path upstream to the CIST Root for all MSTIs and their mapped VLANs. It is interesting to dump the
MSTP BPDUs sent and received by SW2:
SW2#debug spanning-tree mstp bpdu receive MSTP BPDUs RECEIVEd dump debugging is onMST[0]: RX- Fa0/13
repeated designated BPDU Prot:0 Vers:3 Type:2MST[0]:
RemHops:20MST[0]:
Cost
:0MST[0]:
fwdelay:15MST[0]:
Role
:0MST[0]:
Reg_root : 4096.0019.55e6.d380
max_age:20 hello:2
Role
:0MST[0]:
4096.0019.55e6.d380 Port_ID:32784MST[0]:
:0MST[0]:
CIST_root:
Bridge_ID:
V3_len:64
Nothing special in received BPDUs, only SW1 claiming itself as the CIST Root/CIST Regional Root. Look at the
BPDUs that SW2 is sending though:
SW2#debug spanning-tree mstp bpdu transmitMSTP BPDUs TRANSMITted dump debugging is onMST[0]:-TX Fa0/16
BPDU Prot:0 Vers:3 Type:2MST[0]:
4096.0019.55e6.d380 Cost
Role
:50MST[0]:
Bridge_ID:16384.0019.564c.c580 Port_ID:32786MST[0]:
Cost
:0MST[0]:
fwdelay:15MST[0]:
Role
:0MST[1]:
CIST_root:
:0MST[0]:
V3_len:80
: Desg Flags[AFL]
Bridge_ID:16385.0019.564c.c580
Role
:50MST[0]:
Reg_root :16384.0019.564c.c580
Bridge_ID:16384.0019.564c.c580 Port_ID:32789MST[0]:
max_age:20 hello:2
Role
:0MST[1]:
Bridge_ID:16385.0019.564c.c580 Port_id:149
The output now shows one M-Record attached to the IST BPDU. This M-Record specifies SW2 as the root bridge for
IST1 you can tell that by looking at the Cost field.
%SPANTREE-2-PVSTSIM_FAIL: Superior PVST BPDU received on VLAN 5 SW2#show spanning-tree mst 0##### MST0
vlans mapped:
1-9,11-19,21-4094Bridge
sysid 0)Root
Fa0/13
20Interface
--------------------------Fa0/13
Desg BKN*200
Bound(RSTP)Fa0/19
128.16
port
hello time 2 , forward delay 15, max age 20, max hops
128.15
blog.ine.com/2010/02/22/understanding-mstp/
16384 (16384
128.21
P2p Bound(PVST)Fa0/14
Root FWD 100
128.18
P2p
P2p Bound(RSTP)
17/20
4/7/14
Understanding MSTP
Notice the syslog message in the beginning. It says that while emulating PVST+ operation the MSTP code
encountered the situation where PVST+ domain claims itself as a root for one or more VLANs. That is, the PVST+
Bridge has better BID than the current CIST Root. As a result, even though the MSTP considers the new root as the
legitimate new CIST Root, it blocks the uplink port as PVST Simulation Inconsistent. It is interesting to notice that
SW1 is still considered to be the CIST Root and SW2 is the CIST Regional Root but all ports to the CIST Root are
blocking! Check the flow of BPDUs received from SW1. The first is the VLAN 1 BPDUs perceived on SW2 as IEEE
STP BPDUs. They claim SW1 as the Root Bridge you may see extended system ID carrying the VLAN number of 1.
SW2#debug spanning-tree mstp bpdu receiveMSTP BPDUs RECEIVEd dump debugging is onMST[0]: RX- Fa0/13
repeated designated BPDU Prot:0 Vers:0 Type:0MST[0]:
1.0019.55e6.d380 Cost
:0MST[0]:
Bridge_ID:
Flags[] Age:0MST[0]:
CIST_root:
1.0019.55e6.d380 Port_ID:32783MST[0]:
max_age:20
hello:2 fwdelay:15MST[0]: RX- Fa0/14 repeated designated BPDU Prot:0 Vers:2 Type:2MST[0]:
Desg Flags[FL] Age:0MST[0]:
CIST_root:
1.0019.55e6.d380 Port_ID:32784MST[0]:
1.0019.55e6.d380 Cost
:0MST[0]:
Role
Bridge_ID:
There are other BPDUs received on SW2 due to the fact that 802.1Q is the trunking encapsulation SW2 receives
PVST+ BPDUs for VLANs 10 and 20:
SW2#debug spanning-tree bpdu receive Spanning Tree BPDU Received debugging is onSTP: MST0 rx BPDU:
config protocol = mstp, packet from FastEthernet0/13 , linktype IEEE_SPANNING , enctype 2, encsize
17STP: enc 01 80 C2 00 00 00 00 19 55 E6 D3 8F 00 26 42 42 03STP: Data
00000000010001001955E6D380000000000001001955E6D380800F0000140002000F00STP: MST0 Fa0/13:0000 00 00 01
0001001955E6D380 00000000 0001001955E6D380 800F 0000 1400 0200 0F00STP: MST0 rx BPDU: config protocol
= mstp, packet from FastEthernet0/14 , linktype IEEE_SPANNING , enctype 2, encsize 17STP: enc 01 80
C2 00 00 00 00 19 55 E6 D3 90 00 27 42 42 03STP: Data
000002021E0001001955E6D380000000000001001955E6D38080100000140002000F00STP: MST0 Fa0/14:0000 02 02 1E
0001001955E6D380 00000000 0001001955E6D380 8010 0000 1400 0200 0F00STP: MST0 rx BPDU: config protocol
= mstp, packet from FastEthernet0/13 , linktype SSTP , enctype 3, encsize 22STP: enc 01 00 0C CC CC
CD 00 19 55 E6 D3 8F 00 32 AA AA 03 00 00 0C 01 0BSTP: Data
0000000001000A001955E6D38000000000000A001955E6D380800F0000140002000F00STP: MST0 Fa0/13:0000 00 00 01
000A001955E6D380 00000000 000A001955E6D380 800F 0000 1400 0200 0F00STP: MST0 rx BPDU: config protocol
= mstp, packet from FastEthernet0/14 , linktype SSTP , enctype 3, encsize 22STP: enc 01 00 0C CC CC
CD 00 19 55 E6 D3 90 00 32 AA AA 03 00 00 0C 01 0BSTP: Data
000002021E000A001955E6D38000000000000A001955E6D38080100000140002000F00STP: MST0 Fa0/14:0000 02 02 1E
000A001955E6D380 00000000 000A001955E6D380 8010 0000 1400 0200 0F00STP: MST0 rx BPDU: config protocol
= mstp, packet from FastEthernet0/13 , linktype SSTP , enctype 3, encsize 22STP: enc 01 00 0C CC CC
CD 00 19 55 E6 D3 8F 00 32 AA AA 03 00 00 0C 01 0BSTP: Data
00000000010014001955E6D380000000000014001955E6D380800F0000140002000F00STP: MST0 Fa0/13:0000 00 00 01
0014001955E6D380 00000000 0014001955E6D380 800F 0000 1400 0200 0F00STP: MST0 rx BPDU: config protocol
= mstp, packet from FastEthernet0/14 , linktype SSTP , enctype 3, encsize 22STP: enc 01 00 0C CC CC
CD 00 19 55 E6 D3 90 00 32 AA AA 03 00 00 0C 01 0BSTP: Data
000002021E0014001955E6D380000000000014001955E6D38080100000140002000F00
The above output shows that both ports receive IEEE native STP BPDUs along with PVST+ SSTP BPDUs for VLAN
numbers 0xA (10) and 014 (20). Now check how MSTI1 sees the inconsistent port:
vlans mapped:
10,20Bridge
address 001b.8f0c.2a00
128.15
blog.ine.com/2010/02/22/understanding-mstp/
128.18
P2pFa0/19
128.16
P2p
128.21
18/20
4/7/14
Understanding MSTP
P2p
Here we see that the Master Port is blocked as well, due to the PSVT simulation inconsistency. To resolve this issue
you need to ensure that MSTP domain contains the root bridge for all PVST+ trees. This is accomplished by tuning
priority value for the CIST to a number lower than any PVST+ bridge priority.
Now SW2 is the new CIST Root. Look at the show command output again:
vlans mapped:
1-9,11-19,21-4094Bridge
hello time 2 , forward delay 15, max age 20, txholdcount 6Configured
15, max age 20, max hops
20Interface
address
Desg FWD 50
128.15
P2p
Bound(PVST) Fa0/14
128.16
128.18
128.21
P2pFa0/19
vlans mapped:
10,20Bridge
200000
200000
128.18
Hello Time
19
Fa0/19
128.15
Cost
port
Desg FWD 200000
128.16
128.21
Port
Address
0019.55e6.6800
P2p
Desg FWD
Priority
4096
Address
15 (FastEthernet0/13)
sys-id-ext 1)
cost
Hello Time
8193
(priority 8192
Prio.Nbr Type---
Root
FWD 19
128.15
P2pFa0/14
Altn
BLK 19
128.21
P2p
Altn BLK 19
128.16
P2pFa0/19
All SW2 ports are now designated. SW2 correctly emulates the PVST+ interactions, and SW1 sees SW2 as the root
of all PVST+ instances. SW1 will then block one of its redundant uplink based on the regular STP rules. In this
situation, traffic may flow between the PVST+ and MSTP domains and you can achieve optimal load-balancing using
the PSVT+ cost tuning on SW1.
Conclusions
MSTP was designed to overcome one major problem with classic STP protocol inability to use blocked links for
traffic forwarding due to single STP instance present. This is accomplished by running multiple spanning trees in a
topology and mapping VLANs to different trees for traffic forwarding. Even though this feature does not allow for
precise and optimal traffic engineering it improves redundant link utilization. By using regions, MSTP allows for
isolating different physical topologies from each other while maintaining Layer 2 connectivity between the regions.
However, even with improved fault isolation, MSTP still suffers from the problems inherent to Ethernet topology
uncast and broadcast flooding and slow spanning-tree convergence. This limits MSTP deployments to small Layer 2
domains, such as single access-distribution switch block. Larger MSTP deployments should be planned carefully and
require strict administrative control. As a suggestion, Private VLANs could be used for larger domains to minimize
traffic flooding.
blog.ine.com/2010/02/22/understanding-mstp/
19/20
4/7/14
Understanding MSTP
Further Reading
IEEE 802.1 Series Standards
MSTP Configuration Guide
RFC 5517: Cisco Systems Private VLANs
Tags: 802.1s, ccie.mstp, cist, cst, multiple spanning tree
Download this page as a PDF
About Petr Lapukhov, 4xCCIE/CCDE:
Petr Lapukhov's career in IT begain in 1988 with a focus on computer programming, and progressed into networking with his
first exposure to Novell NetWare in 1991. Initially involved with Kazan State University's campus network support and UNIX
system administration, he went through the path of becoming a networking consultant, taking part in many network
deployment projects. Petr currently has over 12 years of experience working in the Cisco networking field, and is the only
person in the world to have obtained four CCIEs in under two years, passing each on his first attempt. Petr is an exceptional
case in that he has been working with all of the technologies covered in his four CCIE tracks (R&S, Security, SP, and Voice) You
on a daily basis for many years. When not actively teaching classes, developing self-paced products, studying for the CCDE can leave
Practical & the CCIE Storage Lab Exam, and completing his PhD in Applied Mathematics.
Find all posts by Petr Lapukhov , 4xCCIE/CCDE | Visit Website
blog.ine.com/2010/02/22/understanding-mstp/
20/20