Sep
24

Note: You may want to read a newer blog post on MSTP here Understanding MSTP

This post continues the previous article dedicated to MSTP operations inside a single region. Before reading any further, make sure you read and fully understand the first part of MSTP overview: MSTP Tutorial Part I: Inside a Region. The information there is critical to understand the new post.

The concept of CIST

As you remember, every MSTP region runs special instance of spanning-tree known as IST or Internal Spanning Tree (=MSTI0). This instance is active on all links inside a region and serves the purpose of disseminating STP topology information for other STP instances. As usual, IST has a root bridge, elected based on the lowest bridge ID (priority/MAC address). However, situation changes when you have different regions in the network (e.g. switches with different region names, different revisions, etc). When a switch detects BPDU messages sourced from another region on any link, it marks the link as MSTP boundary. On the figure below you can see two MSTP regions connected via two separate links (disregard the RSTP region for now).

Now two regions should build a common spanning tree known as CIST – Common and Internal Spanning Tree. This tree is result of joining ISTs of each region in a special manner. Here is a detailed description of the process.

1) In addition to sending IST configuration BPDUs, every switch initially declares itself as the root of CIST. The switches pass CIST configuration information along with IST information in additional BPDU fields. Switches inside a region never change the path cost to the CIST Root, known as CIST External Root Path Cost. Instead of that, the external path cost only changes on the boundary ports. Thus, this external cost only accounts for the cost of boundary links, not the cost of the paths inside a region. Essentially, CIST External Path Cost information “tunnels” across a region.

2) On boundary ports, switches exchange their CIST BPDU information ONLY. That is, switches hide IST information between regions, but pass CIST metrics. The usual RSTP synchronization process takes places between switches on a border link, and eventually ONE switch with the lowest BID (Bridge ID = Priority + MAC Address) among all regions is elected as the CIST Root. Note that each region still elects a local IST root, known as CIST Regional Root, as described further.

3) The region that contains the CIST Root, declares this switch as the root of local IST as well. However, things start to differ for regions that don’t contain the CIST root. All of them elect one of the border switches (switches connected to other regions) as IST root (aka CIST Regional Root). This procedure elects the IST Root (CIST Regional Root) based on the lowest CIST External Root Path Cost. Note that this procedure differs from elections based purely on BID, which take place inside a single region. In this case, the procedure uses BIDs as tiebreaker, if two or more switches have the same CIST Root External Path Cost. MSTP blocks all redundant boundary “uplinks” marking them as “alternate” paths to the CIST Root. The boundary switches do so by receiving “extra” CIST BPDUs on top of IST BPDUs with external root path cost values and comparing them with the ones received on local boundary ports.

4) Inside a region, switches build regular IST, using the CIST Regional Root as the root of IST. Note that this tree uses so-called Internal Root Path Cost stored in the local IST BPDUs. This cost increments along all the links inside a region, but it never leaks out of the region. Between regions, switches exchange information about CIST External Root Path cost only.

Note that switch with non-optimal priority value may become the CIST Regional Root (local IST Root). For example, if you configure a switch inside a region with a lowest BID among all switches it may not necessarily become the CIST Regional Root. Only if the switch has the lowest BID among all regions it would be elected as CIST Root.

The concept of CST and STP interoperation

From the above information, we conclude that CIST essentially has organization of a two-level hierarchy. The first level treats all regions as “pseudo-bridges” and operates with the External Root Path Cost. The first-level spanning tree roots in CIST Root Bridge and encompasses the pseudo-bridges. They call it CST or Common Spanning Tree. Effectively, this has no idea of the internal MSTP regions structure, but sees each region as a virtual bridge.

This is the point where MSTP interoperates with legacy IEEE STP/RSTP regions as well. The legacy switch regions have no concept of IST, so they simply join their STP instance with the CST and perceive MSTP regions as “transparent” pseudo-bridges, staying unaware of their internal topology. (Note that it may happen so that a switch with the lowest BID belongs to 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”). Naturally, MSTP detects the appropriate STP version on a boundary link and switches to the respective mode of operations (e.g. RSTP/STP).

