Hello,
This is going to be a longer post.
See this thread for introduction - here, Mr. Francois Tallet from Cisco explains some of the rationale behind the curious MSTP/RSTP interaction:
https://supportforums.cisco.com/thread/26958
Also study this document closely:
http://www.cisco.com/en/US/customer/tech/tk389/tk621/technologies_white_paper09186a0080094cfc.shtml
Cisco's implementation of MSTP tries to speak to PVST or PVRST neighbors by using a so-called PVST Simulation mode, in which a MSTP boundary port takes the IST (=MSTI0) information and replicates it in outbound PVST BPDUs for all currently created VLANs. This is done in order to make the entire region appear as a single PVST switch to the outside world. This way, all PVST BPDUs originated by the boundary port contain the same information taken from the IST data.
Conversely, information received in BPDUs arriving at a boundary port is replicated onto the IST running inside the region. This poses actually a very strong requirement: if the outside world speaks PVST then all BPDUs received on a boundary port, both standard STP and PVST BPDUs, must contain identical information - the same root bridge ID (some documents say that this is the only parameter that must be identical), the same root path cost, sender bridge ID and sender port ID, and probably even the timers (the PVST Simulation is not well documented and I have had no opportunity to play with it in detail). This is because the MSTP/PVST interaction does not try to sensibly map external VLANs from PVST to MST instances, and even if it tried, it would not be able to cope with situations where two different VLANs in the PVST world have, say, different root bridges while in the MSTP world, they share the same instance. To put it simply, if several BPDUs arrive at the boundary port from the outside world, they must be consistent - in effect identical - so that they can be easily and uniquely replicated into the MST region on the IST. If they are not, Cisco switches will block the boundary port and put it into PVST Simulation Inconsistent state, preventing a possible loop but at the same time cutting off the MSTP region from the rest of the network.
From what has been said so far, it follows that a proper cooperation between MSTP and PVST region using PVST Simulation can be achieved only in these two situations:
- The MSTP region is the root for all existing VLANs, or
- The PVST region is the root for all existing VLANs in such a way that it has a single spanning tree shared for all existing VLANs (i.e. identical root, identical active ports and links etc.) and no extended system ID is used in the PVST region
Because of the extended system ID commonly used in all recent switches, the second option is usually not possible: even with a single spanning tree shared for all VLANs in the PVST region, the root bridge has different bridge ID for each VLAN because the bridge ID contains the VLAN number in its lowest 12 bits. This, however, violates the PVST Simulation requirement that all received PVST BPDUs on a boundary port must contain identical information.
Now, to your original question about MST/RSTP interaction: Mr. Tallet suggested that it is difficult in PVST Simulation to maintain the Proposal/Agreement on a per-VLAN basis. I would like to argue with that a little. Technically, there is no problem with it, and the PVRST is in fact doing that already, on a per-VLAN-per-port basis. I suppose, however, that it can be a system resource hog to maintain the Proposal/Agreement state information on a boundary port for up to 4094 possible VLANs and to tie that into the MSTP (although at the same time, I really don't think it would be more resource-expensive than in PVRST). Also, I suppose that most Cisco switches that support PVRST also support MST, and that could be the reason why it does not actually make much sense to implement an additional functionality into the PVST Simulation if the neighboring switch can be configured to run MSTP anyway.
A point to highlight here is that all this hassle is caused by the PVST Simulation - originally a good intention but now complicating things far beyond what is reasonable. The original and pure MSTP specification without PVST Simulation makes it very simple: on a boundary, the IST information is transmitted as normal RSTP/STP BPDU, and the outside world is expected to run a single spanning tree without any per-VLAN semantics so it has only one BPDU which can be happily replicated onto the IST. Performing a Proposal/Agreement on a boundary would be a matter of a single BPDU. It is the PVST Simulation that is causing all these problems.
While Cisco software engineers have obviously made a reasonable choice regarding the MST/RSTP interoperation when all switches are made by Cisco, they have at the same time somehow missed two other possible combinations:
- Two (possibly Cisco) MSTP regions speaking to each other
- A Cisco MSTP region speaking to a non-Cisco switch running a single shared RSTP for all VLANs
In both these cases, the PVST Simulation is useless because besides Cisco, only very few other vendors speak PVST/PVRST, and between MSTP regions, there is no point in running PVST/PVRST at all.
I wish very much that somebody who could influence these matters would attend this thread...
Best regards,
Peter
