MST - PVST+ Interoperation

[jim_berlow]

I've been reading Cisco documentation regarding MST - PVST+ interoperation and have some questions as I am about to do this in a production environment.

In our environment (PVST+), we often manually exclude unwanted VLANs from our trunks (as shown below):

interface GigabitEthernet2/0/1

switchport trunk encapsulation dot1q

switchport trunk allowed vlan 1,300,404,405,455,474,700,800,1001-1005

switchport mode trunk

We are looking to implement MST as such:

spanning-tree mst configuration

name test

instance 1 vlan 1-300

instance 2 vlan 301-4094

We do this kind of VLAN filtering at nearly all of our closets. The Cisco document at the following URL shows that trunks should carry all VLANs mapped to an instance.

http://www.cisco.com/en/US/products/hw/switches/ps708/products_configuration_example09186a00807b075f.shtml

So according to everything that I see and provided that I use the MST configuration above, I would need to remove VLAN filtering from the trunks for this to work properly.

Am I correct on this?

Thanks,

Jim

[Istvan_Rabai]

Hi Jim,

Why don't you then configure you instances like this:

instance 1 vlan 1,300

instance 2 vlan 404,405,455,474,700,800,1001-1005

Cheers:

Istvan

[bmarms]

you could also load balance mst instances if you have redundant trunks. you can use the following commands on your trunk interfaces on your edge switches:

int g2/0/1

spanning-tree mst 1 port-priority 240

spanning-tree mst 1 cost 1

int g2/0/2

spanning-tree mst 2 port-priority 240

spanning-tree mst 2 cost 1

[jim_berlow]

Good ideas, guys.

A question about this:

instance 1 vlan 1,300

instance 2 vlan 404,405,455,474,700,800,1001-1005

I imagine that I would need to configure that on both ends of the link. Now if I am doing this on the core side, wouldn't I have an issue with other access closets that trunk different vlan's. I'm concerned that different trunks would then require diffrent vlan's mapped to the instances. I hope that I am conveying that okay.

How about an example. If on the core side I had another trunk (going to a different access closet) that required different vlans. Say:

interface GigabitEthernet1/0/1

description different_access_closet

switchport trunk allowed vlan 1,201,202,413,470,1002-1005

switchport mode trunk

interface GigabitEthernet1/0/2

description another_access_closet

switchport trunk allowed vlan 1,250,251,421,470,1002-1005

switchport mode trunk

Do you understand what I am asking? How would I map instances when I have trunks with different vlan requirements?

Thanks,

Jim

[Istvan_Rabai]

Hi Jim,

In this case I would try to resort to defining more than 2 mst instances, though I have never done such a configuration.

There is a possibility to define 15 mst instances (0 is the IST).

Each instance would embrace only vlans that form a common contiguous spanning tree.

In your case this can get very complicated, so I would prefer to draw on paper all my instances and which vlans would be mapped to each instance, so I can see clearly the resulting configurations.

In the above specific example I would define the following instances:

instance 1 vlan 1,470,1002-1005 (this instance spans both ports)

instance 2 vlan 250,251,421 (this instance is alive only on port Gig1/0/2)

instance 3 vlan 201,202,413 (this instance is alive only on port Gig1/0/1)

I suppose it will work, but you should try it on a lab configuration before putting this into a production network.

Cheers:

Istvan

[jim_berlow]

It sounds like it may be easier to remove all the vlan filtering from all trunks and let it do its thing. The bad part of this would be unneccessary vlan traffic transitting to switches which don't house those vlans (since now there is no vlan pruning).

15 mst instances would not adequately cover all the different trunk configurations.

Thanks,

Jim

[Francois Tallet]

Hi Jim,

That's a recommendation, not a rule at all. You can perfectly prune some vlans from a trunk, but you have to be aware that MST is only computing its topology based on the instances, not the vlans. So suppose you have two redundant paths on your network P1 and P2 (you generally run STP because you have redundant paths;-). MST runs on both and determines that instance 1 should use P1 and block P2. If you have pruned vlan 10 from path P1, you will lose connectivity in vlan 10. MST is not going to make an exception for vlan 10 because it only exists on path P2. Path P2 is blocked for all vlans mapped to instance 1, period. That behavior would be different in PVST because no BPDU would have gone through P1 for vlan 10. Thus the STP instance for vlan 10 would not have seen P1 and P2 as redundant paths and would not have blocked P2.

If you are able to understand this, you don't need to follow the recommendation (which is just a simple way of avoiding those kind of problems).

Regards,

Francois