Re: MST and PVST+ interaction

droeun141 · ‎02-07-2011

Since Cisco doesn't allow the CST root to be outside the region when interacting with a PVST+ switch, does that also mean that only one MST region can be presesnt? (imagine MST region A connected to MST region C through region B which only runs PVST+).

If there are two, wouldn't they both be requird to have the CST root inside their own respective regions? Thank you for any clarification!

Peter Paluch · ‎02-07-2011

Hello,

Since Cisco doesn't allow the CST root to be outside the region when interacting with a PVST+ switch

Why do you believe so? For PVST+, the CST region interacts with PVST+ VLAN1 in a completely usual way, and the PVST+ BPDUs for other VLANs are transparently tunelled across the CST region (as if the CST region was a simple common segment). With PVST+, there are no problems with the placement of the CST root switch - as far as I know, it can be positioned wherever you want.

does that also mean that only one MST region can be presesnt? (imagine 
MST region A connected to MST region C through region B which  only runs
 PVST+).

No, you can have multiple MST regions in your network. However, the interaction between MST regions, especially when additional PVST+ regions are present, is nontrivial. The problem is the PVST+ Simulation implemented in Cisco's MSTP. On an MST boundary trunk port, Cisco switches take data of the IST (MSTI0) instance and replicate it into egress PVST+ BPDUs for all VLANs defined and active on that trunk. Conversely, each received PVST+ BPDU is processed by the IST instance.

This poses a strong requirement on the incoming PVST+ BPDUs - all received PVST+ BPDUs must be identical (root bridge ID, root path cost, sending bridge ID, sending port ID, timers) save the VLAN ID because otherwise, the MSTI0 could not perform a definite, unambiguous decision about the role and state of the boundary trunk port. Note that with the extended system ID (the VLAN ID occupying a portion of the bridge ID), this requirement cannot be met if there are multiple VLANs running in the PVST+ region because even if a single PVST+ switch was the root for all VLANs, its bridge ID would differ for each VLAN. That is the primary reason why it is stressed that the MST region shall be the root either for all VLANs or for none (but in that case, the non-MSTP region must run CST only).

If there are two, wouldn't they both be requird to have the CST root inside their own respective regions?

With pure MSTP regions, only the IST instance "leaks out" from the region, not other MST instances, and the state of the boundary port as determined by the IST instance also influences all other instances defined in that region. If it is only the IST instance that in effect spans through the entire switched topology, creating the CIST (Common and Internal Spanning Tree), you can view it simply as a single tree with all usual rules about root election, root ports etc. Thus, while each region contains a "local" IST root (which is called CIST Regional Root), there is only one switch that is indeed the best, called simply the CIST Root, in which the CIST tree is rooted. The CST as you call it is actually a tree topology of the switched network that would be created if you considered the regions to be just large switches with no internal structure. Logically, such a CST has only one root.

I am not sure if this answers your questions - feel welcome to ask further!

Best regards,

Peter

droeun141 · ‎02-08-2011

Peter, as always, thank you for the detailed response! The question originally stems from an article I stumbled across that described the CST root placement inside the region:

It's under scenario 3 - PVST+ and MSTP interoperation:

http://blog.ine.com/2010/02/22/understanding-mstp/#MSTP_MULTI_SCENARIO3

Peter Paluch · ‎02-12-2011

Hello,

I sincerely apologize for answering lately.

I have had a look at the document by Petr Lapukhov you have referenced. I have some comments regarding his explanation but I guess I need to take it more slowly because I am myself trying to sort it out in the most comprehensive way.

Let's assume we have an MSTP region connected to a pure 802.1D region that speaks only 802.1D STP. Even if the 802.1D region understands VLANs, it does not have any per-VLAN STP semantics and spanning tree established by the single 802.1D instance is shared by all VLANs in the 802.1D region (which is how originally the IEEE envisioned it). In such case, it is absolutely fine and allowed to place the root bridge into the 802.1D region. Note that I am not talking "a root bridge for a particular VLAN" because a root bridge in the 802.1D region is a root bridge for all VLANs.

What the MSTP region does in this situation is that it talks, using its IST, to the 802.1D region just like another 802.1D switch - a single switch. It uses some tricks to appear as a single switch - not incrementing the Message Age, tunelling the External Root Path Cost without incrementing it, using the IST regional root BID as the sender BID in the BPDUs sent out on boundary ports. This way, it interacts with the 802.1D region in an absolutely common and normal way. Also, the 802.1D BPDUs received on boundary ports are simply processed by the IST instance so that a master port (i.e. the MST region's root port) and designated ports to possibly other regions are properly established. In any case, a state of a boundary part is made compulsory for all MST internal instances - i.e. a blocking boundary port is blocking for all instances (thus for all VLANs), a forwarding boundary port is forwarding for all VLANs.

I have concocted a small experiment in our lab where I configured a switch with an MSTP process, creating two instances and a number of VLANs sorted among these instances. The VLAN1 was left in MSTI0. Then I have configured an 1841 router for IRB between its two FastEthernet interfaces and started the 802.1D STP on the bridge group. Finally, I connected this 1841 with both Fa interfaces to the switch (the switch ports were configured for trunk), and configured the 1841 to be the STP root. I have used the 1841 because it speaks only plain STP, not PVST+, so it nicely emulates a pure 802.1D region. Guess what - everything worked as expected, with no PVST Simulation errors at all. The MSTP switch happily accepted the 1841 as the root bridge for the CIST, and declared one of its ports towards the 1841 as a root port, the other as an alternate blocking port. Of course, the MSTP switch became the root for the additional two MSTP instances but that is logical, as these instances never leak out from a region, and they are not influenced by the outside regions.

So when an MSTP and a pure 802.1D regions are interconnected, you can nicely have the CIST root in the 802.1D region.

Things get complicated if the 802.1D region is actually a PVST+ region which is something you always get when you have Cisco switches. The problems Petr Lapukhov actually described in his article are related not to the PVST+ region actually containing a root bridge - that should not be a problem according to my description earlier - but rather to problem with taking a bunch of PVST+ BPDUs, one for each VLAN arriving into a MSTP boundary port, and representing them towards the internal MSTP. How shall a switch process PVST+ BPDUs for, say, VLAN10 and VLAN20 that both contain different root BIDs, different costs, etc., and import them into the MSTP? What if the VLAN10 and VLAN20 share the same MSTP instance? Clearly, this does not work. The PVST Simulation is happy only if all PVST+ BPDUs arriving on a port are consistent which means they are in essence totally identical - the same root, the same sender, the same root path cost... Note that you cannot do this at all with modern Catalyst switches whose BID is different for each VLAN thanks to the extended system ID, even if the physical switch was the same for all VLANs!

What I find most troublesome is that Cisco does explain here and there that "there are some issues that must be observed with respect to the PVST Simulation so that it does not fail" but I was not able to find any concise document stating what exactly does the PVST Simulation do and when does it arrive into a failure (under which circumstances). My explanation above is founded only on some personal experience and partly deduced.

Please feel welcome to ask further!

Best regards,

Peter

sdheer · ‎02-07-2011

You may refer to the follwoing document which clearly explains all the exceptions with regards to the MST and PVST migration witha sample config.

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

Hope that helps.

Regards,

Swati

Please rate if you find content useful