In the algorithm specified in the IEEE standard, MSTP does not consider the VLAN membership of ports when calculating
the active topology.
As MSTP is designed to control all ports on a bridge, not just a subset of ports, for each MSTI, it does not work well with
the manual VLAN configuration model.
In the "Understanding MSTP 802.1s" Cisco document, it is not very clear if the Cisco MSTP implementation limits the active
topology of an MSTI only to the ports that have VLANs belonging to that MSTI.
Is it true? If it is true, is this solution IEEE compliant?
We have to avoid a misunderstanding here: there is no port VLAN membership management whatsoever in the IEEE 802.1Q recommendation with respect to the MSTP. MSTP does not care which VLAN a port is in or what VLANs are allowed on it, and it also does not care about how the port became a member of a respective VLAN. MSTP sends its BPDUs on all ports, access and trunks, in the same format and with the same contents. If MSTP decides to block or allow an instance on a port, it does just that, and all VLANs mapped to that instance will simply inherit their blocked or allowed status on the port. This is what IEEE standard says, and this is also what Cisco MSTP implementation is doing. Cisco is, as far as I know, not limiting the active MSTI topology only to ports that have active VLANs belonging to that MSTI (how would you want to do that, anyway? A single MSTI instance can be shared by multiple VLANs that can be individually allowed or filtered on a port or a trunk).
Of course, the independence of VLANs and MSTP instance can lead to unpleasant results if VLAN filtering is applied inappropriately, which is also described in the document you have referenced. This is merely a logical consequence of how the MSTP works, and is not Cisco-proprietary.
The Cisco-proprietary addition in this case is the so-called PVST+ Simulation which takes place on MSTP Boundary ports, which basically results in the MSTI0 (i.e. the IST) information being advertised out the Boundary port in PVST+/RPVST+ BPDUs for each known VLAN, and conversely, replicating each received PVST+/RPVST+ BPDU onto the IST. There are some caveats about this process and in some recent IOS versions for higher Catalyst series, this PVST Simulation mode can be deactivated.
Please ask further if there is anything unclear.
Hello Peter and thanks for your answer.
I had supposed that, for example, if a MSTI is mapped to VLANs 10, 20, 30, than
the active ports for that MSTI are those, trunks and access, which have at least one of
VLANs 10, 20, 30.
But right now, after your answer, I have realized that it would be possible to have some VLANs broken the same.
I had not considered this aspect and thanks for having done me realized my conceptual error.
So, you are probably correct when you say "how would you want to do that, anyway?
A single MSTI instance can be shared by multiple VLANs that can be individually allowed or filtered on a port or a trunk".
But the document I have referenced has a strange example.
I have added the image in my answer.
It seems that BPDUs are different and depend on VLANs configured on the ports.
What do you think about?
What the exhibit shows is in fact two switches interconnected via two access ports, one being in VLAN 10 and the other in VLAN 20 (a similar configuration could be achieved using trunks with the switchport trunk alloved vlan command). Now, the exhibit says that:
Now, this slightly contradicts what I have written before, doesn't it? The fact is that I am not quite sure right now if this is indeed what Catalysts do, and I will have to make a quick test in a lab. I'll be back here in an hour or two with a more precise answer. My thinking tells me that either option would work - either enclosing Mrecords for all instances, ignoring the VLANs on the port, or enclosing only those Mrecords for which there are allowed VLANs on the port.
Thank you that you have asked. Actually, I take some things for granted too soon. You are actually helping me here, and I am thankful for that!
So I've made a couple of experiments on 2960 series running 12.2(55)SE IOS and I can confirm that the exhibit is actually correct. In Cisco MSTP implementation, MSTP BPDUs contain Mrecords only for those MSTIs for which there are allowed VLANs on the port. Sending Mrecords for MSTIs that do not correspond to any allowed VLAN on a port does not harm but at the same time, it does has no practical impact.
Moreover, I have skimmed over the 802.1Q-2005 standard but I could not find any definitive answer whether all Mrecords should be included in an MSTP BPDU or only active instances on a port. In other words, the 802.1Q seems to be undefined on this point - if I haven't overlooked anything.
Sorry if I misled anyone.
Thanks very much for your precious information. It helps me going on with MSTP.
I am reading the standard too in order to find the better comprehension of the argument,
even if the work seems hard because I would like to find a complete agree with the Cisco
documents about the implementation. If I find some alluring aspects I will tell you.
The VLAN membership of ports is not considered when calculating the active topology. Several Multiple Spanning Tree Instances (MSTIs) are defined as well as a Common Spanning Tree (CST) for RSTP compatibility. VLAN Identifiers (VIDs) are then mapped to MSTIs. So in the calculation of the tree, the VLAN membership of ports needs not be considered at all, only the bridge and port priorities, etc. Each bridge will indicate a priority for each MSTI and that is how different spanning trees are achieved. Cisco implements MST this way and it is in compliance with the standard.
Latest IEEE documentation can be found here: http://chand.lums.edu.pk/cs573/resources/802.1Q-2003.pdf
A nice wrap-up about the MSTP principle. Thanks for that!
One comment, though: the 802.1Q document you have referenced seems to be outdated. The current 802.1Q revision was published in 2005 (note that your URL references the 2003 version) and can be downloaded from
As a general rule, all 802 recommendations should first be tried to be downloaded directly from the IEEE site as they are guaranteed to be the most recent.