MST

MST is a version of STP that is much simpler than PVST, yet I rarely see it implemented. I think a big part of that is due to the fact that there is very little documentation out there, and what is available, well, let’s just say that reading ancient Sumerian would be easier.

MST can appear to be very difficult, but it doesn’t need to be. Like anything technical, if you make it too complicated, it will be difficult to understand, so keep it simple and you’ll do fine. MST can be simpler to configure, easier to manage, often makes more sense (when deployed simply), and uses fewer CPU cycles than PVST. When I discovered that Arista switches were configured with MST as the default, it was love at first sight.

Hey, I never said I was normal.

MST is based on Rapid Spanning Tree Protocol (RSTP), which is a great thing because it offers some great backward compatibility, as you’ll see later in this chapter. You might be thinking, “Well, isn’t PVST multiple Spanning Trees?” And you’d be right, but MST works differently. The problem with PVST is that there’s a Spanning Tree instance running for every VLAN. On an enterprise network comprising 20 or 30 (or even 100) VLANs, that’s not a big deal, but in a data center where there can easily be hundreds of VLANs, things can become problematic.

First, each Spanning Tree instance requires CPU and memory resources, and unless you’re a fan of the old even VLANs on the left and odd VLANs on the right paradigm, all of the VLANs will likely have the same topology anyway. Suppose that you are a fan of splitting your VLANs up between two core switches (I am not); then you have two topologies (assuming that all trunks allow all VLANs, of course). Why have potentially hundreds of Spanning Tree instances running when there are only two topologies?

MST allows you to have one Spanning Tree instance for all your VLANs. Or, if you’re still hell-bent on balancing which switch is the root based on some arbitrary pattern such as even/odd, you can split up your VLANs into instances, each with its own root. Oh, and MST is a standards-based protocol. There are no proprietary things to worry about, and it works with any vendor’s switch that supports it.

The MST documentation goes into painful detail about MST, the Common Spanning Tree (CST), the Internal Spanning Tree (IST), the MSTI, the Common Internal Spanning Tree (CIST), and who knows what else. I explain all this to you later in this chapter and show you why it doesn’t need to be all that difficult. Naturally, I’ll do this in a way that makes sense to me and seems to make sense to people I teach. My goal is not to get you certified; my goal is to make you understand.

Let’s begin with a simple scenario to see how MST works. In Figure 17-1, there are two switches: SW1 and SW2. These two switches are connected together with two links.

Figure 17-1. Two switches connected with two links

Of course, such a topology is a problem because it creates a loop, and loops are bad. Spanning Tree, in its default state on Arista switches, shuts down one of the links, as shown in Figure 17-2. For details about which link is blocked, I recommend the excellent chapter on Spanning Tree in Network Warrior (can that guy write or what?). For now, suffice to say that the blocked port is the interface farthest from the root bridge. In my little network, SW1 won the battle for root bridge status (everything is set to defaults for now), so the e48 interface on SW2 ended up blocking.

Figure 17-2. STP saving the day by breaking the loop

This simple network shouldn’t be a surprise to anyone who has ever used Spanning Tree, but the difference is that out of the box, Arista switches use MST, so let’s take a look at what the switches report.

The command to show STP information is show spanning-tree. Here’s the output for SW1:

SW1#sho spanning-tree
MST0
  Spanning tree enabled protocol mstp
  Root ID    Priority    32768
             Address     2899.3a18.46f1
             This bridge is the root

  Bridge ID  Priority    32768  (priority 32768 sys-id-ext 0)
             Address     2899.3a18.46f1
             Hello Time  2.000 sec  Max Age 20 sec  Forward Delay 15 sec

Interface        Role       State      Cost      Prio.Nbr Type
---------------- ---------- ---------- --------- -------- --------------------
Et47             designated forwarding 2000      128.47   P2p
Et48             designated forwarding 2000      128.48   P2p

This output shows the information we’d need when looking at STP, including the root bridge’s information, which includes the root bridge’s priority (the default is 32,768), the root bridge’s MAC address, this bridge’s priority, this switch’s MAC address, and the status of every interface that has received Bridge Protocol Data Units (BPDUs). This switch shows that it is the root and the bridge information for itself. The ports on this switch are both designated because it’s the root bridge.

Here’s the output for SW2:

SW2#sho spanning-tree
MST0
  Spanning tree enabled protocol mstp
  Root ID    Priority    32768
             Address     2899.3a18.46f1
             Cost        0 (Ext) 2000 (Int)
             Port        47 (Ethernet47)
             Hello Time  2.000 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    32768  (priority 32768 sys-id-ext 0)
             Address     2899.3a26.481d
             Hello Time  2.000 sec  Max Age 20 sec  Forward Delay 15 sec

Interface        Role       State      Cost      Prio.Nbr Type
---------------- ---------- ---------- --------- -------- --------------------
Et47             root       forwarding 2000      128.47   P2p
Et48             alternate  discarding 2000      128.48   P2p

This output clearly shows that interface Et47 is the root port and that interface Et48 is the alternate root port, which is blocking (discarding).

The thing to notice is the first line of output on both switches. On this line, they each say MST0.

MST0 is the default instance in MST. I cover instances in a minute, but the thing to remember now is that MST0 is always on, it’s always active, and every interface forwards MST0 BPDUs. You cannot disable MST0. That will become important later in this chapter, but for now, understand that because MST0 is always on, if you connect two switches running MST together like I have, MST will run and behave as you’d expect.

