How MSTP works
Today we talk about MSTP. Before you deal with MSTP, you need to familiarize yourself with the STP and RSTP protocols . MSTP is a modification of RSTP, and therefore STP. If RSTP is the same STP, only with a more optimized sending of BPDUs and in general STP work, then why is it necessary to invent an MSTP that works based on RSTP? The main feature of MSTP is the ability to work with VLANs. Some readers may say - “Wait, but aren't Cisco pvst + and rpvst + able to work with vlans?” RPVST + and PVST + just launch autonomous instances of RSTP or STP in the limit of one vlan. But then there are problems:
All these problems are successfully solved by the multi-vendor protocol MSTP. We will try to deal with his work. The scheme for constructing a loopless topology in RSTP consists in plotting a graph without intersections, regardless of logical topologies, without taking into account where and how the vlans are configured. In MSTP, we get the opportunity to combine certain vlans into a group and for each group build a separate topology. For example, take a look at this topology: PCs play the role of network segments. PC1, PC3 is the network segment where Vlans from 10 to 50 are used, and PC2, PC4 are installed from 50 to 100. Vlana from 10 to 100 are created on the Sw1-4 switches themselves. If we use the RSTP protocol, then segments PC1 and PC2 get to segments PC3 and PC4 respectively, you need to use one common path, choosing it from two possible:
Sw1-Sw2-Sw4 or Sw1-Sw3-Sw4 . Unfortunately, it is impossible to build a scheme with load distribution and one of these paths will be blocked and empty. With the help of PVST + and RPVST +, this can be done, but there are their own problems mentioned above. MSTP comes to our aid in this matter, creating an RSTP instance for a group of Vlans 10-50 and 50-100. You can configure that the Root switch for Vlan 10-50 will be Sw3, and for 50-100 - Sw2. The path Sw1-Sw3-Sw4 will be used by Vlans 10-50, the path Sw1-Sw2-Sw4- Vlans 50-100. The idea is to create instances that will integrate Vlans and build an RSTP tree separately for each instance. Thus, by combining Vlans 10-50 and 51-100 in different instances, the MSTP protocol will allow building independent trees for each instance. The configuration will look like this:
In each region there is an instance of MSTI 0 (instance 0), which is created by default and it includes all the vlans that were not included in the other instances. Instance 0 is called IST:
Internal Spanning Tree (IST) —a special copy of the spanning tree, which, by default, exists in every MST region. IST is assigned the number 0 (Instance 0). It can send and receive BPDU frames and serves to manage the topology within the region. All VLANs configured on switches in a given MST region are tied to IST by default.
Root Bridge for IST is called Regional Root Bridge. It is through IST that the frames of BPDU are transmitted, through which a tree is set for each instance. Consider what BDPU looks like in this region:
Before the start of the MST Extension field, the BPDU MSTP is very difficult to separate from the RSTP BPDU and, roughly speaking, IST is the classic RSTP. MSTP only adds MSTI data. The BPDU stores information about the Root Bridge for Instance 0-2. Thus, for all vlans and authorities, only one BPDU is sent, which contains all the necessary information. This is a huge savings compared to PVST + and RPVST +. Let's see the output of the show spanning-tree mst command on the Sw2 switch: For instance 0 there is a special field - Regional Root. Regional Root we chose Sw3 using the spanning-tree mst 0 root primary command
. Regional Root is the root switch for MSTI 0 within one region. For MSTI1, Root is also Sw3, and for MSTI2, Sw2. In terms of blocking ports and convergence, MSTP repeats the principles of RSTP on the basis of which it works, so I think the operation of MSTP within one region is quite understandable. Consider a topology with two regions: About Region A has been said above, now we will try to figure out how to interact with each other regions. In region B, the switches have the following configuration:
The construction of an STP tree in Region B is similar to Region A and has been described above. Just say, since we did not set the Root Bridge for MSTI 0 in Region B, it will be selected at the lowest MAC address among Sw9-12. The lowest MAC address is for Sw9. Command output from Sw10:
For MSTI 0 Regional Root 5000.0009.0000 (Sw9). It will be discussed below why Sw9 and why the priority or MAC address is nothing to do with. Now we are more interested in the question of what will happen at the border. In order for the STP tree to be built correctly between regions, using MST0 (IST) a common tree is created for all regions. This tree is called CIST. Let's introduce the concept also CST. So, first recall the IST:
For understanding the boundaries of each tree I advise the following article .
IST is a tree within one region, CIST is a tree between regions, CST is a tree that combines both trees within a region, and a tree to connect regions.
Since we entered the spanning-tree mst 0 root root commandon Sw3, the CIST Root Bridge for both regions will be Sw3. If there is only one region in the entire topology, then the Regional Root Bridge and the CIST Root Bridge are the same. If there are many regions, then the best Regional Root is chosen among all the regions. Also in the election for the role of CIST Root Bridge, switches that use protocols other than MSTP can be used. If you try to build an overall picture, then the interaction of the regions can be explained as follows: Each region appears to be a union of a certain number of switches and appears to other switches as one large virtual switch. That is, if we consider our topology through the eyes of Region B, then we get the following picture for it:
Similarly for Region A, Region B will be represented by a single switch. In each region, each switch has a Root Port that connects it to the Regional Root. Also, each region has one Root Port for MSTI 0, which leads to a common CIST Root Bridge. Such ports can be Gi1 / 1 ports on Sw9 and Sw10, since they connect the regions. In our topology, Sw9 has the best Bridge ID, the Root Port is selected on it, and on Sw10, Gi1 / 1 is blocked. On Sw9 for MSTI 0, the Gi1 / 1 port is Root Port, but for example, for MSTI 1 and 2, there is a Root Port for the Instance Root Bridge and the port that leads to CIST Root Bridge gets a new role - Master. From one region to another there can be only one working channel or in other words only one Master port and only on one switch. Here is the MST information on the Sw9 switch,
This port for MSTI 0, as we said, has the role of Root, and for MSTI 1-2 Master. Also introduced a new type of channel - P2p Bound (RSTP). The Boundary type is assigned to those ports that are on the border with another region or another type of STP protocol. Through the Master port, information about the CIST Root Bridge is transmitted to this region, a distinctive feature is that the port itself does not send BPDUs, but only receives, unlike the type of P2P port, in RSTP. The only exception is BPDU with TC (topology change) flag. Let's see how a BPDU from another region is processed by a switch in one region. As we said on the Master port of Gi1 / 1 Sw9, BPDUs from Sw1 will be received, while Sw9 itself will not be sent, consider it again:
Sw1 sends the same BPDU, regardless of whether the BPDU is sent to the switch within the region or outside the region. Sw9 accepting this BPDU will process the information only before the start of the MST Extension field, only this information is used to build the tree in instance 0. Here you can see an interesting fact - Root Identifier (50: 00: 00: 03: 00: 00) coincides with Bridge Identifiet (50: 00: 00: 03: 00: 00), although it sends a Sw1 packet with Bridge Identifier - 50: 00: 00: 01: 00: 00. This confirms our theory that for each region each region is represented by one large virtual switchboard. You can also say that between regions we have a classic RSTP. But let's talk about Root path cost. There are two types of Path Cost - internal and external. Root Path Cost, which points to MSTI 0, is external. And despite the fact that from Sw1 to Root Bridge (Sw3) there is another channel, it is still indicated as zero. As if sent by Root Bridge himself. Internal Root Path Cost is listed in the fields below the MST Extension. CIST Internal Root Path Cost indicates the cost of the path to the Regional Root Bridge for MSTI 0, and the fields below MSTID 1 and 2 indicate the Internal Root Path Cost to the Root Bridge for each instance, respectively. The external Root Path Cost has a special and very important role, it will determine the Regional Root Bridge, and not the priority and the MAC address, we made a note above about this. The switch that has the smallest Root Path Cost to the CIST Root Bridge will be the Regional Root Bridge! For example, Sw9 and Sw10 have Root Path Cost - 20000, equal to the cost of the port Gi1 / 1. And only after that they begin to compare their Bridge ID. Let's check it out we will change the cost of the link to Sw10 and at the same time we will increase its priority to the maximum, in order to exclude its option of choosing Regional Root by priority. We introduce the following commands:
If, for example, we add a link between Sw9 and Sw4 and think about which link becomes the Master, then for all equal parameters, the CIST Bridge Identifier field, which is lower than the MST Extension, will determine. We lied a bit when we said that Sw9 does not look at the data below the MST Extension. In this case, the CIST Bridge Identifier from the MST Extension will be counted.
Now let's look at the behavior of MST when we add RPVST switches: Two cases are possible:
Consider first the case where Sw3 continues to be a CIST Root Bridge (i.e. case 2). In this case, Sw10 and Sw12 as soon as they receive BPDUs from RSTP1 and RSTP2 for each vlan, they will change the port type Gi1 / 0 to P2p Bound (PVST) . This type means that Sw10 and Sw12 on this port are connected to RPVST switches and will start sending copies of BPDUs for MSTI0 (that is, without fields below MST Extension) to all vlans allowed on this port. Thus, RSTP1 and RSTP2 will not notice that Sw10 and Sw12 use a different protocol. This technology in MSTP is called PVST Simulation, and with the help of it we get agreement between different switches.
The case when Root Bridge is among the RPVST switches is more complex and unrecommended. Imagine that our RSTP1 is the Root Bridge for all vlans. For simplicity, we will assume that vlana 1-3 are created and the spanning-tree vlan 1-3 priority 12288 command is entered , the lowest priority among RSTP and MSTP switches. Sw10 will start receiving BPDUs for each vlan. It is very important to understand that only BPDUs for Vlan 1 will be processed by the MSTP switch. How does this work?
Depending on how many vlans are configured, so many RPVST + BPDU packets will be sent, but in addition, the native vlan BPDU with the destination MAC address is 01: 80: c2: 00: 00: 00 will also be sent. This is the MAC address used by MSTP, PVST and RPVST switches using a different MAC address - 01: 00: 0c: cc: cc: cd. Regardless of which vlan is configured as native, information for the first vlan will be transmitted in this BPDU. Only this packet will be processed to build the tree by MSTP switches. The remaining BPDUs for certain vlans will be used to verify the protection of the root node during the PVST simulation (PVST simulations root-guard-based consistency check). What kind of check? As soon as we configure RSTP1 using this command spanning-tree vlan 1-3 priority 12288, then on Sw10 we will immediately get an error: Let's try to explain. Sw10 received native vlan BPDU for vlan 1 with a priority of 12288 + 1. I processed and decided that Gi1 / 0 is his Root Port. Then came the PVST BPDU for the remaining vlans (1-3), he studied them to check the integrity of the root switch, and there were priorities of 12,288 + 2, 12,288 + 3 for vlan 2-3, which are more than 12,288 + 1. Integrity is destroyed - on the one hand, it must be a Root Port, and obtaining other higher priorities causes the port to switch to the Designated role. Such ambiguity is inadmissible for such protocols and MST blocks this port putting it in the BKN state, reporting an error - Blocking root port Gi1 / 0: Inconsitent inferior PVST BPDU received
. To prevent this, it is necessary that no vlan, whose BPDU will be transmitted on this port, have priority (more) than vlan 1. That is, if we reduce the priorities of vlans 2-3 to 4096, obviously less than u vlana 1, then we fix this problem. As you can see, there was a message that restores the correct operation of the port - PVST Simulation inconsistency cleared on port GigabitEhternet 0/1 . On this, I think, to end the conversation on MSTP. Useful links below:
- RPVST + and PVST + are only on Cisco equipment, and on Cisco there is no classic STP and RSTP. What should we do if other vendors are involved in the topology?
- Each instance of STP and RSTP send BPDUs every two seconds. If 100 trunks are skipped on a trunk port, then 100 messages will be sent in 2 seconds. Which is not too good.
- On Cisco, there is a limit in the number of STP or RSTP instances on a single switch, depending on the model. That is, adding 128 vlans on some switch, we will face such a restriction. Link here
All these problems are successfully solved by the multi-vendor protocol MSTP. We will try to deal with his work. The scheme for constructing a loopless topology in RSTP consists in plotting a graph without intersections, regardless of logical topologies, without taking into account where and how the vlans are configured. In MSTP, we get the opportunity to combine certain vlans into a group and for each group build a separate topology. For example, take a look at this topology: PCs play the role of network segments. PC1, PC3 is the network segment where Vlans from 10 to 50 are used, and PC2, PC4 are installed from 50 to 100. Vlana from 10 to 100 are created on the Sw1-4 switches themselves. If we use the RSTP protocol, then segments PC1 and PC2 get to segments PC3 and PC4 respectively, you need to use one common path, choosing it from two possible:
Sw1-Sw2-Sw4 or Sw1-Sw3-Sw4 . Unfortunately, it is impossible to build a scheme with load distribution and one of these paths will be blocked and empty. With the help of PVST + and RPVST +, this can be done, but there are their own problems mentioned above. MSTP comes to our aid in this matter, creating an RSTP instance for a group of Vlans 10-50 and 50-100. You can configure that the Root switch for Vlan 10-50 will be Sw3, and for 50-100 - Sw2. The path Sw1-Sw3-Sw4 will be used by Vlans 10-50, the path Sw1-Sw2-Sw4- Vlans 50-100. The idea is to create instances that will integrate Vlans and build an RSTP tree separately for each instance. Thus, by combining Vlans 10-50 and 51-100 in different instances, the MSTP protocol will allow building independent trees for each instance. The configuration will look like this:
vlan 10-50 instance 2 vlan 51-100 spanning-tree mst configurationIt will be identical on all 4 switches. Switches with identical configuration of these parameters create one region. As for the regions, we will speak in more detail below, while we consider the topology within one region. For each instance, its own Root Bridge is selected. On Sw3, enter the command spanning-tree mst 1 root primary so that Sw3 is Root Bridge for vlans 10-50, and on Sw2 spanning-tree mst 2 root primary for vlan 51-100. In summary, each instance - multiple spanning tree instances (MSTI) - combines vlans. And each region combines switches that have the same MSTI. If we speak strictly, then in the region the switch should have the same parameters:
name Note Instance 1
- region name - the name of the region. Set by the name command.
- revision level is a configuration change parameter.
- MSTI.
In each region there is an instance of MSTI 0 (instance 0), which is created by default and it includes all the vlans that were not included in the other instances. Instance 0 is called IST:
Internal Spanning Tree (IST) —a special copy of the spanning tree, which, by default, exists in every MST region. IST is assigned the number 0 (Instance 0). It can send and receive BPDU frames and serves to manage the topology within the region. All VLANs configured on switches in a given MST region are tied to IST by default.
Root Bridge for IST is called Regional Root Bridge. It is through IST that the frames of BPDU are transmitted, through which a tree is set for each instance. Consider what BDPU looks like in this region:
Before the start of the MST Extension field, the BPDU MSTP is very difficult to separate from the RSTP BPDU and, roughly speaking, IST is the classic RSTP. MSTP only adds MSTI data. The BPDU stores information about the Root Bridge for Instance 0-2. Thus, for all vlans and authorities, only one BPDU is sent, which contains all the necessary information. This is a huge savings compared to PVST + and RPVST +. Let's see the output of the show spanning-tree mst command on the Sw2 switch: For instance 0 there is a special field - Regional Root. Regional Root we chose Sw3 using the spanning-tree mst 0 root primary command
. Regional Root is the root switch for MSTI 0 within one region. For MSTI1, Root is also Sw3, and for MSTI2, Sw2. In terms of blocking ports and convergence, MSTP repeats the principles of RSTP on the basis of which it works, so I think the operation of MSTP within one region is quite understandable. Consider a topology with two regions: About Region A has been said above, now we will try to figure out how to interact with each other regions. In region B, the switches have the following configuration:
spanning-tree mst configurationAt the same time, Sw9 - spanning-tree mst 1 root primary - root switch for Vlan 10-30, and Sw10 - spanning-tree mst 2 root primary - root switch for Vlan 31-60.
name RegionB
instance 1 vlan 10-30
instance 2 vlan 31-60
The construction of an STP tree in Region B is similar to Region A and has been described above. Just say, since we did not set the Root Bridge for MSTI 0 in Region B, it will be selected at the lowest MAC address among Sw9-12. The lowest MAC address is for Sw9. Command output from Sw10:
For MSTI 0 Regional Root 5000.0009.0000 (Sw9). It will be discussed below why Sw9 and why the priority or MAC address is nothing to do with. Now we are more interested in the question of what will happen at the border. In order for the STP tree to be built correctly between regions, using MST0 (IST) a common tree is created for all regions. This tree is called CIST. Let's introduce the concept also CST. So, first recall the IST:
- Internal Spanning Tree (IST) is a special copy of the spanning tree, which exists by default in every MST region. IST is assigned the number 0 (Instance 0). IST can send and receive BPDU frames and serves to manage the topology within the region. By default, all VLANs of the same region are bound to IST. If there are several MSTIs created in the region, then non-associated VLANs remain associated with the IST. In our regions A and B, an independent STP tree is built for vlans who did not fall into instances 1 and 2. The Root Bridge in IST is called the Regional Root.
- Common Spanning Tree (CST) is a tree connecting regions and all STP, RSTP, PVST +, RPVST + switches (not MST switches).
- Common and Internal Spanning Tree (CIST) is a single spanning tree that combines the CST and IST of each MST region.
For understanding the boundaries of each tree I advise the following article .
IST is a tree within one region, CIST is a tree between regions, CST is a tree that combines both trees within a region, and a tree to connect regions.
Since we entered the spanning-tree mst 0 root root commandon Sw3, the CIST Root Bridge for both regions will be Sw3. If there is only one region in the entire topology, then the Regional Root Bridge and the CIST Root Bridge are the same. If there are many regions, then the best Regional Root is chosen among all the regions. Also in the election for the role of CIST Root Bridge, switches that use protocols other than MSTP can be used. If you try to build an overall picture, then the interaction of the regions can be explained as follows: Each region appears to be a union of a certain number of switches and appears to other switches as one large virtual switch. That is, if we consider our topology through the eyes of Region B, then we get the following picture for it:
Similarly for Region A, Region B will be represented by a single switch. In each region, each switch has a Root Port that connects it to the Regional Root. Also, each region has one Root Port for MSTI 0, which leads to a common CIST Root Bridge. Such ports can be Gi1 / 1 ports on Sw9 and Sw10, since they connect the regions. In our topology, Sw9 has the best Bridge ID, the Root Port is selected on it, and on Sw10, Gi1 / 1 is blocked. On Sw9 for MSTI 0, the Gi1 / 1 port is Root Port, but for example, for MSTI 1 and 2, there is a Root Port for the Instance Root Bridge and the port that leads to CIST Root Bridge gets a new role - Master. From one region to another there can be only one working channel or in other words only one Master port and only on one switch. Here is the MST information on the Sw9 switch,
This port for MSTI 0, as we said, has the role of Root, and for MSTI 1-2 Master. Also introduced a new type of channel - P2p Bound (RSTP). The Boundary type is assigned to those ports that are on the border with another region or another type of STP protocol. Through the Master port, information about the CIST Root Bridge is transmitted to this region, a distinctive feature is that the port itself does not send BPDUs, but only receives, unlike the type of P2P port, in RSTP. The only exception is BPDU with TC (topology change) flag. Let's see how a BPDU from another region is processed by a switch in one region. As we said on the Master port of Gi1 / 1 Sw9, BPDUs from Sw1 will be received, while Sw9 itself will not be sent, consider it again:
Sw1 sends the same BPDU, regardless of whether the BPDU is sent to the switch within the region or outside the region. Sw9 accepting this BPDU will process the information only before the start of the MST Extension field, only this information is used to build the tree in instance 0. Here you can see an interesting fact - Root Identifier (50: 00: 00: 03: 00: 00) coincides with Bridge Identifiet (50: 00: 00: 03: 00: 00), although it sends a Sw1 packet with Bridge Identifier - 50: 00: 00: 01: 00: 00. This confirms our theory that for each region each region is represented by one large virtual switchboard. You can also say that between regions we have a classic RSTP. But let's talk about Root path cost. There are two types of Path Cost - internal and external. Root Path Cost, which points to MSTI 0, is external. And despite the fact that from Sw1 to Root Bridge (Sw3) there is another channel, it is still indicated as zero. As if sent by Root Bridge himself. Internal Root Path Cost is listed in the fields below the MST Extension. CIST Internal Root Path Cost indicates the cost of the path to the Regional Root Bridge for MSTI 0, and the fields below MSTID 1 and 2 indicate the Internal Root Path Cost to the Root Bridge for each instance, respectively. The external Root Path Cost has a special and very important role, it will determine the Regional Root Bridge, and not the priority and the MAC address, we made a note above about this. The switch that has the smallest Root Path Cost to the CIST Root Bridge will be the Regional Root Bridge! For example, Sw9 and Sw10 have Root Path Cost - 20000, equal to the cost of the port Gi1 / 1. And only after that they begin to compare their Bridge ID. Let's check it out we will change the cost of the link to Sw10 and at the same time we will increase its priority to the maximum, in order to exclude its option of choosing Regional Root by priority. We introduce the following commands:
Sw10 (config-if) # spanning-tree mst 0 priority 61440And we get that Sw10, despite its terrible priority, has become Regional Root Bridge: Thus, the choice of Regional Root Bridge occurs in this sequence and the Regional Root Bridge can never be a switch without boundary ports:
Sw10 (config-if) # interface gigabitEthernet 1/1
Sw10 (config-if) # spanning-tree mst 0 cost 10000
- Lowest CIST Root bridge.
- Lowest Regional Bridge Identifier.
- BPDU CIST Bridge Identifier by region with CIST Root Bridge.
If, for example, we add a link between Sw9 and Sw4 and think about which link becomes the Master, then for all equal parameters, the CIST Bridge Identifier field, which is lower than the MST Extension, will determine. We lied a bit when we said that Sw9 does not look at the data below the MST Extension. In this case, the CIST Bridge Identifier from the MST Extension will be counted.
Now let's look at the behavior of MST when we add RPVST switches: Two cases are possible:
- Root Bridge is owned by RPVST.
- Root Bridge is owned by MSTP.
Consider first the case where Sw3 continues to be a CIST Root Bridge (i.e. case 2). In this case, Sw10 and Sw12 as soon as they receive BPDUs from RSTP1 and RSTP2 for each vlan, they will change the port type Gi1 / 0 to P2p Bound (PVST) . This type means that Sw10 and Sw12 on this port are connected to RPVST switches and will start sending copies of BPDUs for MSTI0 (that is, without fields below MST Extension) to all vlans allowed on this port. Thus, RSTP1 and RSTP2 will not notice that Sw10 and Sw12 use a different protocol. This technology in MSTP is called PVST Simulation, and with the help of it we get agreement between different switches.
The case when Root Bridge is among the RPVST switches is more complex and unrecommended. Imagine that our RSTP1 is the Root Bridge for all vlans. For simplicity, we will assume that vlana 1-3 are created and the spanning-tree vlan 1-3 priority 12288 command is entered , the lowest priority among RSTP and MSTP switches. Sw10 will start receiving BPDUs for each vlan. It is very important to understand that only BPDUs for Vlan 1 will be processed by the MSTP switch. How does this work?
Depending on how many vlans are configured, so many RPVST + BPDU packets will be sent, but in addition, the native vlan BPDU with the destination MAC address is 01: 80: c2: 00: 00: 00 will also be sent. This is the MAC address used by MSTP, PVST and RPVST switches using a different MAC address - 01: 00: 0c: cc: cc: cd. Regardless of which vlan is configured as native, information for the first vlan will be transmitted in this BPDU. Only this packet will be processed to build the tree by MSTP switches. The remaining BPDUs for certain vlans will be used to verify the protection of the root node during the PVST simulation (PVST simulations root-guard-based consistency check). What kind of check? As soon as we configure RSTP1 using this command spanning-tree vlan 1-3 priority 12288, then on Sw10 we will immediately get an error: Let's try to explain. Sw10 received native vlan BPDU for vlan 1 with a priority of 12288 + 1. I processed and decided that Gi1 / 0 is his Root Port. Then came the PVST BPDU for the remaining vlans (1-3), he studied them to check the integrity of the root switch, and there were priorities of 12,288 + 2, 12,288 + 3 for vlan 2-3, which are more than 12,288 + 1. Integrity is destroyed - on the one hand, it must be a Root Port, and obtaining other higher priorities causes the port to switch to the Designated role. Such ambiguity is inadmissible for such protocols and MST blocks this port putting it in the BKN state, reporting an error - Blocking root port Gi1 / 0: Inconsitent inferior PVST BPDU received
. To prevent this, it is necessary that no vlan, whose BPDU will be transmitted on this port, have priority (more) than vlan 1. That is, if we reduce the priorities of vlans 2-3 to 4096, obviously less than u vlana 1, then we fix this problem. As you can see, there was a message that restores the correct operation of the port - PVST Simulation inconsistency cleared on port GigabitEhternet 0/1 . On this, I think, to end the conversation on MSTP. Useful links below:
- www.cisco.com/c/en/us/support/docs/lan-switching/multiple-instance-stp-mistp-8021s/116464-configure-pvst-00.html
- habrahabr.ru/post/128172
- www.cisco.com/c/ru_ru/support/docs/lan-switching/multiple-instance-stp-mistp-8021s/116464-configure-pvst-00.pdf
- www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus5000/sw/configuration/guide/cli_rel_4_0_1a/CLIConfigurationGuide/MST.html
- networkengineering.stackexchange.com/questions/28716/multiple-spanning-tree-terminology-cst-ist-cist-and-exact-behavior
- blog.sbolshakov.ru/11-3-mstp
- blog.ine.com/2010/02/22/understanding-mstp
- networklessons.com/spanning-tree/multiple-spanning-tree-mst