cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Join Customer Connection to register!
19243
Views
40
Helpful
9
Replies
bridgepartners
Beginner

Migrating from Rapid-PVST+ to MST

We wish to migrate our Rapid-PVST+ network of around 25 switches to MST but for reasons that we believe are valid we do not want to start with the core switches. We want to convert one part of our network first that is connected to the core with a single trunk link.

We are refering to this document: Understanding Multiple Spanning Tree Protocol (802.1s) and in particular the section headed 'Alternate Configuration (Not Recommended)'. We can accomodate the drawbacks of this scenario, and in any case it will only be a temporary setup unitl we complete the migration.

Under 'Invalid Configuration' it states that "If the PVST+ bridge is the root, this bridge must  be the root for all VLANs (including the CST, which always runs on VLAN  1, regardless of the native VLAN, when the CST runs PVST+)". My question is if this is strictly correct (the border bridge MUST be the root for all the VLANs) or if the PVST+ sub-section as a whole must contain the root (e.g. the next PVST+ bridge in the topology would also be valid if its priority were high enough)?

Daniel

1 ACCEPTED SOLUTION

Accepted Solutions
Peter Paluch
Hall of Fame Cisco Employee

Hi Daniel,

Let me start by explaining what is the problem with MSTP/PVST+ interoperation. Things to watch out for are direct consequences of the interoperation limitations so it is vital to understand what is going on.

When MSTP region is connected to an (R)PVST+ region, it tries to speak (R)PVST+ and process received (R)PVST+ BPDUs. This process is called PVST Simulation. However, there are major difficulties in this process: the (R)PVST+ uses per-VLAN semantics while MSTP runs instances with VLANs simply mapped onto them. The role and state of an MSTP boundary port is always determined by the IST ( = MSTI0) instance talking to the outside world, and is simply inherited by all instances running in the MSTP region. That means that if the port is discarding in IST, it is discarding in all instances (and hence all VLANs). If the port is forwarding in IST, it is forwarding in all instances (and hence all VLANs). The same goes for every role/state combination. This fact makes it impossible to do any per-VLAN semantics on an MSTP boundary port. Even if you tried to map incoming (R)PVST+ BPDUs into appropriate instances, you could arrive to an unsolvable situation where the port should be discarding for one VLAN and forwarding for another, although they are both mapped to the same MSTP instance.

These limitations are the guidelines according to which the PVST Simulation works. Because the MSTP boundary port should use only IST data when speaking to the outside world (that is how MSTP boundary port should operate according to IEEE specifications), PVST Simulation makes use of it: it takes the IST data and replicates it into PVST+ BPDUs sent out for all VLANs defined on the switch. In other words, an MSTP boundary port speaking to PVST+ region sends one PVST+ BPDU for each VLAN that is defined on the switch, using IST data as the contents of this BPDU. Essentially, this makes the entire MSTP region look like a single huge switch identically configured for each and every VLAN, with the configuration simply taken from the IST.

Doing this is easy. However, the opposite process is much more constraining: an MSTP boundary port tries to process every received PVST+ BPDU using the IST instance. This is where the troubles begin. If all received PVST+ BPDUs are supposed to allow stable and unambiguous determination of the MSTP boundary port role and state, they must be identical, i.e. the same Root Bridge ID, the same Sending Bridge ID, same Root Path Cost, same Sending Port ID, perhaps even the same timers in each received PVST+ BPDU (sorry for the "perhaps" word here - the PVST Simulation is practically undocumented and these are only my experiences - some areas are still white). Failure to meet this requirement, i.e. receiving two or more differing PVST+ BPDUs on an MSTP boundary port, results in PVST Simulation inconsistency and into permanent blocking of that port until the conflicting PVST+ BPDUs cease to be received.

Note that this requirement of receiving identical PVST+ BPDUs is impossible to achieve with current Catalyst switches: every recent Catalyst switch is using Extended System ID, i.e. it inserts the VLAN ID into the Bridge ID when creating a BPDU for a particular VLAN. Even if you configured the PVST+ region so that a single switch was the root bridge for all VLANs, its PVST+ BPDUs would still differ because each of them would carry a different Extended System ID in the RBID/SBID field.