Let’s change the network so that SW2 is the root bridge by using the command that you likely already known, spanning-tree root primary:

SW2(config)#spanning-tree root primary

This has the almost immediate effect of making SW2 the root. Here’s the proof that the STP bridge priority is now 8,192:

SW2(config)#sho spanning-tree
MST0
  Spanning tree enabled protocol mstp
  Root ID    Priority    8192
             Address     2899.3a26.481d
             This bridge is the root

  Bridge ID  Priority     8192  (priority 8192 sys-id-ext 0)
             Address     2899.3a26.481d
             Hello Time  2.000 sec  Max Age 20 sec  Forward Delay 15 sec

Interface        Role       State      Cost      Prio.Nbr Type
---------------- ---------- ---------- --------- -------- --------------------
Et47             designated forwarding 2000      128.47   P2p
Et48             designated forwarding 2000      128.48   P2p

I say almost immediate because MST is fast. I’ve done mass switch migrations to MST and was amazed that after changing more than 200 switches, we never once noticed an outage or disruption of service. Like RSTP, MST has much tighter timers than traditional Spanning Tree. This speed is one of the things that I like about MST, and it is one of the reasons that I recommend its use.

Another way to change the priority is by using the spanning-tree priority priority-value command. Here, I goose up the priority a notch to 4,096:

SW2(config)#spanning-tree priority 4096
SW2(config)#sho spanning-tree
MST0
  Spanning tree enabled protocol mstp
  Root ID    Priority    4096
             Address     2899.3a26.481d
             This bridge is the root

  Bridge ID  Priority     4096  (priority 4096 sys-id-ext 0)
             Address     2899.3a26.481d
             Hello Time  2.000 sec  Max Age 20 sec  Forward Delay 15 sec

Interface        Role       State      Cost      Prio.Nbr Type
---------------- ---------- ---------- --------- -------- --------------------
Et47             designated forwarding 2000      128.47   P2p
Et48             designated forwarding 2000      128.48   P2p

Note that the global spanning-tree priority command works only on MST0, which will make more sense in a bit.

To that end, I’d like to make SW1 the root bridge again because I can’t sleep knowing that a higher numbered switch (SW2 versus SW1) is in charge. I just negate the commands, and MST will recalculate:

SW2(config)#no spanning-tree priority 4096
SW2(config)#no spanning-tree root primary
SW2(config)#sho spanning-tree
MST0
  Spanning tree enabled protocol mstp
  Root ID    Priority    32768
             Address     2899.3a18.46f1
             Cost        0 (Ext) 2000 (Int)
             Port        47 (Ethernet47)
             Hello Time  2.000 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    32768  (priority 32768 sys-id-ext 0)
             Address     2899.3a26.481d
             Hello Time  2.000 sec  Max Age 20 sec  Forward Delay 15 sec

Interface        Role       State      Cost      Prio.Nbr Type
---------------- ---------- ---------- --------- -------- --------------------
Et47             root       forwarding 2000      128.47   P2p
Et48             alternate  discarding 2000      128.48   P2p

One of the things that is not terribly obvious is that MST does not care about VLANs in its default state. Whenever I explain MST to someone, this is one of the most difficult things for them to wrap their heads around, likely because we’ve all used PVST for so long.

Remember when I wrote that MST0 is active on all interfaces at all times? This is because MST, in its basic form, has no concept of VLANs. So long as MST0 can see another bridge (or BPDUs from that bridge, to be precise), there’s a link to that bridge, and MST will act accordingly.

One of the other things special about MST0 is that it will interact with a switch that’s running RPVST. How can it do this if it doesn’t comprehend VLANs? That depends on the vendor, but in a nutshell, the switches will interoperate because MST is based on RSTP.

On a Cisco switch, MST0 sends identical BPDUs out every VLAN on every interface. How is that not RPVST? The difference is that it sends the same BPDU out every VLAN (that of MST0), not VLAN-specific BPDUs. This is a very important distinction to understand because it can bite you if you’re not careful. With the Cisco model, if you configure MST0 with a priority of 4,096, it will likely become the root bridge on every VLAN on an attached PVST switch.

Arista switches only send MST0 BPDUs on the default VLAN (VLAN1 by default). Because I had first used MST on Cisco switches and had grown accustomed to the way they sent BPDUs on every VLAN, I was convinced that I had found a bug when my Arista switches didn’t behave the same way. When I talked to the folks at Arista about it, they pointed out that there is nothing in the RFCs that specifies BPDUs for MST0 being sent out every VLAN.

So, what does this all mean for you in the real world? Let’s take a look. I’ve built a small lab with three switches (SW1, SW2, and SW3), as shown in Figure 17-3. SW1 has a priority of 8,192, SW2 has a priority of 32,768 (the default), and SW3 (the one in the middle of the drawing) has a priority of 4,096. There is one VLAN configured on all three switches: VLAN 100. The links between the switches are trunks with all VLANs permitted.

Figure 17-3. RPVST split by MST using Arista switches

If all three of these switches were running Rapid PVST, SW3 would be the root for all VLANs. With MST thrown in the middle, things change a bit, and unless you’re careful, the results can surprise you. To further understand this, know that the links between each switch are trunks and that VLAN 100 had been configured on all three switches.