The second level of CIST hierarchy consists of various regional ISTs. Every MSTP region builds IST instance using the internal path costs and following the optimal “internal” topology. As you remember, this “internal topology” transparently transports the “external” BPDU information to the border switches, so that they can elect Regional CIST Root. The fist level topology (CST) is somewhat independent of the second level topology (IST) and bases upon the CIST root and cost of the boundary links. The second level topology (“internal”, IST) may change in case if boundary link cost changes or something happens to the CIST Root, since this affect the election of the Regional CIST Root.

MSTP pseudo-bridges do not strictly emulate the real bridges. For example, different boundary switches send their own BID in BPDUs, so the pseudo-bridge may appear to have many BIDs on various boundary links. However, this has no impact on the process of transparent tunneling of CIST Root information across the pseudo-bridge. Other things that don’t see pseudo-bridge as non-transparent include MSTP hop count or MaxAge timer value, for they may change asynchronously, as information travels along different paths inside a region.

MSTIs and CIST

Now, what could be said about the MSTIs – individual STP instances used inside regions? From what we learned so far, it is easy to conclude that the only logical solution is to map all MSTP instances to the CIST on the boundary links. This implies that you cannot load-balance VLAN traffic on the boundary links by mapping VLANs to different instances. All VLANs use the same non-blocking uplink that CIST elected as the optimal path to the CIST Root. But this only applies to the “CST” paths connecting the regional virtual bridges – inside any region VLANs follow the internal topology paths, based on the respective MSTI configurations.

It is important to note that MSTIs have no idea of the CIST Root whatsoever; they only use internal paths and internal MSTI root to build the spanning tree. However, all MSTP instances see the root port (towards the CIST Root) of the CIST Regional Bridge as the special “Master Port” connecting them to the “outside” world. This port serves the purpose of the “gateway” linking MSTI’s to other regions. Notice that switches do not send M-records (MSTI information) out of boundary ports, only CIST information and thus . Thus, the CIST and MSTI’s may converge independently and in parallel. The master port will ony beging forwarding when all respective MSTI ports are in sync and forwarding to avoid temporary bridging loops.

MSTP and Fault Isolation

Ethernet is known for its broadcast nature that tends propagating issues 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. Every topology change may cause massive invalidation of MAC address tables and unicast traffic flooding. This process is the result of Ethernet topology unawareness – the bridges don’t know MAC addresses location.
  • Broadcas and Multicast flooding. This is a separate problem as many core protocols (ARP, IGP, PIM) rely on multicasting or broadcasting. Thos 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 convergence issue, such as counting to infinity (old information circulation). This is especially noticeable in larger topologies with 10 switches and more 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, 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.

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. A 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 – separated “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.

Interoperating with PVST+

This task poses a tough issue. We know that PSVST+ runs an STP instance for every VLAN. On a contrary, MSTP maps VLANs to MSTIs, so one-to-one mapping between VLAN and STP instance no longer holds true. How should an MSTP switch operate on a border link connected to the PVST+ domain? As we remember, on the border with IEEE STP domain, PVST+ simply joins VLAN 1 STP with IEEE STP and tunnels SSTP BPDUs across the IEEE STP domain (refer to PVST+ Explained article for more information).

However, MSTP runs multiple MSTIs inside a region and maps them all to CIST on the border link. That means we need to make sure that internal MSTIs could be aware of changes in PVST+ trees. It’s hard to automatically map VLAN-based STPs to MSTI and so the simplest way to accomplish the desired behavior is to join all PVST+ trees with CIST. This way, changes in any of PVST+ STP instances propagate to CIST/IST and affect all MSTIs in result. While not the optimal solution, it ensure that no changes go unnoticed and no black holes occur in a single VLAN due to the topology changes.

The MSTP implementation simulates PVST+ by replicating CIST BPDUs on the link facing the PVST+ domain and sending the BPDUs on ALL VLANs active on the trunk. The MSTP switch consumes all BDPUs received from PVST+ domain and processes them using the CIST/IST instance. The PSVT+ side sees the MSTP domain as a special PVST+ domain with all per-VLAN instances claiming the CIST Root as the root of their STP. Note that PVST+ also interprets the whole region as a single pseudo-bridge, but operating in PSVT+ mode. The two possible options are allowed here:

1) MSTP domain (either a single region or multiple regions) contains the root bridge for ALL VLANs. This is only true if CIST Root BID is better than any PVST+ STP root BID. This is the preferred design, for you can manipulate uplink costs on the PVST+ side and obtain optimal traffic engineering results.

2) PVST+ contains the root bridges for ALL VLANs, including VLAN1, which maps to CST of STP. This is only true is all PVST+ root bridges BIDs for all VLANs are better than CIST Root BID. This is not the preferred design, since all MSTIs map to CIST on the border link, and you cannot load-balance the MSTIs as the enter the PVST+ domain.

Cisco implementation does not support the second option. MSTP domain should contain the bridge with the best BID, to ensure that the CIST Root is also the root for all PVST+ trees. If any other case, 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 BIDs better than the CIST Root Bridge ID.

Scenario 1: CIST Root and CIST Regional Root

In this scenario, we configure four switches in two regions. The first region consists of one switch (SW1) and the second region consists of three switches: SW2, SW3 and SW4. SW1 is the CIST root thanks to its lowest priority. SW2 is the CIST Regional Root. We also demonstrate some path manipulation options.

SW1:
spanning-tree mode mst
spanning-tree mst 0 priority 4096
!
spanning-tree mst configuration
 name REGION1
 exit

SW2:
spanning-tree mode mst
spanning-tree mst configuration
 name REGION234
 exit
!
interface range FastEthernet 0/13 - 14
 spanning-tree mst 0 cost 100

SW3:
spanning-tree mode mst
spanning-tree mst configuration
 name REGION234
 exit
!
interface FastEthernet 0/19
 spanning-tree mst 0 cost 100

SW4:
spanning-tree mode mst
spanning-tree mst configuration
 name REGION234
 exit
spanning-tree mst 0 priority 16384
!
interface FastEthernet 0/16
 spanning-tree mst 0 cost 100

In the above configuration we adjusted some link costs to ensure that

1) MSTP elects SW2 as the CIST Regional root due to its shortest path to the CIST Root. SW2 is the CIST Regional Root for REGION234, even though SW4 has better switch priority.
2) SW3 selects the path through SW4 to reach internal root bridge due to the shortest path cost via SW4.

Verifications:

SW2#show spanning-tree mst 0

##### MST0    vlans mapped:   1-4094
Bridge        address 0019.564c.c580  priority      32768 (32768 sysid 0)
Root          address 0019.55e6.d380  priority      4096  (4096 sysid 0)
              port    Fa0/13          path cost     100
Regional Root this switch
Operational   hello time 2 , forward delay 15, max age 20, txholdcount 6
Configured    hello time 2 , forward delay 15, max age 20, max hops    20

Interface        Role Sts Cost      Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa0/13           Root FWD 100       128.15   P2p Bound(RSTP)
Fa0/14           Altn BLK 100       128.16   P2p Bound(RSTP)
Fa0/16           Desg FWD 200000    128.18   P2p
Fa0/19           Desg FWD 200000    128.21   P2p

Note the following: SW2 is the Root Bridge (CIST Root) with priority 4096. The root port is Fa 0/13, elected based on regular STP rules (shortest path, lowest upstream port priority). The other uplink is blocking. Both ports show up as “Boundary” since they face the other MSTP domain. Note that SW2 is the Regional Root due to the fact that is has the shortest path to the CIST Root.

Now look at SW4. This switch has lower priority than SW2, but it is not elected as the CIST Regional Root, for SW4 path cost to the CIST Root is worse

SW4#show spanning-tree mst 0

##### MST0    vlans mapped:   1-4094
Bridge        address 000b.5f02.1100  priority      16384 (16384 sysid 0)
Root          address 0019.55e6.d380  priority      4096  (4096 sysid 0)
              port    Fa0/16          path cost     100