The only way to prevent these problems is to make sure that the MSTP region is considered as the root switch for all VLANs. Because it is the IST whose data is visible outside the MSTP region, this can be accomplished by configuring the bridge priority on the IST root bridge so low that it beats all switches in the PVST+ region and thereby becomes the root bridge for all VLANs.

Now to your questions:

We are refering to this document:

Understanding Multiple Spanning Tree Protocol (802.1s)

and in particular the section headed 'Alternate Configuration (Not  Recommended)'. We can accomodate the drawbacks of this scenario, and in  any case it will only be a temporary setup unitl we complete the  migration.

That document is a perfect reference. However, it does not describe the troubles related to the PVST Simulation because it does not take the Extended System ID into account. In fact, the scenario with the PVST+ region containing the root bridge for all VLANs is not possible to accomplish with current Catalyst switches. It is ironical that by striving for compatibility between MSTP and Cisco (R)PVST+, Cisco has actually created a situation where it is very easy to be incompatible. So in my opinion, you cannot accomodate for such a setup - you can not afford having a root switch in the PVST+ region because that would most probably lead to MSTP boundary ports being blocked due to PVST Simulation inconsistency.

I shall stress that these problems are created in particular by the PVST Simulation. Switches running pure IEEE STP/RSTP do not cause these problems because they run a single (R)STP instance for all VLANs. An MSTP boundary port can talk to a single external (R)STP always without problems - a single (R)STP can never produce two conflicting BPDUs. It is as easy as that. It is the overdone striving for compatibility with PVST+ BPDUs that is causing these troubles.

Under 'Invalid Configuration' it states that "If the PVST+ bridge is the  root, this bridge must  be the root for all VLANs (including the CST,  which always runs on VLAN  1, regardless of the native VLAN, when the  CST runs PVST+)". My question is if this is strictly correct (the border  bridge MUST be the root for all the VLANs) or if the PVST+ sub-section  as a whole must contain the root (e.g. the next PVST+ bridge in the  topology would also be valid if its priority were high enough)?

It is not the border bridge exactly that must be the root bridge for all VLANs. As I explained earlier, the MSTP region talks to the outside world using IST data. If the MSTP region is to become a root bridge for all VLANs, then the IST root bridge priority must be the lowest among all PVST+ bridges. The IST root bridge itself can perfectly be an internal switch somewhere deep inside the MSTP region.

The same would be valid if the PVST+ region was to become the region containing the root bridge for all VLANs. This root bridge can be any switch inside the PVST+ region, not just a boundary switch. However, this would require, among other things, deactivating the Extended System ID which is not possible.

Please feel welcome to ask further!

Best regards,

Peter

View solution in original post

9 REPLIES 9
Peter Paluch
Hall of Fame Cisco Employee

Hi Daniel,

Let me start by explaining what is the problem with MSTP/PVST+ interoperation. Things to watch out for are direct consequences of the interoperation limitations so it is vital to understand what is going on.

When MSTP region is connected to an (R)PVST+ region, it tries to speak (R)PVST+ and process received (R)PVST+ BPDUs. This process is called PVST Simulation. However, there are major difficulties in this process: the (R)PVST+ uses per-VLAN semantics while MSTP runs instances with VLANs simply mapped onto them. The role and state of an MSTP boundary port is always determined by the IST ( = MSTI0) instance talking to the outside world, and is simply inherited by all instances running in the MSTP region. That means that if the port is discarding in IST, it is discarding in all instances (and hence all VLANs). If the port is forwarding in IST, it is forwarding in all instances (and hence all VLANs). The same goes for every role/state combination. This fact makes it impossible to do any per-VLAN semantics on an MSTP boundary port. Even if you tried to map incoming (R)PVST+ BPDUs into appropriate instances, you could arrive to an unsolvable situation where the port should be discarding for one VLAN and forwarding for another, although they are both mapped to the same MSTP instance.

These limitations are the guidelines according to which the PVST Simulation works. Because the MSTP boundary port should use only IST data when speaking to the outside world (that is how MSTP boundary port should operate according to IEEE specifications), PVST Simulation makes use of it: it takes the IST data and replicates it into PVST+ BPDUs sent out for all VLANs defined on the switch. In other words, an MSTP boundary port speaking to PVST+ region sends one PVST+ BPDU for each VLAN that is defined on the switch, using IST data as the contents of this BPDU. Essentially, this makes the entire MSTP region look like a single huge switch identically configured for each and every VLAN, with the configuration simply taken from the IST.

Doing this is easy. However, the opposite process is much more constraining: an MSTP boundary port tries to process every received PVST+ BPDU using the IST instance. This is where the troubles begin. If all received PVST+ BPDUs are supposed to allow stable and unambiguous determination of the MSTP boundary port role and state, they must be identical, i.e. the same Root Bridge ID, the same Sending Bridge ID, same Root Path Cost, same Sending Port ID, perhaps even the same timers in each received PVST+ BPDU (sorry for the "perhaps" word here - the PVST Simulation is practically undocumented and these are only my experiences - some areas are still white). Failure to meet this requirement, i.e. receiving two or more differing PVST+ BPDUs on an MSTP boundary port, results in PVST Simulation inconsistency and into permanent blocking of that port until the conflicting PVST+ BPDUs cease to be received.

Note that this requirement of receiving identical PVST+ BPDUs is impossible to achieve with current Catalyst switches: every recent Catalyst switch is using Extended System ID, i.e. it inserts the VLAN ID into the Bridge ID when creating a BPDU for a particular VLAN. Even if you configured the PVST+ region so that a single switch was the root bridge for all VLANs, its PVST+ BPDUs would still differ because each of them would carry a different Extended System ID in the RBID/SBID field.

The only way to prevent these problems is to make sure that the MSTP region is considered as the root switch for all VLANs. Because it is the IST whose data is visible outside the MSTP region, this can be accomplished by configuring the bridge priority on the IST root bridge so low that it beats all switches in the PVST+ region and thereby becomes the root bridge for all VLANs.

Now to your questions:

We are refering to this document:

Understanding Multiple Spanning Tree Protocol (802.1s)

and in particular the section headed 'Alternate Configuration (Not  Recommended)'. We can accomodate the drawbacks of this scenario, and in  any case it will only be a temporary setup unitl we complete the  migration.

That document is a perfect reference. However, it does not describe the troubles related to the PVST Simulation because it does not take the Extended System ID into account. In fact, the scenario with the PVST+ region containing the root bridge for all VLANs is not possible to accomplish with current Catalyst switches. It is ironical that by striving for compatibility between MSTP and Cisco (R)PVST+, Cisco has actually created a situation where it is very easy to be incompatible. So in my opinion, you cannot accomodate for such a setup - you can not afford having a root switch in the PVST+ region because that would most probably lead to MSTP boundary ports being blocked due to PVST Simulation inconsistency.

I shall stress that these problems are created in particular by the PVST Simulation. Switches running pure IEEE STP/RSTP do not cause these problems because they run a single (R)STP instance for all VLANs. An MSTP boundary port can talk to a single external (R)STP always without problems - a single (R)STP can never produce two conflicting BPDUs. It is as easy as that. It is the overdone striving for compatibility with PVST+ BPDUs that is causing these troubles.

Under 'Invalid Configuration' it states that "If the PVST+ bridge is the  root, this bridge must  be the root for all VLANs (including the CST,  which always runs on VLAN  1, regardless of the native VLAN, when the  CST runs PVST+)". My question is if this is strictly correct (the border  bridge MUST be the root for all the VLANs) or if the PVST+ sub-section  as a whole must contain the root (e.g. the next PVST+ bridge in the  topology would also be valid if its priority were high enough)?

It is not the border bridge exactly that must be the root bridge for all VLANs. As I explained earlier, the MSTP region talks to the outside world using IST data. If the MSTP region is to become a root bridge for all VLANs, then the IST root bridge priority must be the lowest among all PVST+ bridges. The IST root bridge itself can perfectly be an internal switch somewhere deep inside the MSTP region.

The same would be valid if the PVST+ region was to become the region containing the root bridge for all VLANs. This root bridge can be any switch inside the PVST+ region, not just a boundary switch. However, this would require, among other things, deactivating the Extended System ID which is not possible.

Please feel welcome to ask further!

Best regards,

Peter

View solution in original post

Thank you Peter for your extremely helpful reply.

you can not afford having a root switch in the PVST+ region because that would most probably lead to MSTP boundary ports being blocked due to PVST Simulation inconsistency.

I believe that this is the behaviour we saw in the lab: the link to the MST region was blocked when we did not expect it to be.

It seems that the options for our migration would be to a) change everything during one major outage or b) place the root in the MST region. The latter option does not seem ideal given our topology, but it would work.

