cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1901
Views
0
Helpful
9
Replies

MST Houskeeping

martinwalsh
Level 1
Level 1

I currenlty have MST configured on our 6500's with multiple instances. We also have it configured on the connected 3550/3750 switches.

Over time unfortunately the configuration has got out of sync and was wondering if i can just add / remove the vlans out of the instances on the core and remove the MST config all together on the floor switches.

The Core's do all the routing so shouldnt the MST config just be on these? Does having the MST config on the edge switches have any effect on the network?

Also to add/remove vlans from the instances can you say;

"instance 1 vlan x" in isolation to add it or do you have to paste ALL the VLANS for that instance with the additional one appended??

Thanks

9 Replies 9

Peter Paluch
Cisco Employee
Cisco Employee

Martin,

I strongly recommend against mixing the MST and other STP variants. There are several caveats to look out for, and besides, once you have the MSTP, it is definitely the best alternative for a network with lots of VLANs so my personal goal would be to keep the MSTP.

Keeping the MST configuration in sync on all switches is a must but then again, you can directly take the spanning-tree mst configuration stanza from one switch and paste it as-is to all other switch in the MSTP region. That's not that much of a work!

The Core's do all the routing so shouldnt the MST config just be on
these? Does having the MST config on the edge switches have any effect
on the network?

The MSTP is not concerned with routing. As long as you have a redundant switched topology you need to run some variant of STP to eliminate Layer2 loops. I assume that your edge switches are connected by redundant links to core switches and that your switched network contains physical loops. As with all STP algorithms, MSTP must run on all switches to give you an appropriate protection.

With MST, the config on edge switches can have a profound effect. If the MST configuration between two switches differs, they both consider themselves to be in different MSTP regions. Under circumstances, MSTP may decide to block the link between such regions, leading to connectivity interruptions. This can also happen when mixing MSTP and older versions of STP. Therefore, keeping the MST configuration synchronized is very important.

Also to add/remove vlans from the instances can you say;

"instance 1 vlan x" in isolation to add it or do you have to paste ALL the VLANS for that instance with the additional one appended??

You can simply say instance 1 vlan X and the VLAN X will be added to the instance 1 while keeping all VLANs that are already present in the instance 1. You do not need to repeat the entire list.

Best regards,

Peter

Thanks Peter

I had no intention of getting rid of MST.

Its just part of a bigger peice of work i'm doing (Routing SVI across Layer 2 trunk!) which means i need to address Spanning Tree on our network amongst other things.

In doing this i noticed the config isnt consistant across our switches.

The cores config havent had new VLANS that have been created added and the edge switches are definatley not up to date with all the VLANS that are configured on the core!!

With MST, the config on edge switches can have a profound effect. If the MST configuration between two switches differs, they both consider themselves to be in different MSTP regions. Under circumstances, MSTP may decide to block the link between such regions, leading to connectivity interruptions. This can also happen when mixing MSTP and older versions of STP. Therefore, keeping the MST configuration synchronized is very important.

This is my concern that they are out of sync, however the "region" is configured ok on all switches, its just the Vlans on the instances that are not consistant.

I think i may have just added to the list of "Things to do" !

Martin,

Mapping of VLANs into instances is different and independent of having the VLANs actually created. Perhaps you know that but I wanted to be clear about this. For MSTP purposes, it is irrelevant whether the VLANs mapped into indvidual instances exist or not. You can map a non-existent VLAN into an instance - this causes absolutely no problems at all.

In fact, some Cisco engineers recommend that you configure a complete mapping of all VLANs (in sets of, say, 50 or more VLANs) into instances and configure this on all switches - without creating the VLANs. This way, the MSTP configuration will be consistent across the entire switched domain throughout its lifetime. As soon as you create a new VLAN, it will begin using the instance into which it has been mapped beforehand, and you do not need to change the MSTP region configuration. While not a totally flexible approach, it certainly is worth considering.

So if the MSTP configuration itself is identical on all switches in your network then the MSTP will operate just fine without any connectivity issues created by the MSTP alone. Having the proper VLANs created on proper switches is a different housekeeping work.

I hope this helped a bit.

Best regards,

Peter

I understand the creation of VLANs are independant of the MST config instances.

My "housekeeping" for example is where on the core i may have

name reg-XXX

instance 1 vlan 1,2,3,4,5,6,7,8,9,10

But on the edge switches for the same region:

name reg-XXX

instance 1 vlan 1,3,6,9,10

I'm guessing this is the issue that needs tidying up.  Instance 1 Vlans on the core are different from Instance 1 vlans on the edge.

Thanks for taking the time to reply........

Martin Walsh

Hi Martin,

Yes, you are right. Your current MSTP configuration is incongruent across the switched domain, and as a result, your switched domain is already partitioned into different MSTP regions. This absolutely needs to be corrected. Once again, the entire MSTP configuration (i.e., the MSTP region name, revision number and mapping of VLANs into instances) must be completely identical on all switches in an MSTP domain to form a single region.

Newer IOSes on 2960, 3560, 3750 and higher series switches support the VTPv3. The VTPv3 is capable of maintaining the MSTP configuration consistent across a switched domain just as it maintains the VLAN database. This is a great help - you make MSTP configuration changes on a single switch only (the so called primary server switch) and the changes will be automatically propagated to all other switches. If your network consists of recent switches you may want considering migrating to VTPv3 to simplify your maintenance.

Best regards,

Peter

Fantastic....i'll take a look at that

Hi Martin,

Check these URLs for more information about VTPv3 and its configuration/use:

http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/solution_guide_c78_508010.html

http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/12.2_55_se/configuration/guide/swvtp.html#wp1316856

The VTPv3 support on 2960, 3560 and 3750 series switches has been added in the IOS 12.2(52)SE. There is no support for VTPv3 on 3550 or 2950 switches, unfortunately (they are already end-of-sale).

Best regards,

Peter

My excitment was short lived!

The majority of our edge switches are 3550.  We are moving to 3750's but only as and when the 3550's go pop.

The site that I'm woking on at the moment however is 6500 at the core with 4507 at the edge but i think our IOS is older than what you mentioned.

Maybe quicker just to do a bit of manual configuration to get it straight.

It's worrying though that the MST configs are out of sync and have been for some time by the looks of it and we dont really know what side effects that is having on our network.......

Martin,

On 4500 series, the VTPv3 is supported since 12.2(50)SG. On 6500 series, the VTPv3 is supported since 12.2(33)SXI and in various CatOS versions.

Nevertheless, even if your switches do not support the VTPv3 by now, at least keep this option in mind and as you gradually replace your devices with newer versions, you may gradually introduce the VTPv3 into your network.

Best regards,

Peter

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco