Multiple MSTIs for switch blocks on Collapsed Core
I am planning a migration to MST on a collapsed core environment (e.g. no distribution switches due to cost). Thus I am not able to take advantage of the distribution switches to segment my spanning tree topologies into separate regions and after reading the following: "Cisco recommends that you place as many switches as possible into a single region; it is not advantageous to segment a network into separate regions." I have decided that if distribution switches existed that it would be better to make the distribution switches in each switch block the root for that MSTI instance only anyway.
Going with the typical campus hierarchal network design, my network should be broken into switch blocks in order to group traffic by function, e.g. server, management, access, enterprise edge etc, this obviously requires keeping VLANs in their respective switch block in order to keep unknown unicasts and broadcasts being sent around the network. This has brought me to the conclusion that I now require 2 MSTI's per switch block design (only 2 physical topologies present per switch block). So for example I have 2 switch blocks an access block and a server block, connecting into the core block I then should use 4 MSTIs to address the different topologies with the respective access VLANs mapped to the MSTIs used in the access block, and the respective server VLANs mapped to the MSTIs used in the server block.
Now, this is where I am curious. MST defines its region based on, Region Name, Revision Number, and instance to VLANs mapping (I assume its ALL instances) which each switch then MD5 hashes and compares the received BPDU hash to ensure that it is in the same region. This makes sense in the order that all devices need this configuration in order to be in the same IST region for CST.
My concern now is that I have a number of instance to VLAN mappings on switches in each switch block that do not need to know anything about that VLAN. E.g. my server block instance to VLAN mappings need to be on my access block switches and vice versa.
Now Cisco says: "Ensure that trunks carry all the VLANs that are mapped to an instance or do not carry any VLANs at all for this instance. " I translate this as "AN" being a single instance so trunk all VLANs related to the MSTI instance that you want, and "do not carry any VLANs at all for this instance" meaning to prune every VLAN associated to an MSTI of a trunk where you do not want the MSTI instance to appear.
Would this be the correct assumption? I have no lab environment to test this before trying on production so obviously I want to ensure the correct approach.
I have included a conceptual configuration. I guess one of the other questions while I'm at it. Should I segment my port channel in half so that each port channel can segment MSTI's across each channel in order to segment and load balance the VLANs across different ether channels, rather than share the one ether channel?
I say originally because it has been duplicated in many place without the reason for the recommendation;-) And this is not a rule, just a recommendation in order to make things simpler if you have a very PVST-centric state of mind (generalized within the Cisco community). Let me know if you have any problem understanding the recommendation after reading the part I referenced above.
The vlan to instance mapping is just an MST configuration. The vlans that are mentioned there don't have to exist globally. It is simpler if they do, but they don't have to. So what you are planning seems perfectly reasonable.
For your second question, I'm not sure what port channel you are talking about. I understand that you are asking whether you should dedicate a port channel per group or having a larger port channel handling all the groups together. The answer depends on your traffic pattern and requirements. Separating your traffic ensures a dedicated bandwidth for each of your group. If one group needs more bandwidth than its channel provide, it will lose traffic even if the other channels are under-utilized.
Re: Multiple MSTIs for switch blocks on Collapsed Core
Thanks very much for your reply. Unfortunately, I cannot access that link 403, after login in?
Sorry, When I was mentioning pruning I meant the configuration of the trunk ports to carry vlans. "switchport trunk allowed vlan 2,3,4". Not VTP pruning if that is what this document is regarding ( wild guesses ;) )
My second question was regarding a L2 etherchannel between each core. My thinking was that if I have the SPT Root/HSRP Active gateway for each VLAN on the same Core and with VLANS/MSTI split over each core, then I would have almost 2 diverse traffic patterns happening. So I wondered if there was any benefit in segmenting the L2 etherchannel for QoS/etc. I am now thinking that this is better to keep as one etherchannel.
There are two part relevant to this, starting by "IST Instance is active on all ports, whether trunk or not".
I also think that keeping the channel is more flexible than splitting it. You might want to split the channel if you have critical traffic for which you want to reserve bandwidth. But in that case, you will not be able to share the links between the vlans that are assigned to either of them.
The ProblemEnter EVCsHow It Works (Ingress)How It Works
(Egress)Step-by-Step ExampleFinal Thoughts The ProblemOn traditional
switches whenever we have a trunk interface we use the VLAN tag to
demultiplex the VLANs. The switch needs to determine which MAC ...
The ProblemEnter EVCsHow It Works (Ingress)How It Works
(Egress)Step-by-Step ExampleFinal Thoughts Introduction: Netdr is a tool
available on a RSP720, Sup720 or Sup32 that allows one to capture
packets on the RP or SP inband. The netdr command can be use...
IntroductionOSPF, being a link-state protocol, allows for every router
in the network to know of every link and OSPF speaker in the entire
network. From this picture each router independently runs the Shortest
Path First (SPF) algorithm to determine the b...