In researching this I am actually beginning to question if we really want to migrate to MST at all. We have about 120 VLANs (relating to different customers) and at present a spanning tree renegotiation on one VLAN does not affect any other. The downside of our current setup is that troublehooting STP is very opaque. Under MST the addition of a new VLAN would trigger a spanning tree renegotiation for the whole instance. Our topology only requires two instances and so many VLANS would suffer a brief outage pretty often. We could be better off staying with RPVST+ or, possibly, having more instances than the topogoly requires (maybe ten, for example).

Daniel

Peter Paluch
Hall of Fame Cisco Employee

Daniel,

Adding a new VLAN does not cause any renegotiation per se in MSTP. Note that the VLANs are pre-mapped into MSTP instances before they even exist:

Switch# show span mst configuration

Name      [ABCD]

Revision  1     Instances configured 2

Instance  Vlans mapped

--------  ---------------------------------------------------------------------

0         1-4,6-10,16-998,1000-4094

1         5,11-15,999

-------------------------------------------------------------------------------

This is a 3560G having 12 VLANs defined (5 built-in plus 7 manually added), however, the entire range of VLAN IDs is already mapped onto instances 0 and 1 in my case. In fact, if a VLAN is not explicitly mapped anywhere, it is mapped into IST. A particular instance is run if there is at least one VLAN existent that is mapped onto it , but how many VLANs are mapped - that makes no difference to the instance itself.

So do not worry - adding a VLAN does not cause MSTP renegotiations because MSTP runs in instances, not in VLANs.

There are recommendations to pre-map the VLANs into particular instances beforehand, say, by batches of 100 or 50 IDs, and adding a new VLAN afterward immediately makes sure that there is a particular instance onto which it is mapped (possibly a different instance than IST).

Best regards,

Peter

Oops! I have only recently noticed that RPVST+ has a limitation of 128 VLANs on smaller Catalyst switches like the 3560. Pretty important fact for this discussion, I guess.

Daniel

Hi,

Peter wonderful answer.

I would add some blogs from Petr Lapukhov I have read not so long ago on the point which you may find useful too.

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

http://blog.internetworkexpert.com/2008/07/27/mstp-tutorial-part-i-inside-a-region/

http://blog.ine.com/2008/09/24/mstp-tutorial-part-ii-outside-a-region/

Best regards,

Alex

Peter Paluch
Hall of Fame Cisco Employee

Hello Alex,

Thank you! In fact, I learned most of my MSTP knowledge exactly from the Petr Lapukhov's blog you have referenced here. Petr made a very good job in explaining the guts of MSTP indeed!

Best regards,

Peter

Hello Peter,

Thanks for the nice explanation.

I was running into the same kind of issue. Now, it's clear to me.

I just want to share my test result since i'm also in the migration phase from R-PVST to MST.

I was able to see "Root Inc/PVST Inc" whenever I blocked VLAN 1(Excluded from the allowed-vlan list)  in the PVST switch. Once I allowed VLAN 1 in the PVST switch (NOT in the MST switches), the inconsistency was lost. Not sure about the reason behind it, hope you will be able to respond me even though it's very old thread.

Additionally, I would apprecaite if you could explain the difference between Root Inc & PVST Inc.

Thanks!

Hi Daniel,

I know this is pretty old a post. Just curious, did you migrate your network to MST?

MST looks pretty but it is very painful to when you need a new topology in your network. A change of VLAN to instance mapping would make multiple MST regions. In some platform, there isn't a method (there are VTP v3 but may not available across platforms) to propagate the MST configuration so it is a manual process and may need maintenance window to perform the work.

I think it is suitable more for static network. Just wondering what is your experience with your multi-tenant environment.

Peter really did a fantastic job in explaining the interactivity between MST and PVST. It must come from lots of real time experiences, not only through reading. Thank you Peter!

Thanks.

Dmitry Semiz
Beginner

I know it is very old post, but I have the same case now. Please can anyone suggest the right solution?

 

I need to migrate about 100 switches from PVST+ to MST. Am I correct, that the right method to do so is

1) Make a single root bridge for all VLANs

2) Convert it to MST, while ensuring that it still will be root bridge for PVST+ domain

3) Connect to the closest switch from root, convert it to mst, then next closest switch and so on.