STP convergence – MST – Daniels Networking Blog

In the comments I received a wish to compare RPVST+ with MST.
RPVST+ is Ciscos proprietary STP running one instance per VLAN over
802.1Q trunks. MST is an industry standard which can run multiple
instances but not one per VLAN. MST does run RSTP as underlying
protocol so in theory there should be no difference at all. Let’s
give it a try. The topology is very similar to last time but a couple
of extra routers are involved. We’ll get back to these later. This is
the topology:

These are the current port roles:

I just have put some basic MST configuration and NTP on the switches.

SW3(config)#ntp server 13.13.13.1
SW3(config)#span mode mst
SW3(config)#span mst 0 prio 16384
SW3(config)#span mst 1 prio 16384
SW3(config)#span mst conf
SW3(config-mst)#name TST       
SW3(config-mst)#revision 1

Verify initial reachability between the routers.

R1#ping 13.13.13.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 13.13.13.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

R2#ping 25.25.25.5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 25.25.25.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms

Now let’s shutdown Gi0/21 on SW3 which is leading to SW2 root port.
Debug spanning-tree events will show the sequence of events.

May  7 20:32:18.975: MST[0]: Fa0/21 state change forwarding -> disabled
May  7 20:32:18.975: MST[0]: updt roles, root port Fa0/21 going down
May  7 20:32:18.975: MST[0]: Fa0/23 is now root port
May  7 20:32:18.975: MST[0]: Fa0/21 state change disabled -> blocking
May  7 20:32:18.975: MST[0]: Fa0/23 state change blocking -> forwarding
May  7 20:32:18.979: MST[0]: sending proposal on Fa0/3
May  7 20:32:18.983: MST[0]: sending proposal on Fa0/5

The switchover is immediate as expected. Now let’s try to simulate passive
error by implementing BPDU filter.

SW3(config-if)#span bpdufilter enable
SW3(config-if)#do sh clock
20:36:14.354 UTC Tue May 7 2013

This is from SW2:

May  7 20:36:20.008: MST[0]: updt roles, information on root port Fa0/21 expired
May  7 20:36:20.008: MST[0]: Fa0/23 is now root port
May  7 20:36:20.008: MST[0]: Fa0/21 state change forwarding -> blocking
May  7 20:36:20.008: MST[0]: Fa0/3 state change forwarding -> blocking
May  7 20:36:20.008: MST[0]: Fa0/5 state change forwarding -> blocking
May  7 20:36:20.008: MST[0]: Fa0/23 state change blocking -> forwarding
May  7 20:36:20.008: MST[0]: Fa0/21 is now designated
May  7 20:36:20.012: MST[0]: sending proposal on Fa0/21
May  7 20:36:20.012: MST[0]: sending proposal on Fa0/3
May  7 20:36:20.012: MST[0]: sending proposal on Fa0/5

So it took roughly 6 seconds which was expected. Because MST runs
RSTP the results are exactly the same. The only thing that’s really different
with MST is that all BPDUs are piggybacked in the CIST (instance 0). If you have
VLANs mapped to instance 0 and there is a change then the other ISTs may have
to recalculate as well.

So using MST is no different than using RPVST+ from a convergence standpoint.
In future posts I will look at running a mix of RPVST+ and MST and see how
they interconnect.

STP convergence – MST

Tagged on: CIST Convergence IST MST MSTP RPVST+ RSTP Spanning tree STP

rednectar

May 8, 2013 at 11:49 am

Permalink

A couple of points from an MST fan:

1. You have configured the priority for MST instance #0 and MST instance #1
By default, all VLANs use instance 0, so you don’t need to define instance #1 unless you allocate some VLANs to it.

2. You configured a region called TST. This just complicates the issue. In fact, I would suggest that more problems are caused by this practice than any other with MST, because you MUST get that same case-sensitive name exactly the same on EVERY switch that joins the topology. This means you have to touch any new switch before it will join the STP topology happily. Far better to leave the region name as the default (blank), then by default any new MST switch (possibly from another manufacturer even) will just join in like with normal spanning tree.

This whole region name thing is very widely mis-understood. Firstly, the syntax of the Cisco CLI doesn’t even hint that the commands:
spanning-tree mst configuration
name XXXXX
have anything to do with actually naming a REGION.
Secondly, many book examples actually show examples that create regions, when none is required. Like your example :). I wish that people would forget about MST regions until they really need to use them. Which is probably never.

3. You say “MST is an industry standard which can run multiple instances but not one per VLAN”.

This highlights two very important advantages of MST
i) It is an industry standard. In fact it is called 802.1D. Many people refer to 802.1D meaning the 1998 version of the standard. 802.1D has been MST and rapid since 2004.
ii) It doesn’t spawn another instance of a spanning-tree topology every time you create a new VLAN. If you are funning say 100 VLANs in your PVST+ environment, you have 100 possible spanning-tree instances sending 100 BPDUs every 2 seconds on every link, and you may have to look at 100 groups of blocked/alternate/forwarding ports to troubleshoot.

With MST, you would typically assign say 50 VLANs to MST instance#1 and 50 VLANs to MSTinstance#2. Now you only have three possible spanning-tree topologies to troubleshoot (there is always an MST instance#0 as well) and they send one BPDU every 2 seconds with a digest of the STP information for all instances.