First, let’s take a quick look at SW3 in the middle:

SW3#sho spanning-tree
MST0
  Spanning tree enabled protocol mstp
  Root ID    Priority    4096
             Address     2899.3a06.6c09
             This bridge is the root

  Bridge ID  Priority     4096  (priority 4096 sys-id-ext 0)
             Address     2899.3a06.6c09
             Hello Time  2.000 sec  Max Age 20 sec  Forward Delay 15 sec

Interface        Role       State      Cost      Prio.Nbr Type
---------------- ---------- ---------- --------- -------- --------------------
Et1              designated forwarding 2000      128.1    P2p Boundary
Et2              designated forwarding 2000      128.2    P2p Boundary

Looks simple enough. This bridge is the root, and other than it having a priority of 4,096, it appears as if the switch is pretty much in a default configuration. Now let’s take a look at SW2, which is running RPVST:

SW2#sho spanning-tree
VL1
  Spanning tree enabled protocol rapid-pvst
  Root ID    Priority    4096
             Address     2899.3a06.6c09
             Cost        2000 (Ext) 0 (Int)
             Port        34 (Ethernet34)
             Hello Time  2.000 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    32769  (priority 32768 sys-id-ext 1)
             Address     2899.3a26.481d
             Hello Time  2.000 sec  Max Age 20 sec  Forward Delay 15 sec

Interface        Role       State      Cost      Prio.Nbr Type
---------------- ---------- ---------- --------- -------- --------------------
Et34             root       forwarding 2000      128.34   P2p

VL100
  Spanning tree enabled protocol rapid-pvst
  Root ID    Priority    32868
             Address     2899.3a18.46f1
             Cost        2000 (Ext) 0 (Int)
             Port        34 (Ethernet34)
             Hello Time  2.000 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    32868  (priority 32768 sys-id-ext 100)
             Address     2899.3a26.481d
             Hello Time  2.000 sec  Max Age 20 sec  Forward Delay 15 sec

Interface        Role       State      Cost      Prio.Nbr Type
---------------- ---------- ---------- --------- -------- --------------------
Et34             root       forwarding 2000      128.34   P2p

Certainly, the output of the show spanning-tree command is different due to this switch running RPVST instead of MST, but look at the VLANs and their respective root bridges. VLAN1 (the default VLAN) shows that SW3 is the root, whereas VLAN 100 shows SW1 to be the root. This is due to the fact that MST does not send out BPDUs on every VLAN, only the default VLAN (VLAN1 in this example).

Now let’s look at SW1. Can you guess what it will show?

SW1#sho spanning-tree
VL1
  Spanning tree enabled protocol rapid-pvst
  Root ID    Priority    4096
             Address     2899.3a06.6c09
             Cost        2000 (Ext) 0 (Int)
             Port        34 (Ethernet34)
             Hello Time  2.000 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    32769  (priority 32768 sys-id-ext 1)
             Address     2899.3a18.46f1
             Hello Time  2.000 sec  Max Age 20 sec  Forward Delay 15 sec

Interface        Role       State      Cost      Prio.Nbr Type
---------------- ---------- ---------- --------- -------- --------------------
Et34             root       forwarding 2000      128.34   P2p

VL100
  Spanning tree enabled protocol rapid-pvst
  Root ID    Priority    32868
             Address     2899.3a18.46f1
             This bridge is the root

  Bridge ID  Priority    32868  (priority 32768 sys-id-ext 100)
             Address     2899.3a18.46f1
             Hello Time  2.000 sec  Max Age 20 sec  Forward Delay 15 sec

Interface        Role       State      Cost      Prio.Nbr Type
---------------- ---------- ---------- --------- -------- --------------------
Et34             designated forwarding 2000      128.34   P2p

SW1 shows that, again, SW3 is the root for VLAN1, but SW1 is the root for all the remaining VLANs! It’s almost like RPVST BPDUs were tunneled through MST or something. In a way, that’s not far from the truth.

SW3 is the root on VLAN1 for the same reason that SW1 saw SW3 as the root. Because MST operates on the default VLAN, this makes perfect sense.

RPVST (all forms of STP, really) uses a multicast MAC address (01:80:C2:00:00:00) to send BPDUs on all VLANs. Switches not configured for multicast flood these packets out all ports on the respective VLAN, so when SW1 and SW2 send out its BPDUs, SW3 forwards them, but doesn’t process them because MST does not listen for BPDUs on VLANs other than the default. The BPDUs from SW1 are then received by SW2, and vice versa, after which each switch on the outer edges processes them due to them running RPVST.

This behavior is different than what you would see with a Cisco switch in the middle. With a Cisco switch running MST in the middle (configured with the same priority of 4,096), the Cisco switch would become the root bridge for all VLANs. This is due to the fact that Cisco enhanced the MST protocol to have this effect.

OK, so MST0 works as expected, and it’s simple, and we know how to change the root bridge. We’ve seen how it behaves with RPVST attached, which is interesting, but for many environments, that’s good enough. Let’s dig in a bit and see how a more complicated scenario might look.

MST0 is only the tip of the iceberg when it comes to MST. Though MST is not a PVST in the sense that BPDUs are not sent out every VLAN, it has the ability to separate groups of VLANs into separate Spanning Trees. How is that different than PVST? I like to describe it as being a per-instance Spanning Tree as opposed to a per-VLAN Spanning Tree. Imagine that you have 400 VLANs active on your network. With PVST, you would have 400 Spanning Trees active, each with its own root bridge and each one sending out BPDUs aplenty.

With MST, BPDUs are only ever sent over VLAN1 (by default), but VLANs can be grouped into MST instances. For example, you could put VLAN 100 into MST1, 200 into MST2, 300 into MST3, and 400 to 499 into MST4.

With your VLANs grouped like this, you could still do some manual splitting by making one core switch the root for MST1 and MST3, whereas another switch could be the root for MST2 and MST4. As I wrote earlier, I’m not a fan of this type of manual balancing, but I do like to have options, and my customers’ desires often override my recommendations, anyway. This is generally a bad idea with MST, though, and the documentation states that there is no benefit to overlapping instances. Because I learn best by breaking things, let’s see what happens when we try.

To keep things simple, I use the network in Figure 17-4 for the next examples. This network has only three VLANs—VLAN 100, 200, and 300—all of which are active on all switches and trunked on all links. Note that these are the same switches I used earlier, and I’ve just changed the connections to form a loop while also configuring all three switches for MST.

Figure 17-4. Simple MST network

To start things off, I need to put all three switches into MST mode:

SW1(config)#spanning-tree mode mstp
SW2(config)#spanning-tree mode mstp
SW3(config)#spanning-tree mode mstp

Next, I’m going to create a new MST instance on SW1. Many of the commands for MST are done in the spanning-tree mst configuration mode. Like many other such modes, changes do not take effect until you exit the mode:

SW1(config)#spanning-tree mst configuration
SW1(config-mst)#

To add a new MST instance, use the command instance, followed by the instance number, and then the VLANs to be included in the instance. To place VLAN 100 into MST instance 1, I use the instance 1 vlan 100 command. Note that VLANs can be listed individually, separated by commas, or listed as ranges:

SW1(config-mst)#instance 1 vlans 100

Now, I put VLANs 200 and 300 into MST instance 2:

SW1(config-mst)#instance 2 vlans 200,300

After I exit, spanning-tree will be configured, and I should see three instances in MST instead of one:

SW1(config-mst)#^z
SW1#sho spanning-tree
MST0
  Spanning tree enabled protocol mstp
  Root ID    Priority    4096
             Address     2899.3a06.6c09
             Cost        2000 (Ext) 0 (Int)
             Port        34 (Ethernet34)
             Hello Time  2.000 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority     8192  (priority 8192 sys-id-ext 0)
             Address     2899.3a18.46f1
             Hello Time  2.000 sec  Max Age 20 sec  Forward Delay 15 sec

Interface        Role       State      Cost      Prio.Nbr Type
---------------- ---------- ---------- --------- -------- --------------------
Et34             root       forwarding 2000      128.34   P2p Boundary
Et48             alternate  discarding 2000      128.48   P2p Boundary

MST1
  Spanning tree enabled protocol mstp
  Root ID    Priority    32769
             Address     2899.3a18.46f1
             This bridge is the root

  Bridge ID  Priority    32769  (priority 32768 sys-id-ext 1)
             Address     2899.3a18.46f1
             Hello Time  2.000 sec  Max Age 20 sec  Forward Delay 15 sec

Interface        Role       State      Cost      Prio.Nbr Type
---------------- ---------- ---------- --------- -------- --------------------
Et34             master     forwarding 2000      128.34   P2p Boundary
Et48             alternate  discarding 2000      128.48   P2p Boundary

MST2
  Spanning tree enabled protocol mstp
  Root ID    Priority    32770
             Address     2899.3a18.46f1
             This bridge is the root

  Bridge ID  Priority    32770  (priority 32768 sys-id-ext 2)
             Address     2899.3a18.46f1
             Hello Time  2.000 sec  Max Age 20 sec  Forward Delay 15 sec

Interface        Role       State      Cost      Prio.Nbr Type
---------------- ---------- ---------- --------- -------- --------------------
Et34             master     forwarding 2000      128.34   P2p Boundary
Et48             alternate  discarding 2000      128.48   P2p Boundary

MST0 still sees SW3 as the root from my earlier example, but all of the other instances show SW1 to be the root. This is because the other VLANs are in different MST regions on this switch than they are on the other two. An MST region is basically what is formed when one or more switches connect and agree upon their instance mappings. Think of a region as the same instances combining across switches.

This is where MST confuses people, so hang on and let’s examine what’s really happening. To make things a bit clearer, Figure 17-5 shows a visual representation of what’s happening.

Figure 17-5. MST network with overlapping regions

First, MST0 continues to function the way it always has. MST1 and MST2 are new regions, but they exist only on SW1. Also given the way that MST works, they sort of overlap, as shown in Figure 17-5. If you think that’s bad, you’re right, but in this example so far it continues to work. What happens to the VLANs that we mapped to MST1 and MST2 on switches SW2 and SW3? Let’s take a look. Here’s SW2:

SW2(config)#sho spanning-tree
MST0
  Spanning tree enabled protocol mstp
  Root ID    Priority    4096
             Address     2899.3a06.6c09
             Cost        0 (Ext) 2000 (Int)
             Port        34 (Ethernet34)
             Hello Time  2.000 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    32768  (priority 32768 sys-id-ext 0)
             Address     2899.3a26.481d
             Hello Time  2.000 sec  Max Age 20 sec  Forward Delay 15 sec

