Multiple Spanning Tree (MST)


(Rene Molenaar) #1

This topic is to discuss the following lesson:


Hi From United States - Tulsa Oklahoma!
(Yevgeniy O) #2

good


(Philip W) #3

Awesome explanation on this, really cleared things up for me


(Michael M) #4

Hi Rene.
So is IST0 just Vlans that have not been applied to an Instance? If so im just confused about the part in the article where you state that “MST will only advertise BPDUs from the IST to the outside world”.
If a region connects to a different region or another STP domain does that mean all VLANs are now mapped to IST0 just for that switch that is outside of the region?


(Rene Molenaar) #5

Hi Michael,

IST0 is called IST (Internal Spanning-Tree) and these are the VLANs that haven’t been mapped to another instance.

PVST uses 1 STP for each VLAN, MST uses 1 STP for multiple VLANs so we have a mismatch here. To make the two compatible, here’s what happens:

- Within the MST region we run multiple STPs (one for each instance).
- On the border links (switches that connect to PVST) our MST switch will detect PVST BPDUs (or another MST region) and marks these interfaces as “boundary”.
- The MST switch won’t send any BPDUs from the instances that we configured.
- The MST switch will copy its BPDU from the IST and sends this BPDU on all VLANs towards the “outside” switch (this is called PVST Simulation mode).

This is what allows switches outside of the MST region to see it as “1 big switch”.

If you need some more detail, let me know. I can always do another write-up on MST…

Rene


(Michael M) #6

Ahh ok I think I get it. IST0 is purely a MST thing and has nothing to do with PVST or CST
Thank you Rene.


(Hussein Samir) #7

Hi Rene,

Can we use MST in ISL trunks ?
And what about MISTP implementation ?


(Rene Molenaar) #8

Hi Hussein,

MISTP is Cisco’s pre-standard version which later became MST (which is a standard IEEE 802.1s). ISL trunks is no problem btw.

Rene


(Alberto s) #9

Hello, Rene.

Reference to the 2 instances, can I put one SW like root for the 2 instances?


(Rene Molenaar) #10

Hi Alberto,

Sure that’s no problem. The advantage of using two root switches however is that you can have some load balancing. If you use the same root bridge for all VLANs then a single interface will become the blocked port for all VLANs.

Rene


(Robert J) #11

How would we configure a secondary root bridge in a four switch environment in case the primary root bridge went down? Would it be as simple as setting this on the secondary root bridge switch?

spanning-tree mst 1 priority 8192


(Rene Molenaar) #12

Hi Robert,

Yes that’s it, just make sure you set the priority to be the “second best”. By default all switches have a priority of 32768 so when the primary switch fails, this one fill becomes the new root bridge.

Rene


(Frades) #13

so the switch that running PVST that connects to the MST, that switch will only see the IST0 priority? in your example, you made the Switch A the root on Instance 0. so PVST switch will just see a one giant big switch on MST but the switch A is the root bridge?

so when you make the Switch B the root on Instance 0, PVTS switch that have the directly connected interface to switch B will become the root port?


(Rene Molenaar) #14

Hi John,

That’s right, the PVST switch doesn’t know what the MST regions looks like. The MST region will replicate IST BPDUs on all VLANs to “simulate” a PVST neighbor. If you make SwitchB the root then the PVST switch(es) will use their interface(s) connected to switchB as the root port.

Rene


(Ryan M) #15

So I am a bit confused about how external Switches see this.
Even though SwitchB is Root Bridge and is assigned to Instance 2, it gets back to Instance 0 to external switches and the root switch becomes whatever the root is for Instance 0?

Here’s VLAN 10 which is mapped to instance 2. SwitchD sees SwitchA as the root bridge for this VLAN even though we configured SwitchB as the root bridge for instance 2. This is perfectly normal because MST will only advertise BPDUs from the IST to the outside world. We won’t see any information from instance 2 or instance 3 on SwitchD.

(Andrew P) #16

Hi Ryan,
Interaction between MST and PVST/Rapid STP can be quite confusing. There are a few key points that are helpful to keep in mind.

  1. MST tries to hide the details of what is going on inside a region to any STP topology outside of that region
  2. MST accomplishes this by using “Virtual Bridge” in that the entire MST region is present as one giant switch to an outside STP topology
  3. MST uses “Instance 0” for the mechanics of this virtual bridge interaction with an external STP domain
  4. Every MST region MUST have an Instance 0–MST does this automatically
  5. MST uses the best Bridge ID of any switch within its region as its “Virtual Bridge” ID.

Basically, what happens when MST interacts with an external STP domain is this: MST looks at all the switches that are part of its region and selects the one with the best bridge ID. When it comes time to elect a root bridge between the MST region and the external STP, MST says, “Here’s the best I’ve got (and presents the previously selected bridge ID, via Instance 0). Can you do any better?” Depending on whether the external STP can beat the Instance 0 bridge ID, the main root bridge (also called the CST Root) will be either inside the MST or outside. It is always best for it to be inside, fyi.

Here’s the interesting bit. MST will engage in telling lies to the external STP domain. Let’s say the Virtual Bridge ID chosen was from a switch deep inside the MST region, and not at the boundary with the external STP domain. When the external STP switch receives information from the directly connected member of the MST region, it thinks it is talking directly to the switch that is deep within MST. The MST boundary switch will pretend that it has the bridge-ID of the switch that was deep inside MST. The external STP switch will never learn the true identity of the actual MST switch it is talking to.

Like I said, this is a complicated topic, and if you want to get into the real nuts and bolts of it, check out a great blog from INE:
http://blog.ine.com/2010/02/22/understanding-mstp/


(Abhishek D) #17

very nice.

can you please share an example from “real world networks” , why someone would use MSTP ?

Is is common to see in real life networks ?

Thanks in advance
Abhishek


(Andrew P) #18

Abhishek,
In large networks where there are high numbers of VLANs, it would be very common to see MST. The reason is efficiency. Let’s say you have 100 VLANs. With RSTP, each one of those VLANs is going to have its own root bridge, its own RSTP flooding domain, with separate BPDUs. The question becomes, “why do we need 100 possible different topologies?” In real life, even with a high number of switches, it is unlikely you would need more than 5-6 separate topologies (meaning, I want my root bridge for topology A over here, while the root bridge for topology B is somewhere else, etc).

The whole reason for MST is to cut down the 100 topologies in our example, down to just a few. This is done by mapping groups of VLANs together that require the same topology. The resource and complexity reduction by going from 100 topologies to, say, 5 is significant.


(Abhishek D) #19

Many Thanks Andrew. it clears most of the doubts , except when you said :

  1. With RSTP, each one of those VLANs is going to have its own root bridge

Can I also say :- “With R-PVST, each one of those VLANs is going to have its own root bridge” becuase with VLAN we will actually use PVST .

  1. “This is done by mapping groups of VLANs together that require the same topology”

So what characteristics of a network would decide that which VLANs should part of same topology from SpanningTree Point of view.?

Best Regards
Abhishek


(Andrew P) #20
  1. You are correct. Cisco doesn’t implement a pure RSTP. It is technically R-PVST+, so I was using RSTP as shorthand for that.

  2. This is purely a traffic flow / business decision. For example, if you have two divisions, say, Sales and Marketing that each have their own VLANs, and you want to make sure that traffic between those VLANs flows over as few links as possible, it would be best to group those two together with a common root.