MST without preferred routes applied...

[ehamil1984]

Hi There folks, hopefully a quick & easy one for someone to answer:

In the process of an MST migration, and referring to various components in the following doc - http://www.cisco.com/en/US/products/hw/switches/ps708/products_configuration_example09186a00807b075f.shtml.  Just over half way down, a reference to the following is present:

!--- Distribution2 configuration:Distribution2(config)#spanning-tree mst configurationDistribution2(config-mst)#name region1Distribution2(config-mst)#revision 10Distribution2(config-mst)#instance 1 vlan 10, 30, 100Distribution2(config-mst)#instance 2 vlan 20, 40, 200Distribution2(config-mst)#exitDistribution2(config)#spanning-tree mst 2 root primaryDistribution2(config)#spanning-tree mst 0-1 root secondary

Is the implementation of primary/secondary roots necessary for switches involved in a single MST region?  Can someone summarise the expected behaviour in a scenario where no primary/secondary roots are defiend?  Would all traffic be effectively treated equally in the MST region?

My thinking behind this is to keep the MST implementation as simple as possible, with perhaps two spanning-tree instances existing per switch layer governing all VLANS (since layer 3 routing with vlans will be involved higher up the switch-stack, it would make sense to logically segregate each inter-connecting vlan between switch-stacks with their own dedicated instance).  Since all vlans at the switch-access layers will be effectively used for segregation of departmental data only, am I safe in assuming that no primary root needs to be defined?

Thanks in advance guys!  Any input would be appreciated!

ehamil1984

[Giuseppe Larosa]

Hello Ewan,

MST provides you the capability to build different topologies for different MST instances.

If you do not configure MST primary/secondary root for each MST instance the MST region will end up electing the same device as root bridge for ALL MST instances.

If you want to build two different topologies you should at least configure a primary root bridge for each MST instance on two different devices. Configuring also secondary root bridge is considered best practice so that in case of fault of primary root bridge the configured secondary root bridge takes over for that MST instance.

So you understand that configuring primary and secondary root bridges for each MST instance is part of the solution.

There is another important aspect to be considered: MST requires a different approach you need to provision association of the all the existing AND future Vlans in advance because if you make a change of Vlan to MST instance mapping you cause an MST region partitioning until the configuration change is not propagated everywhere.

The suggestion is to configure full ranges of Vlans to MST instance mapping by dividing the whole Vlan space 1-4094 in N parts.

You can define ranges including Vlans that do no exist in the Vlan database of switches.

In the future, when you will need a new vlan you can create a Vlan taken from the range associated to a specific MST instance and you get the topology of that MST instance automatically without any downtime by avoiding to make changes on the MST configuration.

Hope to help

Giuseppe

[ehamil1984]

Hi again Giuseppe,

Again many thanks for taking the time to respond - should have you on speed-dial! ;-)

Sounds like some of these considerations havent been taken into account in my proposal - back to the drawing board it is then.

Thank you for the input!

Ewan

[ehamil1984]

Hi again Giuseppe,

Based upon what we have discussed, I have threw together a quick theoretical topology for the sake of this discussion.  As you can see, I have placed a vlan block of 2000-3000 into instance 2 (this of course is subject to change and will probably be sub-divided into other instances -  as per your suggestion).  For future proofing, we may (as you described) add additional vlans out of the 1-4094 range - it would definitely come in handy when adding additional infarstructure to the solution.  To keep things logical, I have divided the network into several instances.  Each instance will have a dedicated vlan for routing purposes (10,11 & 20).  My interpretation of what you suggest makes me feel that this would work as long as the primary and secondary root bridges are configured appropriately.  In this topology, BDR01 is primary with BDR02 being secondary for instance 1, WAN01 is primary with WAN02 being secondary for Instances 0, 2 & 3.  The access & aggregation switches would therefore be subject to WAN1 & 2.  Let me know your thoughts:

Cheers,

Ewan

[Renan Abreu]

Ewan,

    In STP/MST there's no actual secondary switch, the root bridge is only one switch, the only reason for configuring a secondary switch is to have a controlled scenario in case the first one fails and we would be sure who would be the root bridge in that case.

    MST instances works mainly for load balancing, what you would do is to get for example 2 switches and devide all your VLANs into two instances (I.E. instance 1 => VLAN 1-500 Instance 2 => 501-100) This way, all traffic for VLAN 1-500 would converge to one switch and the traffc for VLANs 501-1000 would converge to another one.

    You should configure the instances exactly the same in all switches in the network and choose who you want to be the primary for the instance you want.

    If you're using HSRP, you should also take care with the L3 part, the HSRP active should be the router where the VLANs converge to, otherwise it won't work as expected.

    Of course I'm resuming A LOT how it works here.

    Sorry if I wrote too many things together, if I confused yourself I can try to explain more detailedly.

[ehamil1984]

Hi Renan,

I believe I follow.  If we compare what you say to the above topology therefore, all STP/MST instance information will be the same on all switches i.e. instance 1 for example could be defined as having 10,11,20 & 2000-3000 accross the board.  The logical segregation of the network I want to achieve would then be done via editing the vlan databases per switch and amending those vlans permitted over the various trunks specified.  At the end of the day, I am interested in the additional redundancy that MST will provide (i.e. cover more than the current 128 vlan limit we are restricted to with PVST) more than load-balancing etc, so as long as I can have the curent and future vlans subject to STP/MST (1024 odd vlans in total) then I'll be happy.  Would this be in line with what you are suggesting?

I am currently using HSRP to provide redundant gateways, so thats a very good point.  Thank you for this.

I would be keen to nail down exactly what switch would be defined as a backup root bridge in the event of failure, so I would still implement a secondary in this case  The theoretical topology above therefore would have wan01 as primary and wan02 as secondary for any instances defined.

Thanks in advance,

Ewan

[Renan Abreu]

Hi Ewan,

The instances are groups of VLANs you want to behave the same way in STP, why I'm saying this? In your example your instances 2 and 3 are using the very same switch as the root bridge so I don't see a very good reason to separate the VLANs into 2 different instances, you'll only create a separate database that will behave exactly the same. If you're thinking in the future to change the root bridge for one of them it is a good point to separate it so it will be easier in the future.

In your diagram, all VLANs except VLAN 10 will have WAN1 as the root bridge, so if you create the instances below you'll be good to go.

Instance 1 - VLAN 10

Instance 2 - 1-9,11-4096

You actually wouldn't need instance 2 because IST (instance 0) would take care of it, but let's simplify ;-)

So now your network would be the way you wanted.

VLAN 10 converging to BDR1 (in case of failure BDR2)

All other VLANs converging to WAN1 (in case of failure WAN2)

You should MAP all instances exactly the same in all switches, you don't even need to have the VLANs created on VLAN database, although the MAP should be the same, otherwise you may come to a failure in the future if you create a VLAN that is not mapped correctly.

If you want for example SRV Aggregation 1 to be part of only VLAN20, there's no need to have a separate instance, configure it as a trunk interface and set the allowed VLANs for it as only the VLAN20, there's no need to have a separate instance for that (Don't trust VTP pruning for that, if you intend in using VLANs higher than 1024 you'll not be able to use VTP).

I don't know exactly if I got your point so that's why I'm explaining some things.

You mentioned PVST, the problem with PVST is that comparing to MST you would create a single instance for each VLAN you have, which is completily unnecessary as you will not load-balance accross for example 128 paths if you have 128 VLANs.

You can have as many VLANs as you want in an instance, the key point here is load-balance, if you leave all of them in a single instance you're wasting bandwidth in a full redundant network.

If you create too many instances and are not balancing, they'll behave exactly as one instance but you'll waste memory and CPU.

[ehamil1984]

Hi again Renan,

Perfect - many thanks for that latest reposnse.  I believe I have enough now to take this forward and proceed with testing!

Thanks to both yourself and Giuseppe for your input in this discussion, was very much appreciated!

Ewan

[Renan Abreu]

Anytime.