Interface        Role       State      Cost      Prio.Nbr Type
---------------- ---------- ---------- --------- -------- --------------------
Et34             root       forwarding 2000      128.34   P2p      
Et48             designated forwarding 2000      128.48   P2p Boundary

And here is SW3:

SW3(config)#sho spanning-tree
MST0
  Spanning tree enabled protocol mstp
  Root ID    Priority    4096
             Address     2899.3a06.6c09
             This bridge is the root

  Bridge ID  Priority     4096  (priority 4096 sys-id-ext 0)
             Address     2899.3a06.6c09
             Hello Time  2.000 sec  Max Age 20 sec  Forward Delay 15 sec

Interface        Role       State      Cost      Prio.Nbr Type
---------------- ---------- ---------- --------- -------- --------------------
Et1              designated forwarding 2000      128.1    P2p Boundary
Et2              designated forwarding 2000      128.2    P2p

So, they both see SW3 as the root, just like SW1 did, but they show only MST0. There are some other interesting things going on here, so let’s look at what’s really, really happening.

You might see that some of the interfaces show up as boundary ports. A boundary port is one that connects one MST region to another, but looking at SW3 in MST0, why is Ethernet 1 a boundary port when it’s connecting to SW1, which also has MST0 configured? This is the part of MST that I think is a bit complicated, so stay with me.

Yes, all three switches have an MST0 configured, and MST0 is where all of the VLANs are mapped by default. However, there is another layer of organization going on that’s not necessarily obvious looking at the configurations or the command output. The thing to note is that just because two switches are configured with the same MST instance number, this doesn’t mean that they will form into the same region. In fact, if any of the following parameters are different, two switches with the same MST instance will form separate regions (and here’s the rub) that will have the same MST instance identifier! The configurations that must match in order for two switches to form a region are the following:

• Instance to VLAN mapping

• Configuration name

Because MST0 on our three switches are configured differently, Figure 17-6 shows what the network actually looks like.

Figure 17-6. Actual MST regions formed based on our configuration thus far

Looking at this frightening diagram we can see that there are actually two different MST0 regions! That’s why we see boundary ports on our switches in MST0:

 SW3#sho spanning-tree
MST0
  Spanning tree enabled protocol mstp
  Root ID    Priority    4096
             Address     2899.3a06.6c09
             This bridge is the root

  Bridge ID  Priority     4096  (priority 4096 sys-id-ext 0)
             Address     2899.3a06.6c09
             Hello Time  2.000 sec  Max Age 20 sec  Forward Delay 15 sec

Interface        Role       State      Cost      Prio.Nbr Type
---------------- ---------- ---------- --------- -------- --------------------
Et1              designated forwarding 2000      128.1    P2p Boundary
Et2              designated forwarding 2000      128.2    P2p

There are a few common scenarios that will result in boundary ports. First, when a switch configured with Spanning Tree protocol other than MST is attached, the port will be put into a boundary state. Look at the example in Figure 17-3 in which I put an MST switch in the middle of two RPVST switches, and you’ll see two boundary ports. These ports are a result of MST being connected to RPVST switches.

This is the kind of thing that can easily be missed by network engineers who aren’t seasoned in MST. Again, even though they’re all configured with an MST0, they’re not all in the same region.

This is explained through another couple of initialisms from the MST lexicon: CST and the CST and the CIST. If you look at Figure 17-6, you’ll see that the MST0 that’s connecting SW2 and SW3 is labeled as the CIST—this is the CST that’s connecting these two MST0s into a region because there was really nothing configured. The larger MST0 is the CST and is what connects all of the regions together, including the MST0 CIST. It can help to think of the CST as sort of the global Spanning Tree. Note that if we had left all three switches with default configurations, they would all be in the same CIST and there would not be the need for a CST. As soon as we connected any of those switches to another region or to a RPVST-enabled switch, boundary ports would form and there would be a CST.

This entire CST/CIST thing is not configured but is part of the way that MST operates. Understanding the way that MST forms regions, though, makes it clearer that there is a sort of hierarchy of Spanning Trees that are built by MST without your intervention. Understanding this hierarchy is the key to understanding MST.

To pound this point home, I’m going to configure SW1 to be the root for all of our new MST instances (but not MST0). This is done in global configuration mode with the spanning-tree mst instance-number priority priority-value command. You can also specify the word root instead of priority priority-value. Here I do both:

SW1(config)#spanning-tree mst 1 root primary
SW1(config)#spanning-tree mst 2 priority 8192

Another reason that ports will be configured as boundary ports is when MST is running on both switches, but the instances don’t match. When attached switches are in the same MST instance, they form a region. To be painfully accurate, to form a region, the switches need to have matching instances, with matching VLAN-to-region mapping and the same configuration names. This leads me to one of the main points of confusion (and misconfiguration) I’ve seen in the field when using MST. Let me show you what I mean, because it’s easier to see firsthand. In the next code snippet, I configure SW2 to have the same MST–VLAN mappings, but I add a configuration name, which will force the switches to be in different regions, even though they have the same instance numbers:

SW2(config)#spanning-tree mst configuration
SW2(config-mst)#instance 1 vlan 100
SW2(config-mst)#instance 2 vlan 200,300
SW2(config-mst)#name Switch2
SW2(config-mst)#exit

Here’s how SW2 sees its world with regard to Spanning Tree:

SW2(config)#sho spanning-tree
MST0
  Spanning tree enabled protocol mstp
  Root ID    Priority    4096
             Address     2899.3a06.6c09
             Cost        2000 (Ext) 0 (Int)
             Port        34 (Ethernet34)
             Hello Time  2.000 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    32768  (priority 32768 sys-id-ext 0)
             Address     2899.3a26.481d
             Hello Time  2.000 sec  Max Age 20 sec  Forward Delay 15 sec

Interface        Role       State      Cost      Prio.Nbr Type
---------------- ---------- ---------- --------- -------- --------------------
Et34             root       forwarding 2000      128.34   P2p Boundary
Et48             alternate  discarding 2000      128.48   P2p Boundary

MST1
  Spanning tree enabled protocol mstp
  Root ID    Priority    32769
             Address     2899.3a26.481d
             This bridge is the root

  Bridge ID  Priority    32769  (priority 32768 sys-id-ext 1)
             Address     2899.3a26.481d
             Hello Time  2.000 sec  Max Age 20 sec  Forward Delay 15 sec

Interface        Role       State      Cost      Prio.Nbr Type
---------------- ---------- ---------- --------- -------- --------------------
Et34             master     forwarding 2000      128.34   P2p Boundary
Et48             alternate  discarding 2000      128.48   P2p Boundary

MST2
  Spanning tree enabled protocol mstp
  Root ID    Priority    32770
             Address     2899.3a26.481d
             This bridge is the root

  Bridge ID  Priority    32770  (priority 32768 sys-id-ext 2)
             Address     2899.3a26.481d
             Hello Time  2.000 sec  Max Age 20 sec  Forward Delay 15 sec

Interface        Role       State      Cost      Prio.Nbr Type
---------------- ---------- ---------- --------- -------- --------------------
Et34             master     forwarding 2000      128.34   P2p Boundary
Et48             alternate  discarding 2000      128.48   P2p Boundary

Now SW2 is isolated, and all of its interfaces are boundary ports! Let’s remove that name and see if we can get it to sync with SW1’s config thus forming a region between MST1 and MST2:

SW2(config)#spanning-tree mst configuration
SW2(config-mst)#no name Switch2
SW2(config-mst)#^z
SW2#
SW2#sho spanning-tree
MST0
  Spanning tree enabled protocol mstp
  Root ID    Priority    4096
             Address     2899.3a06.6c09
             Cost        2000 (Ext) 2000 (Int)
             Port        48 (Ethernet48)
             Hello Time  2.000 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    32768  (priority 32768 sys-id-ext 0)
             Address     2899.3a26.481d
             Hello Time  2.000 sec  Max Age 20 sec  Forward Delay 15 sec

Interface        Role       State      Cost      Prio.Nbr Type
---------------- ---------- ---------- --------- -------- --------------------
Et34             alternate  discarding 2000      128.34   P2p Boundary
Et48             root       forwarding 2000      128.48   P2p

MST1
  Spanning tree enabled protocol mstp
  Root ID    Priority    8193
             Address     2899.3a18.46f1
             Cost        2000
             Port        48 (Ethernet48)
             Hello Time  0.000 sec  Max Age  0 sec  Forward Delay  0 sec

  Bridge ID  Priority    32769  (priority 32768 sys-id-ext 1)
             Address     2899.3a26.481d
             Hello Time  2.000 sec  Max Age 20 sec  Forward Delay 15 sec

Interface        Role       State      Cost      Prio.Nbr Type
---------------- ---------- ---------- --------- -------- --------------------
Et34             alternate  discarding 2000      128.34   P2p Boundary
Et48             root       forwarding 2000      128.48   P2p

MST2
  Spanning tree enabled protocol mstp
  Root ID    Priority    8194
             Address     2899.3a18.46f1
             Cost        2000
             Port        48 (Ethernet48)
             Hello Time  0.000 sec  Max Age  0 sec  Forward Delay  0 sec

  Bridge ID  Priority    32770  (priority 32768 sys-id-ext 2)
             Address     2899.3a26.481d
             Hello Time  2.000 sec  Max Age 20 sec  Forward Delay 15 sec

Interface        Role       State      Cost      Prio.Nbr Type
---------------- ---------- ---------- --------- -------- --------------------
Et34             alternate  discarding 2000      128.34   P2p Boundary
Et48             root       forwarding 2000      128.48   P2p

Ah-ha! The status of interface Et48 has gone from alternate to root, and from discarding to forwarding, and the type is now P2p and no longer P2p Boundary. This is what an MST instance should look like when paired with a switch in the same region.

Now that we took care of interface Et48, what’s up with Et34? Remember, Et34 is connected to SW3, and we haven’t configured that switch with MST1 or MST2 yet. Because SW2 is configured for MST1, it sees that interface as active in the instance. Because the attached switch on that interface is not configured to be in this instance (and also name and VLAN map), the switch considers it to be in a different region, and thus, the port is in a P2p Boundary state. Let’s go ahead and put SW3 into the same MST configuration, and all of our ports should become state P2p.

First, here’s the output of show spanning-tree on SW3:

SW3#sho spanning-tree
MST0
  Spanning tree enabled protocol mstp
  Root ID    Priority    4096
             Address     2899.3a06.6c09
             This bridge is the root

  Bridge ID  Priority     4096  (priority 4096 sys-id-ext 0)
             Address     2899.3a06.6c09
             Hello Time  2.000 sec  Max Age 20 sec  Forward Delay 15 sec

