MST instance vlan mappings

[branfarm1]

Hi there,

I'm preparing to deploy a pair of 6500's with a fairly simple collapsed core topology.  I've decided to use MST because I'll be connecting the 6500's to HP Procurve switches for the server access layer and in my testing MST allowed for much faster failover in the case of uplink failure.    As part of my ongoing operation I'll have a number of connections that terminate directly on the 6500's and these will require individual vlans to allow connectivity up to FWSM's in each 6500.  My question is about adding these vlans into MST -- since these only exist on the 6500's and will not be carried down to the access switches, do I need to add these to a specific mst instance, or can I keep them in the default instance?

Thanks in advance,

Brandon

[Ian Jay]

Hi Brandon,

The scenario you describe indicates you will be running the FWSM in routed mode and that the Procurve are MST compatible. Assuming this is true, im also assuming the Core will route from 'access' vlans, to the FWSM VLANs. This scenario would be ideal to have multiple MST instances where the FWSM VLANs are not present in the Procurve switches. Since there will be no need to have the VLANs present, there would be no reason to define them on Procurve switches and subsequently be affected by any topology change in the FWSM instance.

You would create a separate instance for FWSM VLANs and keep the Procurve VLANs in the default instance. You should also ensure that Root for both instances remains in your collapsed core.

If i've made some incorrect assumptions, please correct.

/ijay

[branfarm1]

Hi Ijay,

Would you recommend defining a completely separate instance for these vlans or leave them part of the default instance 0?

--Brandon

[Ian Jay]

Hi Brandon,

It's really a design question. Defining separate regions (instances) to aggregate similar topologies is the main benefit of MST. Each region maintains what is essentially the same topology. Since you mention that you dont need FWSM VLANs on the Procurve, then you could define a separate instance for those VLANs, but this is a choice that is not technically imperative.

There would be no problem with having all the VLANs in the default instance with the rest, but then you are essentially just running all VLANs with the same topology, this sounds as if it is contrary to your design goals. The main benefit you would gain from two separate instances is isolation of topology changes in each region.

Unfortunately there is no hard and fast rule. If you want less administration overhead, use one instance. If you want to isolate possible topology changes, you must accept the administrative overhead of the extra instance.

Hope this helps to make the decision either way.

/ijay