Regional Root address 0019.564c.c580  priority      32768 (32768 sysid 0)
                                      internal cost 100       rem hops 19
Operational   hello time 2 , forward delay 15, max age 20, txholdcount 6
Configured    hello time 2 , forward delay 15, max age 20, max hops    20

Interface        Role Sts Cost      Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa0/13           Altn BLK 200000    128.13   P2p Bound(RSTP)
Fa0/16           Root FWD 100       128.16   P2p
Fa0/19           Desg FWD 200000    128.19   P2p

Note the following in the above output. First, the local switch has priority value of 16834 and the CIST Root has priority value of 4096. Next the path cost to CIST Root is 100 – the same value that SW2 (the CIST Regional Root) has. This is a direct consequence from the fact that CIST External Root Path cost never increments along the internal paths. The CIST Regional Root is SW2 with the default priority, and the internal path cost is 100 – just as we set it. The boundary port is Fa 0/13 and it is blocking (we are not the CIST Regional Root). The port connected to SW2 is out root port (internal root port). Finally inspect the show output on SW3:

SW3#show spanning-tree mst 0

##### MST0    vlans mapped:   1-4094
Bridge        address 000d.bd27.de00  priority      32768 (32768 sysid 0)
Root          address 0019.55e6.d380  priority      4096  (4096 sysid 0)
              port    Fa0/19          path cost     100
Regional Root address 0019.564c.c580  priority      32768 (32768 sysid 0)
                                      internal cost 200       rem hops 18
Operational   hello time 2 , forward delay 15, max age 20, txholdcount 6
Configured    hello time 2 , forward delay 15, max age 20, max hops    20

Interface        Role Sts Cost      Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa0/16           Altn BLK 200000    128.16   P2p
Fa0/19           Root FWD 100       128.19   P2p

Again, we see that SW1 is the CIST Root with the External Root Path Cost of 100 (it never changes inside the region). SW2 is the CIST Regional Root with the internal path cost of 200 (across SW4). The link to SW2 is the root port of SW4.

Scenario 2: MSTIs and the Master Port

In this scenario we adds another STP instance to REGION234. We also add two VLANs 10 and 20 to all switches and map them to MSTI 1 in REGION234.

SW1:
vlan 10,20

SW2, SW3 & SW4:
vlan 10,20
!
spanning-tree mst configuration
 instance 1 vlan 10, 20

Let’s see the show command output in SW2.

SW2#show spanning-tree mst 1

##### MST1    vlans mapped:   10,20
Bridge        address 0019.564c.c580  priority      32769 (32768 sysid 1)
Root          address 000b.5f02.1100  priority      32769 (32768 sysid 1)
              port    Fa0/19          cost          200000    rem hops 19

Interface        Role Sts Cost      Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa0/13           Mstr FWD 200000    128.15   P2p Bound(RSTP)
Fa0/14           Altn BLK 200000    128.16   P2p Bound(RSTP)
Fa0/16           Altn BLK 200000    128.18   P2p
Fa0/19           Root FWD 200000    128.21   P2p

There is no Regional Root here. 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 provides the path upstream to the CIST Root for all MSTIs and their VLANs.

Scenario 3: PVST+ and MSTP interoperation

In this scenario, we configure SW1 to use PSVT+ and see how it interworks with MSTP. First, configure so that SW1 is the root bridge for all VLANs and that it beats all bridges in MSTP domain.

SW1:
spanning-tree mode pvst
spanning-tree vlan 1-4094 priority 8192

Let’s see what happens on SW2:

%SPANTREE-2-PVSTSIM_FAIL: Superior PVST BPDU received on VLAN 

SW2#show spanning-tree mst 0

##### MST0    vlans mapped:   1-9,11-19,21-4094
Bridge        address 0019.564c.c580  priority      32768 (32768 sysid 0)
Root          address 0019.55e6.d380  priority      4097  (4096 sysid 1)
              port    Fa0/13          path cost     100
Regional Root this switch
Operational   hello time 2 , forward delay 15, max age 20, txholdcount 6
Configured    hello time 2 , forward delay 15, max age 20, max hops    20

Interface        Role Sts Cost      Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa0/13           Root BKN*100       128.15   P2p Bound(PVST) *PVST_Inc 
Fa0/14           Altn BLK 100       128.16   P2p Bound(PVST)
Fa0/16           Desg FWD 200000    128.18   P2p
Fa0/19           Desg FWD 200000    128.21   P2p

First note the syslog message in the beginning. It says that while emulating PVST+ the MSTP code encountered the situation where PVST+ domain claims itself as a root for one or more VLANs. This implies PVST+ bridge having 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. This process results in interesting situation – even though the PVST+ domain contains the CIST Root, the MSTP domain cannot reach it. In effect, potential loops are eliminated, but the MSTP domain loses connectivity to the PVST+ domain. The same situation could be observed with the MSTI 1:

SW2#show spanning-tree mst 1

##### MST1    vlans mapped:   10,20
Bridge        address 0019.564c.c580  priority      32769 (32768 sysid 1)
Root          address 000b.5f02.1100  priority      32769 (32768 sysid 1)
              port    Fa0/19          cost          200000    rem hops 19

Interface        Role Sts Cost      Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa0/13           Mstr BKN*200000    128.15   P2p Bound(PVST) *PVST_Inc 
Fa0/14           Altn BLK 200000    128.16   P2p Bound(PVST)
Fa0/16           Altn BLK 200000    128.18   P2p
Fa0/19           Root FWD 200000    128.21   P2p

Here we see that the “Master Port” is blocked 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 IST to a number lower than any PVST+ bridge priority.

SW1:
spanning-tree mode pvst
spanning-tree vlan 1-4094 priority 8192

SW2:
spanning-tree mst 0 priority 4096

Now SW2 is the new CIST Root. Look at the show command output now:

SW2#show spanning-tree mst 0

##### MST0    vlans mapped:   1-9,11-19,21-4094
Bridge        address 0019.564c.c580  priority      4096  (4096 sysid 0)
Root          this switch for the CIST
Operational   hello time 2 , forward delay 15, max age 20, txholdcount 6
Configured    hello time 2 , forward delay 15, max age 20, max hops    20

Interface        Role Sts Cost      Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa0/13           Desg LRN 100       128.15   P2p Bound(PVST)
Fa0/14           Desg BLK 100       128.16   P2p Bound(PVST)
Fa0/16           Desg FWD 200000    128.18   P2p
Fa0/19           Desg FWD 200000    128.21   P2p 

SW2#show spanning-tree mst 1

##### MST1    vlans mapped:   10,20
Bridge        address 0019.564c.c580  priority      32769 (32768 sysid 1)
Root          address 000b.5f02.1100  priority      32769 (32768 sysid 1)
              port    Fa0/19          cost          200000    rem hops 19

Interface        Role Sts Cost      Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa0/13           Desg FWD 200000    128.15   P2p Bound(PVST)
Fa0/14           Desg FWD 200000    128.16   P2p Bound(PVST)
Fa0/16           Altn BLK 200000    128.18   P2p
Fa0/19           Root FWD 200000    128.21   P2p

All SW2 ports are now designated. It 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.

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) on a daily basis for many years. When not actively teaching classes, developing self-paced products, studying for the CCDE Practical & the CCIE Storage Lab Exam, and completing his PhD in Applied Mathematics.

Find all posts by Petr Lapukhov, 4xCCIE/CCDE | Visit Website


You can leave a response, or trackback from your own site.