Interface        Role       State      Cost      Prio.Nbr Type
---------------- ---------- ---------- --------- -------- --------------------
Et1              designated forwarding 2000      128.1    P2p Boundary
Et2              designated forwarding 2000      128.2    P2p Boundary

So, SW3 is the root for MST0 and has no other configuration yet. It sees both its ports as P2p Boundary ports because there are switches attached with different instance VLAN maps. Let’s change that by getting SW3 in line with the other two:

SW3(config)#spanning-tree mst configuration
SW3(config-mst)#instance 1 vlan 100
SW3(config-mst)#instance 2 vlan 200,300
SW3(config-mst)#exit

Let’s see how that’s affected the Spanning Tree. Here’s the output of the command show spanning-tree on SW3 after these changes:

SW3(config)#sho spanning-tree
MST0
  Spanning tree enabled protocol mstp
  Root ID    Priority    4096
             Address     2899.3a06.6c09
             This bridge is the root

  Bridge ID  Priority     4096  (priority 4096 sys-id-ext 0)
             Address     2899.3a06.6c09
             Hello Time  2.000 sec  Max Age 20 sec  Forward Delay 15 sec

Interface        Role       State      Cost      Prio.Nbr Type
---------------- ---------- ---------- --------- -------- --------------------
Et1              designated forwarding 2000      128.1    P2p
Et2              designated forwarding 2000      128.2    P2p

MST1
  Spanning tree enabled protocol mstp
  Root ID    Priority    8193
             Address     2899.3a18.46f1
             Cost        2000
             Port        1 (Ethernet1)
             Hello Time  0.000 sec  Max Age  0 sec  Forward Delay  0 sec

  Bridge ID  Priority    32769  (priority 32768 sys-id-ext 1)
             Address     2899.3a06.6c09
             Hello Time  2.000 sec  Max Age 20 sec  Forward Delay 15 sec

Interface        Role       State      Cost      Prio.Nbr Type
---------------- ---------- ---------- --------- -------- --------------------
Et1              root       forwarding 2000      128.1    P2p
Et2              designated forwarding 2000      128.2    P2p

MST2
  Spanning tree enabled protocol mstp
  Root ID    Priority    8194
             Address     2899.3a18.46f1
             Cost        2000
             Port        1 (Ethernet1)
             Hello Time  0.000 sec  Max Age  0 sec  Forward Delay  0 sec

  Bridge ID  Priority    32770  (priority 32768 sys-id-ext 2)
             Address     2899.3a06.6c09
             Hello Time  2.000 sec  Max Age 20 sec  Forward Delay 15 sec

Interface        Role       State      Cost      Prio.Nbr Type
---------------- ---------- ---------- --------- -------- --------------------
Et1              root       forwarding 2000      128.1    P2p
Et2              designated forwarding 2000      128.2    P2p

Huzzah! SW3 is still the root for MST0, but it sees SW1 as the root for MST1 and MST2. All ports are in a P2p state, and there are no boundary ports in any instances. Let’s take a look at MST1 on SW1 and then on SW2:

SW1#sho spanning-tree mst 1
##### MST1    vlans mapped:    100
Bridge        address 2899.3a18.46f1  priority      8193 (8192 sysid 1)
Root          this switch for MST1


Interface        Role       State      Cost      Prio.Nbr Type
---------------- ---------- ---------- --------- -------- --------------------
Et34             designated forwarding 2000      128.34   P2p
Et48             designated forwarding 2000      128.48   P2p

No boundary ports anymore!

Here’s the output from SW2:

SW2#sho spanning-tree mst 1
##### MST1    vlans mapped:    100
Bridge        address 2899.3a26.481d  priority      32769 (32768 sysid 1)
Root          address 2899.3a18.46f1  priority      8193 (8192 sysid 1)

Interface        Role       State      Cost      Prio.Nbr Type
---------------- ---------- ---------- --------- -------- --------------------
Et34             alternate  discarding 2000      128.34   P2p
Et48             root       forwarding 2000      128.48   P2p

And again, this switch has no more boundary ports. This is the way MST should look when all your switches are configured to be in the same region.

MST Terminology

Let me take a moment and describe how all of these instances and regions interact. To help us along, let’s define some terms. I’ve already used most of these terms in the chapter, so most of this should be apparent by now:

Instance

This is a group of VLANs mapped into a single Spanning Tree. Instance numbers can be within the range of 1 to 4,096. There can be as many as 16 instances configured on a switch.

MSTI

This is a technical term for any MST instance other than instance 0.

Region

A region is one or more switches (technically, bridges) connected together that are configured with the same VLAN instance maps, the same configuration name, and the same configuration revision (all of these are configured within the spanning-tree mst configuration mode).

CST

The Common Spanning Tree is what we’ve seen as MST instance 0 (MST0). The CST is the means whereby regions are interconnected.

IST

Internal Spanning Tree is used on instance 0 (MST0, or the CST) for the inter-instance Spanning Tree. Consider it to be the Spanning Tree that connects all of the regions together.

CIST

The Common and Internal Spanning Tree comprises all regions, along with the CST (MST0).

It took me a long time to get this all straight, likely because I’ve spent too much of my life thinking about girls and guitars and not enough time studying, but I’ve come up with some comparisons that work for me and seem to help other people, as well.