But I’m really glad you took the challenge, and did the MST comparison. I come across many people who hate spanning tree, and think that it is difficult. I used to work for a vendor who implemented MST when it became a standard back in 2004, and it just worked out of the box. And I mean actually worked. And it was rapid. It is a shame that even in 2013 Cisco seems to eschew using the 2004 standard in preference to a proprietary implementation.

4 thoughts on “STP convergence – MST”

rednectar
May 8, 2013 at 11:49 am

A couple of points from an MST fan:

1. You have configured the priority for MST instance #0 and MST instance #1
By default, all VLANs use instance 0, so you don’t need to define instance #1 unless you allocate some VLANs to it.

2. You configured a region called TST. This just complicates the issue. In fact, I would suggest that more problems are caused by this practice than any other with MST, because you MUST get that same case-sensitive name exactly the same on EVERY switch that joins the topology. This means you have to touch any new switch before it will join the STP topology happily. Far better to leave the region name as the default (blank), then by default any new MST switch (possibly from another manufacturer even) will just join in like with normal spanning tree.

This whole region name thing is very widely mis-understood. Firstly, the syntax of the Cisco CLI doesn’t even hint that the commands:
spanning-tree mst configuration
name XXXXX
have anything to do with actually naming a REGION.
Secondly, many book examples actually show examples that create regions, when none is required. Like your example :). I wish that people would forget about MST regions until they really need to use them. Which is probably never.

3. You say “MST is an industry standard which can run multiple instances but not one per VLAN”.

This highlights two very important advantages of MST
i) It is an industry standard. In fact it is called 802.1D. Many people refer to 802.1D meaning the 1998 version of the standard. 802.1D has been MST and rapid since 2004.
ii) It doesn’t spawn another instance of a spanning-tree topology every time you create a new VLAN. If you are funning say 100 VLANs in your PVST+ environment, you have 100 possible spanning-tree instances sending 100 BPDUs every 2 seconds on every link, and you may have to look at 100 groups of blocked/alternate/forwarding ports to troubleshoot.

With MST, you would typically assign say 50 VLANs to MST instance#1 and 50 VLANs to MSTinstance#2. Now you only have three possible spanning-tree topologies to troubleshoot (there is always an MST instance#0 as well) and they send one BPDU every 2 seconds with a digest of the STP information for all instances.

But I’m really glad you took the challenge, and did the MST comparison. I come across many people who hate spanning tree, and think that it is difficult. I used to work for a vendor who implemented MST when it became a standard back in 2004, and it just worked out of the box. And I mean actually worked. And it was rapid. It is a shame that even in 2013 Cisco seems to eschew using the 2004 standard in preference to a proprietary implementation.
- reaper81Post author
  May 8, 2013 at 12:10 pm
  
  Hi,
  
  Thanks for the great comment. I did have VLANs mapped to instance 1. My point was to prove that changes in CIST would mean that other ISTs have to recalculate but it wasn’t working. I think I need to run multi region for this to happen. So I’ll try that in another post.
  
  I agree, it’s a bad habit of naming the instance when it’s not really needed. All the books preach that you need to configure name, revision and instance to VLAN mapping but as you said the name isn’t really necessary. Also, it’s not like the name is actually sent, if I remember correctly these things just create a digest that is sent and then if the digest is matching then obviously all parameters are matching.
  
  People definitely get the standars confused, 802.1W vs 802.1w and 802.1S vs 802.1s and so on. Like you say Rapid has been in the standard for a long time since 2004.
  
  People are afraid of L2, they learn the basics but don’t get deep into how control packets are sent etc. L2 interests me and I want to go deep. Even though I’m a CCIE there’s still a lot to learn in this area. I’m planning to do some tests with RPVST+ running and MST and maybe multi region as well.
  
  If you like to discuss things like this you should add me on Gtalk or something. Always fun discussing L2 with knowledgable peers 🙂
rednectar
May 8, 2013 at 2:11 pm

Play with multi-region MST if you want – as an academic exercise. Do you know anyone who actually needs to use regions? (There are probably plenty of sites that DO use regions because they followed the ill-advised examples I mentioned earlier). With the introduction of 802.1aq in 2012 there may be better solutions to many problems that regions were meant to solve (Mind you, regions are still around in 802.1aq AFAIK).

I do also apologise for quoting 2004 as the year that 802.1D became “MST”. According to wikipedia it was 2005. However, I do see that regions are mentioned in the 2004 standard as well, so I’m not so sure now.

Re:Gtalk – I never did sign up. Or maybe I did, but didn’t use it. But I’m easy to find – start at rednectar.net or the GNS3 forum
Petter Bruland
May 14, 2013 at 12:04 pm

Excellent comments. When I started working for my company, they had MST configured with multiple regions. Each IDF within the HQ building had its own region. Also adding new VLANs would break the MST digest, making the switches run RSTP until the new VLAN was added to all switches in region. Now our plan is to convert all IDFs to L3 and minimize use of spanning-tree.

4 thoughts on “STP convergence – MST”

Leave a Reply Cancel reply