36 Responses to “MSTP Tutorial Part II: Outside a Region”

 
  1. Sahara says:

    Hi Petr,
    As we can see it´s impossible to implement
    the second option (Interoperating with PVST+
    PVST Simulation Inconsistent).

    Why the Cisco´s guys keep this information on the web site ?

  2. To: Sahara

    This puzzles me as well actually :) Probably it was an option in pre-standard implementation. But since it does not make much practical sense to allow PVST+ domain contain all root bridges, Cisco decided to simply block such cases. If you think of that, it’s too risky to allow PVST+ domain to control root bridges and besides it does not allow for flexible load-balancing features of PVST+.

  3. Vladimir Kokshenev says:

    Thanks, Petr!

    It’s a greate article.
    Hope proctors will not become evil enough to use this on exam. =)

  4. asap says:

    Hi Petr,
    In the following paragraph
    ‘… the special “Master Port” connecting them to the “outside” world. This port is always forwarding, and serves the purpose of the “gateway” linking MSTIs to other regions.’

    do you mean all MSTIs of one region can communicate with other bridges outside the region only via ‘master port’? what about the boundary ports?

  5. To: asap

    Remember that Master Port is the non-blocking boundary port. There may be other non-blocking boundary ports, but they may have blocking downstream ports.

    Thus, the Master Port is essentially the “external root port” for a MSTI. Every MSTI has it’s own internal tree structure, plus one special uplink (master root port) which leads MSTI traffic towards the CIST Root.

  6. [...] from IE blog has posted his second writeup on MSTP. This is good stuff, i read through the Private vlans writeup he did and it helped me understand PV [...]

  7. Olivier says:

    Hi Petr,

    Great article. Can you help me with the question below?

    Should I consider a single region as belonging to a single operator for example? Are there any reasons/advantages to split a single region into several regions?

    For example in case the topology changes (link failure, NE added, transport link added), what will be the impact on the traffic? As far as I have understood, this will lead to a reconfiguration of all switches in one region (since this topology change is distributed through the STI or MSTI0). Will this impact the traffic on all these switches inside the region?

    Can you optimize this by splitting one region into several other regions? In case of a topology change in part of the network, the possible impact is limited to a smaller part of the network (and services).

    Kind regards,

    Olivier

  8. Karim Jamali says:

    Amazing Peter!!!

    I got the fact that when running MSTP & PVST,one should ensure that the CIST is elected from the MSTP side. Otherwise we will lose communication between the two domains.
    But if possible could you explain the why behind that?
    Thank You

  9. Emanuel Balasa says:

    Hi Petr,

    First of all I want to congratulate you for your wonderful explanations. Second, I want to clear out a problem which was actually asked by Sahara, too, in the first comment.

    You say that:
    “Cisco implementation does not support the second option. MSTP domain should contain the bridge with the best BID, to ensure that the CIST Root is also the root for all PVST+ trees. If any other case, MSTP border switch will complain and place the ports that receive superior BPDUs from PVST+ region in root-inconsistent state.”

    This happens because an MST region needs to “see” the same root BID in the BPDUs coming from ALL VLANs on the PVST+ boundary. As MST only runs instance 0 on the boundary, it replicates all its BPDUs on all VLANs (as you very well explained) and, therefore, cannot cope with different roots on different VLANs (it would mean storing multiple BPDUs on a port for a single instance, which would be impossible).

    The question is why are Cisco devices sending different BID values on every VLAN, making the MST PVST+ simulation fail..Well, the answer is the MAC Address Reduction algorithm, which reserves the first 4 bits in the BID for setting the priority and the subsequent 12 bits for VLAN ID, therefore creating a unique BID for every VLAN. This was needed for switches which don’t support too many owned MAC addresses and therefore cannot have a unique BID for each VLAN. In this manner, a default priority value for a Cisco switch on VLAN 1 would be 32769, it would be 32770 for VLAN 2 and so forth. The only way to disable this behavior is to issue “no spanning-tree extend-system-id” command on platforms that support this. For instance, a Cisco 3750 won’t allow disabling the MAC address reduction process because it supports only about 32 owned MAC addresses. If you have a distribution switch which allows you to issue “no span extend” or you own a Nortel or BNT Blade Switch which interoperate with PVST+ but they use the same BID for all VLANs (PVST instances), you shall see that the PVST+ emulation no longer fails when the CIST Root is inside the PVST+ region (outside of the MST region). The MST region will see the same root BID on all VLANs and will accept this situation.

    @Sahara: Hope this answers your question, Sahara, about why Cisco still keeps this on their website.

    Regards,
    Emanuel Balasa

    Senior Network QA Engineer
    CCAI: CCNA, CCNP: BSCI & BCMSN.

  10. [...] to Petr Lapukhov, CCIE #16379 @ Internetworks.com for this Article. Original Post @http://blog.internetworkexpert.com/2008/09/24/mstp-tutorial-part-ii-outside-a-region/ Share and [...]

  11. Divin John says:

    nice Post. Awesome Explaination! thank you Mr. Petr!

  12. Octavio says:

    Hello, Petr.

    I assembled an MSTP lab today, and the following question arose:

    What is the best way to add a new VLAN to the network? After adding the VLAN and having VTP propagate the new VLAN, I have to map it to an instance because it is by default in instance 0, or any other instance but not necesarily in the one I would prefer to map it to.

    Now, at the precise moment I add the vlan to the instance in any of the switches, I will disjoin that switch from the region, as the VLAN configuration is now different. As I start working my way across all switches, I will be effectively be creating a new region and migrating all switches to the new region.

    This will imply recalculation of the STP after each change, since the virtual bridges in the CIST will be constantly changing.

    How does this affect traffic, as to do this kind of changes live? What is the recommended practice for this procedure?

    In the lab, I tried putting a non-manageable switch along with the switches with some loops, and I somehow managed to put the network in an unworking state for one of my VLANs. I haven’t analyzed the output yet, but it worries that the simple operation of adding a vlan and instance mapping, could not be reliably done live anymore.

    Thank you very much in advance.

    • Truly enough, MSTP lacks any configuration propagation protocol. However, as a best practice, in modern networks you would like to avoid large L2 domains, limiting them to a maximum of
      two distribution layer switches. In your situation, by adding new VLAN to every next switch database you will parition the region in two regions, with CIST being used between those two. Unfortunately,
      in a large production network, it hard to predict the result of topology recalculations and changes (e.g. TC floods). You may model the expansion of a new region “on paper” trying to figure our the
      new inter-region root uplink every time.

      As for the best practices, the only thing that comes in mind is pre-provisioning the VLANs. Allocate all your IST instances when planning and desining the network and map enough VLANs to every instance.
      As time passes, you may start using a new VLAN mapped to the instance of interest and avoid adding it to all switches databases. For example vlans 100-200 map to instance 1 and VLANs 300-500 to instances 2,
      with say just VLANs 100-110, and 300-320 used at current time.

  13. Ashish says:

    Hi Peter

    couldnot get a proper understanding on the CST root placement.
    I understand the CST regional root has to be a border switch.

    Question1:
    Is it required that the CST root also be a border switch or it can be any switch having the best BID among all regions and can lie also deep inside a region?

    Question2:
    In regions MST1-15 reach other regions through the master port (IST root port of the border switch). What is the port status of the border port (it will be an IST designatd port) of the region containing the CST root? Will it be also be a master port?

    Question3:
    Can there be multiple border switches forwarding in a region apart from the regional root switch? If they are forwarding then what would be the border port role in that case?

    thanks in advance
    Ahsish

  14. Scotty says:

    Awesome explanation.
    I am studying for my BCMSN and found this site much better at explaining MSTP than the Cisco book.
    Thanks.

  15. James says:

    I have a litle problem that i am messing around whith.

    Basic is that i have 4 switches that are connected whith each 2 ports to 2 other switces.

    I have chosen 1 vlan on each link to be used to L3 between the switches. And i whould like for those 4 vlans never to be blocked.

    How can i ocomplish that using MST ?

    The reason that i need to use MST is that i have around 800 vlan running on those switches. And the convergence is very heavy.

  16. shivlu jain says:

    Hi Petr

    The article is awesome. Please make a changes in the given line
    “Note the following in the above output. First, the local switch has priority value of 16834 , please change 16834 to 16384″

    regards
    shivlu jain

  17. Shridhar says:

    Great Peter. :-)

  18. Rahul says:

    Thanks Petr for a very nice explanation.
    I have a question regarding MSTP – PVST+ inter-operatibility.

    Why is it necessary to replicate VLAN 1 BPDUs for generating PVST BPDUs and vice versa?

    Is it not possible to map the incoming PVST BPDU for a particular VLAN to a specific MSTI instance?
    Basically, is it possible to treat the PVST+ switch just like another switch in the MSTP region, (except that it requires different types of BPDUs)?

    Thanks,
    Rahul

  19. Shridhar says:

    Hi Peter,
    Congratulations for such nice article.
    I have some questions,
    1) For different instances different roles and states assigned. How this internally managed? How to make port enable for particular instance and disable for another instance ?

    2) How exactly communications take place between different regions for same vlan?

    Thanks.

  20. Wassim says:

    this is awesome man! The only true CST/MSTP explanation I have read so far.
    Keep posting such nice stuff ! :)

  21. Shri says:

    Great peter :-)

    Between any two switches of different two regions, can we have more than one link? MEANS Can we have more than one boundary port going towards same switch?

    Thanks in advance .

  22. Ramiro says:

    Hi Petr.

    Thanks in advance for your nice article, and congratulations for your excellent explanation.

    Now, this scenario is applicable for HP Procurve and Cisco environment too?.

    My question is because I read that, allowing the native VLAN across trunk port these two protocols could interoperate.

    Thanks again,

  23. Shri says:

    Hi Peter,
    If we have network with RSTP and MSTP bridges,
    which version (3 or 2) BPDU sends to all directly connected RSTP bridges?

    If its version 3, RSTP bridges supports these BPDU?

  24. Rik says:

    Hi Peter
    thanks for the excellent explanation
    I have a question on MSTP
    I have Cisco with MSTP connected to a 3Com with MSTP too but in different region
    On Cisco output why there is Bound (RSTP) and not p2p?
    Its right or wrong?
    It seems that Cisco see an RSTP peer not a MSTP peer

    SF-A#sh spanning-tree mst

    …………………………………………………
    —————- —- — ——— ——– ——————————–
    Gi3/1 Root FWD 20000 128.129 P2p Bound(RSTP)

    Thank

  25. Rik says:

    Ok I’have read the show you post UP and its right that the output show p2p Bound(RSTP) because it is a boundary port

    If the 3Com had RSTP instead of MSTP what might show the output?

  26. Rik says:

    Ok
    I have read the show you post before and its right that the output show P2p Bound(RSTP) because is a boundary switch
    But if the 3Com had the RSTP instead of MSTP what might be show the cisco output?

  27. Andry Scan says:

    Petr, thanks for the article!
    It helped me when I migrate from PVST to MSTP

  28. [...] MSTP Tutorial Part 2: Outside a Region [...]

  29. Dani Petrov says:

    I just wanted to say that I have never read such a good explanation of this technology. It’s quite, much better even than Cisco’s explanation (which is kinda scant).

    Best regards for all of you guys and two thumbs up for all these posts, which you’re digging for a people who are getting bored while reading all these drily written RFC’s or vendor’s interpretation attempts.

    Best regards,
    Dani

  30. Dustin Cardoza says:

    Another great STP article! This is the BEST explaination of MSTP/PVST+ interop that I’ve seen to date.

  31. jusegi says:

    Excellent work !!!!, thanks for this great work.

    But I still have a question: There is some limit of switches within a region? Can I join 80 switches in a region 1 for example?

    I´ll appreciate your comments.

  32. @jusegi

    Yes you can add 80 switches provided that you change the Hop Count for the network. However, such large network is most likely to be very unstable due to count to infinity problem and huge broadcast domains.

  33. @pnee says:

    when the external root path cost is same to the CIST root bridge from REGION234, how did SW2 can become the root?. Since the external path cost is same, the tiebreaker should be the sender bridge id, right. Since SW4 has a lower sender bid, shouldn’t SW4 be the Regional Root Bridge for REGION 234?.

  34. Luca says:

    This is a good example, i have one question though.
    Is it possible to have a switch running PVST+ as the root for its VLANs, and have the switches in the MST region as the root for their VLANs. So in scenario 3 on this page, have switch 1 as the root for some VLANs and the MST region the root for other VLANs?

 

Leave a Reply

Categories

CCIE Bloggers