To put all of this stuff into perspective, take a look at Figure 17-7. In this drawing, the large oval represents the CIST because it contains everything within it. Within the CIST, there are three smaller circles. These circles each represent an MST region. The final configuration from my example earlier in this chapter resulted in a single region. Before there was a single region, there were multiple regions due to the mismatched instance VLAN maps and the temporarily entered configuration name. Where regions connect with other regions, they do so at CIST boundary ports, which we saw in the earlier example.

Figure 17-7. Multiple MST regions interconnected with MST0

If you’re familiar with Border Gateway Protocol (BGP), each region is sort of like a BGP confederation, in that the region behaves like a single bridge in relation to other regions. Because each region has its own root, the topology within the region is distinct from the topology outside of the region. The topology between regions is distinct from the topology within regions. I like to call each of the regions a super switch when teaching people who are not familiar with BGP, which is completely inaccurate, but it gets the point across. The way the CST (MST0) sees the regions shown in Figure 17-7 is represented in Figure 17-8.

One of the huge benefits of MST is that each region becomes its own failure domain. I used this behavior to solve an environment that had three data centers all bridged together with dark fiber. These three data centers had been designed into a loop and all of the inter–data center links were configured as trunk all. It was a nightmare and STP was reconverging constantly. By implementing MST and making each data center its own region, the inter–data center topology changes stopped altogether because each data center had its own Spanning Tree. In MST parlance, each data center was its own region and thus had its own CIST. This provided a huge stability boost in the environment.

Figure 17-8. Regions as seen by the CST (MST0)

As I warned earlier, it’s easy to configure switches into their own region without realizing it. When I design an MST-based network, I like to make each instance into its own region where possible, because this makes it easier for junior engineers to visualize what’s going on. Because the regions aren’t really identified in the output of the spanning-tree commands, I like to separate using very logical groupings such as data center, row, floor, or something easy to understand. Now, this might not be possible in your network, especially if you’re a fan of balancing even/odd VLANs between core switches. Still, so long as the instance VLAN mapping remains consistent and the configuration names and revisions match, getting your regions mapped should be relatively straightforward. That having been said, here’s some advice that will help when using MST:

• As Einstein said, make it as simple as possible, but no simpler. The more complicated you make your MST design, the more difficult it will be to understand.

• There aren’t really benefits to running multiple regions unless you have a very complicated network. Where I have physically disparate networks in the same building, I’ll put them into different instance numbers, so that if they ever do become connected, they will form boundary ports and won’t just extend the region.

• One of the ways I like to use regions is when L2 networks span physical buildings. I have a client that has VLANs spanning four buildings. By limiting the interbuilding connectivity, and making each building its own region, the building itself becomes a super switch and any improper new links between buildings will affect only the CST topology and not the topology within the building.

• If your network is small, consider a single MST instance with a single region. Though you shouldn’t keep everything in MST0, placing all of your switches and all of your VLANs into MST1 isn’t necessarily a bad thing..

Pruning VLANs with MST

This little tip is one of those things that people seem to learn the hard way. Let’s see if I can help you avoid the pain and misery that can occur when you inadvertently split VLANs with MST. Don’t ask me how I know about the pain and suffering. You’ll just have to take my word on that part.

Figure 17-9 shows a simple network that looks a lot like the one I’ve used previously in this chapter. In this network, there are three switches and two VLANs. PC-A, connected to SW2, is on VLAN 300, as is PC-B, which is on SW3. The links between the switches are trunks, but the link between SW2 and SW3 does not have VLAN 300 allowed.

Figure 17-9. Pruned trunks in a PVSTP network

The point of this lesson is to remember that MST does not care about VLANs, only instances, and instances generally contain multiple VLANs. In this network, with PVST, VLAN 300 has no loop, but VLAN 100 does, so only VLAN 100 has a blocked port. That’s OK, because there is an alternate path, and all traffic can flow on all VLANs.

Figure 17-10 shows the same network with MST running on all switches. In this example, all switches are configured properly in MST1, and they are all in the same region. Because MST doesn’t care about VLANs and only loops within regions, the link between SW1 and SW2 will be blocked, which will cause PC-A to no longer have a path to PC-B. We have a special term for this in networking: it’s called bad.

Figure 17-10. Simple, broken network thanks to my trunk-pruning ineptitude

There are a couple of ways to prevent this from happening. If all of these switches truly belong in the same region, you could stop pruning VLAN 300 from the SW2–SW3 link. Pruning can be a great way to limit traffic on links, but in this network, I doubt that VLAN 300 really needed to be pruned in the first place. That’s of little comfort, though, when it worked before you converted to MST and now it doesn’t. It turns out that some executives are really sensitive about things like networks working after a change.

Another way to resolve this problem is to put VLAN 100 in one MST instance and VLAN 300 in another. Then, the VLAN 100 instance would block the SW1–SW2 link as shown, but the VLAN 300 instance would have no ports blocked, since that instance would not see a loop. Watch out for overly complex instance VLAN maps, though, because making things complicated leads to switches in different regions when you’re not careful about matching MST configurations.

Conclusion

The Multiple Spanning Tree Protocol is a next-generation Spanning Tree that you should absolutely get to know. Even though it can seem more complex, in practice it isn’t, provided that you design the network with logic and simplicity in mind. And really, shouldn’t all networks be designed that way?