Confused about MST

After reading the end of chapter 11 regarding MST, it threw off my whole studying as i dont really understand why we would use that in a regular network enviornment.

I wonderning now if it takes multiple vlan instances and creates 1 instance for it? or is it another form of STP?

It cannot interact with PVSTP+? But who uses that? Doesnt everyone really just use rstp just fine ?

Im just wondering the need for this in the real world. Maybe im also not getting it? I think thats what it is.

A little light to this dark part of the study room please

Thanks in advance guys.

Find more posts tagged with

SAVE $250 on Your CISCO Boot Camp — Use Code "EXAM26"

Exclusively for TechExams members for Infosec Boot Camps starting before April 30, 2026

View CISCO Boot Camps

Comments

Forsaken_GA

If most of your VLAN's have the same spanning tree topology, there's really no need to run an STP calculation for every single one of them. If I've got 1000 VLAN's, and 3 switches, my number of possible logical topologies is very small. Let's say I wanted to do some vlan load balancing. I could then create 2 MST instances with one switch as the root for half my vlans, with one instance mapping to that, and the other half mapping to the second instance. This saves me a good bit of processor overhead.

In reality, MST isn't something you would normally deploy in a small campus environment. It's more complex than the other STP implementations, and the gains won't be worth it. But when your vlan's start climbing into 4 digit numbers, it's worth a look.

And unfortunately, there are quite a few networks running pvst and pvst+ because it used to be pushed heavily, and if you only had cisco gear it was ok, and I think pvst is the default STP mode on most modern cisco gear anyway. So yeah, it's not something you can really ignore.

yuriz43

A good real world example of using MST is in a service provider environment. In such situations where you have a lot of customers with individual Vlans, running 1000 instances of STP will cause a huge amount of CPU load on your switches. This can lead to serious problems or total network outage. As Forsaken said, most networks ( properly designed ) will only have a few different topologies. This allows you to split your vlans into a few MST instances, and still allow you to load balance your redundant links.

By the way, MST is fully compatible with PVST+ and RSTP.

DevilWAH

Like has been said its really just a way to reduce the amount of spanning tree traffic and processing on the network hardware.

not really usefull in small networks with only 10 to 100 vlans. but once you get in to 1000's it can be very good espicaly at the core where you often find that you have a lot of repetition in your Spanning tree config for each VLAN. having four or 5 perminant MST instance set up across you switch network, which you can just add and remove vlans to makes management much simpler. (and documentation easy as well)

I think documentation is some thing lots of people over look when designing networks,

Forsaken_GA

yuriz43 wrote: »

By the way, MST is fully compatible with PVST+ and RSTP.

With Cisco gear.

If you ever try to integrate Cisco switches with Force10 Switches and MST is in the mix, you'll find a downtime incurring surprises.

ishgotbike

Ok, thats good to know. Easier to comprehend now.

I do agree about documentation. Noone ever leaves a current DOC. Always years behind or something missing. Why cant you just have a document interval where you spend time just updating?

Sorry just another rant.....

DevilWAH

ishgotbike wrote: »

Noone ever leaves a current DOC. Always years behind or something missing.

I take offence at that....

I am rather proud of the fact that every digram, config, ip, port, etc on my network is documents, and referenced from a single central place (one document leads to all others)

And every one is up to date to with in a few days (failing that there are always the current and last 3 configs for every device sorted and time stamped)

I know that any one coming in who has a good reasonable understanding of networking could rebuild my network to the same state it is in, as of this minute.

MY advice is don't worry about putting aside X amount of time a week to do documentation (you will forget about it by then) just factor in 5 or 10 min for each job, or as long as the documention will take to do, and do it there and then, it's so much less stress full. It took me about 2 years to document an undocumented network when I started. I tell managers now, when asked how long a job will take. it will be X amount to research/test, y amount to implement and then Z amount to do the documentation. They use to moan, but now they see the results they are happy for me to sit around for 30 min filling it in.

OK my system still alerts me to any documtation that has not been updated for more than a few months. But it has been a long time since I have seen an alert. I suppose I should check its its still working.... But anyone getting in to networking should realise that the ability to document well and keep it up to date, is no less a requirement of our jobs, than being able to configure the devices in the first place.

Plus the feeling you get when you manager asks for a port audit of site, which you had over 30 seconds later from the weekly report you have running and filled neatly, broken down by building, distribution segment, device type, etc. with a few bandwith usage figures thrown in for good measure, (you know they will come back and ask for them any way, so might as well get in there first). While you colleges are still scrabbling around 3 days later just trying to get a list of PC names. (which you also happen to have, but you can't do all there work for them)