MSTP and Rapid-PVST+












5















We have a medium sized network running all Juniper except for one building. This building is shared with another group, and is completely Cisco. We just trunk our VLANs up there.



Our Juniper network is configured with MSTP with all VLANs belonging to the CIST. All the Ciscos at the other building run rapid-pvst.



The two protocols are not playing well together at all. The Cisco connecting to our Juniper network has put the trunk port in a blocking state multiple times, even though that link is the only link between the two buildings.



What is the recommended implementation? I'm leaning towards just disabling spanning tree on the building uplink port, and letting the Ciscos just manage that building as its own separate spanning tree, and then the Junipers can manage everything else as its own spanning tree.



Thanks.










share|improve this question









New contributor




ZaZa is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
















  • 4





    Set your Cisco devices to run MST.

    – Cown
    yesterday






  • 1





    The best way (IMHO) is using Layer3 communication (routing, not switching) between two networks origins from two different organization and built with different vendors. But if you need the switching (or you don't have possibility to buy/install powerfull routers/firewalls between two networks), you can use MSTP on the Cisco equipment. Third variant, with disabling STP on the uplink - is possible, simple, and cheap, but it is not recommended. You should be very careful doing this and be sure you do not create the loop.

    – Konstantin Goncharenko
    yesterday
















5















We have a medium sized network running all Juniper except for one building. This building is shared with another group, and is completely Cisco. We just trunk our VLANs up there.



Our Juniper network is configured with MSTP with all VLANs belonging to the CIST. All the Ciscos at the other building run rapid-pvst.



The two protocols are not playing well together at all. The Cisco connecting to our Juniper network has put the trunk port in a blocking state multiple times, even though that link is the only link between the two buildings.



What is the recommended implementation? I'm leaning towards just disabling spanning tree on the building uplink port, and letting the Ciscos just manage that building as its own separate spanning tree, and then the Junipers can manage everything else as its own spanning tree.



Thanks.










share|improve this question









New contributor




ZaZa is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
















  • 4





    Set your Cisco devices to run MST.

    – Cown
    yesterday






  • 1





    The best way (IMHO) is using Layer3 communication (routing, not switching) between two networks origins from two different organization and built with different vendors. But if you need the switching (or you don't have possibility to buy/install powerfull routers/firewalls between two networks), you can use MSTP on the Cisco equipment. Third variant, with disabling STP on the uplink - is possible, simple, and cheap, but it is not recommended. You should be very careful doing this and be sure you do not create the loop.

    – Konstantin Goncharenko
    yesterday














5












5








5








We have a medium sized network running all Juniper except for one building. This building is shared with another group, and is completely Cisco. We just trunk our VLANs up there.



Our Juniper network is configured with MSTP with all VLANs belonging to the CIST. All the Ciscos at the other building run rapid-pvst.



The two protocols are not playing well together at all. The Cisco connecting to our Juniper network has put the trunk port in a blocking state multiple times, even though that link is the only link between the two buildings.



What is the recommended implementation? I'm leaning towards just disabling spanning tree on the building uplink port, and letting the Ciscos just manage that building as its own separate spanning tree, and then the Junipers can manage everything else as its own spanning tree.



Thanks.










share|improve this question









New contributor




ZaZa is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.












We have a medium sized network running all Juniper except for one building. This building is shared with another group, and is completely Cisco. We just trunk our VLANs up there.



Our Juniper network is configured with MSTP with all VLANs belonging to the CIST. All the Ciscos at the other building run rapid-pvst.



The two protocols are not playing well together at all. The Cisco connecting to our Juniper network has put the trunk port in a blocking state multiple times, even though that link is the only link between the two buildings.



What is the recommended implementation? I'm leaning towards just disabling spanning tree on the building uplink port, and letting the Ciscos just manage that building as its own separate spanning tree, and then the Junipers can manage everything else as its own spanning tree.



Thanks.







cisco juniper spanning-tree






share|improve this question









New contributor




ZaZa is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











share|improve this question









New contributor




ZaZa is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this question




share|improve this question








edited yesterday









Cown

6,52931030




6,52931030






New contributor




ZaZa is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









asked yesterday









ZaZaZaZa

283




283




New contributor




ZaZa is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





ZaZa is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






ZaZa is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.








  • 4





    Set your Cisco devices to run MST.

    – Cown
    yesterday






  • 1





    The best way (IMHO) is using Layer3 communication (routing, not switching) between two networks origins from two different organization and built with different vendors. But if you need the switching (or you don't have possibility to buy/install powerfull routers/firewalls between two networks), you can use MSTP on the Cisco equipment. Third variant, with disabling STP on the uplink - is possible, simple, and cheap, but it is not recommended. You should be very careful doing this and be sure you do not create the loop.

    – Konstantin Goncharenko
    yesterday














  • 4





    Set your Cisco devices to run MST.

    – Cown
    yesterday






  • 1





    The best way (IMHO) is using Layer3 communication (routing, not switching) between two networks origins from two different organization and built with different vendors. But if you need the switching (or you don't have possibility to buy/install powerfull routers/firewalls between two networks), you can use MSTP on the Cisco equipment. Third variant, with disabling STP on the uplink - is possible, simple, and cheap, but it is not recommended. You should be very careful doing this and be sure you do not create the loop.

    – Konstantin Goncharenko
    yesterday








4




4





Set your Cisco devices to run MST.

– Cown
yesterday





Set your Cisco devices to run MST.

– Cown
yesterday




1




1





The best way (IMHO) is using Layer3 communication (routing, not switching) between two networks origins from two different organization and built with different vendors. But if you need the switching (or you don't have possibility to buy/install powerfull routers/firewalls between two networks), you can use MSTP on the Cisco equipment. Third variant, with disabling STP on the uplink - is possible, simple, and cheap, but it is not recommended. You should be very careful doing this and be sure you do not create the loop.

– Konstantin Goncharenko
yesterday





The best way (IMHO) is using Layer3 communication (routing, not switching) between two networks origins from two different organization and built with different vendors. But if you need the switching (or you don't have possibility to buy/install powerfull routers/firewalls between two networks), you can use MSTP on the Cisco equipment. Third variant, with disabling STP on the uplink - is possible, simple, and cheap, but it is not recommended. You should be very careful doing this and be sure you do not create the loop.

– Konstantin Goncharenko
yesterday










1 Answer
1






active

oldest

votes


















8














You can set your Cisco devices to run MST, by issuing the command (in config mode):



spanning-tree mode mst


Other than that, i'll leave this excellent explanation by Peter Paluch (CCIE) on Cisco support forums, why you should not use Rapid PVST with MST.




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.




More info in the link:



https://community.cisco.com/t5/switching/migrating-from-rapid-pvst-to-mst/td-p/1792071






share|improve this answer



















  • 2





    One note: this kind of thing is best done off-hours when downtime is acceptable. Best case scenario is there is very brief downtime as STP reconverges. Worst case, adjustments have to made to both configs before the peering ports exit the blocking state.

    – Todd Wilcox
    yesterday











  • @ToddWilcox you are absolutely right.

    – Cown
    yesterday











  • @ToddWilcox Oh yeah... This can be a real sob to troubleshoot if you've got more than a trivial amount of switches. And before you begin make double sure that every access-port has bpdu-guard running. This to prevent a rogue switch hooked up somewhere in the periphery (like a developer somewhere that got a switch on his desk you didn't know about) throwing extra BPDU's at you. I've seen some (supposedly dumb) unmanaged switches that had no business doing STP send out BPDU with a 0-ID. Since that day I run BPDU-guard religiously on every access-port.

    – Tonny
    yesterday











Your Answer








StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "496"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});






ZaZa is a new contributor. Be nice, and check out our Code of Conduct.










draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fnetworkengineering.stackexchange.com%2fquestions%2f57647%2fmstp-and-rapid-pvst%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









8














You can set your Cisco devices to run MST, by issuing the command (in config mode):



spanning-tree mode mst


Other than that, i'll leave this excellent explanation by Peter Paluch (CCIE) on Cisco support forums, why you should not use Rapid PVST with MST.




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.




More info in the link:



https://community.cisco.com/t5/switching/migrating-from-rapid-pvst-to-mst/td-p/1792071






share|improve this answer



















  • 2





    One note: this kind of thing is best done off-hours when downtime is acceptable. Best case scenario is there is very brief downtime as STP reconverges. Worst case, adjustments have to made to both configs before the peering ports exit the blocking state.

    – Todd Wilcox
    yesterday











  • @ToddWilcox you are absolutely right.

    – Cown
    yesterday











  • @ToddWilcox Oh yeah... This can be a real sob to troubleshoot if you've got more than a trivial amount of switches. And before you begin make double sure that every access-port has bpdu-guard running. This to prevent a rogue switch hooked up somewhere in the periphery (like a developer somewhere that got a switch on his desk you didn't know about) throwing extra BPDU's at you. I've seen some (supposedly dumb) unmanaged switches that had no business doing STP send out BPDU with a 0-ID. Since that day I run BPDU-guard religiously on every access-port.

    – Tonny
    yesterday
















8














You can set your Cisco devices to run MST, by issuing the command (in config mode):



spanning-tree mode mst


Other than that, i'll leave this excellent explanation by Peter Paluch (CCIE) on Cisco support forums, why you should not use Rapid PVST with MST.




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.




More info in the link:



https://community.cisco.com/t5/switching/migrating-from-rapid-pvst-to-mst/td-p/1792071






share|improve this answer



















  • 2





    One note: this kind of thing is best done off-hours when downtime is acceptable. Best case scenario is there is very brief downtime as STP reconverges. Worst case, adjustments have to made to both configs before the peering ports exit the blocking state.

    – Todd Wilcox
    yesterday











  • @ToddWilcox you are absolutely right.

    – Cown
    yesterday











  • @ToddWilcox Oh yeah... This can be a real sob to troubleshoot if you've got more than a trivial amount of switches. And before you begin make double sure that every access-port has bpdu-guard running. This to prevent a rogue switch hooked up somewhere in the periphery (like a developer somewhere that got a switch on his desk you didn't know about) throwing extra BPDU's at you. I've seen some (supposedly dumb) unmanaged switches that had no business doing STP send out BPDU with a 0-ID. Since that day I run BPDU-guard religiously on every access-port.

    – Tonny
    yesterday














8












8








8







You can set your Cisco devices to run MST, by issuing the command (in config mode):



spanning-tree mode mst


Other than that, i'll leave this excellent explanation by Peter Paluch (CCIE) on Cisco support forums, why you should not use Rapid PVST with MST.




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.




More info in the link:



https://community.cisco.com/t5/switching/migrating-from-rapid-pvst-to-mst/td-p/1792071






share|improve this answer













You can set your Cisco devices to run MST, by issuing the command (in config mode):



spanning-tree mode mst


Other than that, i'll leave this excellent explanation by Peter Paluch (CCIE) on Cisco support forums, why you should not use Rapid PVST with MST.




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.




More info in the link:



https://community.cisco.com/t5/switching/migrating-from-rapid-pvst-to-mst/td-p/1792071







share|improve this answer












share|improve this answer



share|improve this answer










answered yesterday









CownCown

6,52931030




6,52931030








  • 2





    One note: this kind of thing is best done off-hours when downtime is acceptable. Best case scenario is there is very brief downtime as STP reconverges. Worst case, adjustments have to made to both configs before the peering ports exit the blocking state.

    – Todd Wilcox
    yesterday











  • @ToddWilcox you are absolutely right.

    – Cown
    yesterday











  • @ToddWilcox Oh yeah... This can be a real sob to troubleshoot if you've got more than a trivial amount of switches. And before you begin make double sure that every access-port has bpdu-guard running. This to prevent a rogue switch hooked up somewhere in the periphery (like a developer somewhere that got a switch on his desk you didn't know about) throwing extra BPDU's at you. I've seen some (supposedly dumb) unmanaged switches that had no business doing STP send out BPDU with a 0-ID. Since that day I run BPDU-guard religiously on every access-port.

    – Tonny
    yesterday














  • 2





    One note: this kind of thing is best done off-hours when downtime is acceptable. Best case scenario is there is very brief downtime as STP reconverges. Worst case, adjustments have to made to both configs before the peering ports exit the blocking state.

    – Todd Wilcox
    yesterday











  • @ToddWilcox you are absolutely right.

    – Cown
    yesterday











  • @ToddWilcox Oh yeah... This can be a real sob to troubleshoot if you've got more than a trivial amount of switches. And before you begin make double sure that every access-port has bpdu-guard running. This to prevent a rogue switch hooked up somewhere in the periphery (like a developer somewhere that got a switch on his desk you didn't know about) throwing extra BPDU's at you. I've seen some (supposedly dumb) unmanaged switches that had no business doing STP send out BPDU with a 0-ID. Since that day I run BPDU-guard religiously on every access-port.

    – Tonny
    yesterday








2




2





One note: this kind of thing is best done off-hours when downtime is acceptable. Best case scenario is there is very brief downtime as STP reconverges. Worst case, adjustments have to made to both configs before the peering ports exit the blocking state.

– Todd Wilcox
yesterday





One note: this kind of thing is best done off-hours when downtime is acceptable. Best case scenario is there is very brief downtime as STP reconverges. Worst case, adjustments have to made to both configs before the peering ports exit the blocking state.

– Todd Wilcox
yesterday













@ToddWilcox you are absolutely right.

– Cown
yesterday





@ToddWilcox you are absolutely right.

– Cown
yesterday













@ToddWilcox Oh yeah... This can be a real sob to troubleshoot if you've got more than a trivial amount of switches. And before you begin make double sure that every access-port has bpdu-guard running. This to prevent a rogue switch hooked up somewhere in the periphery (like a developer somewhere that got a switch on his desk you didn't know about) throwing extra BPDU's at you. I've seen some (supposedly dumb) unmanaged switches that had no business doing STP send out BPDU with a 0-ID. Since that day I run BPDU-guard religiously on every access-port.

– Tonny
yesterday





@ToddWilcox Oh yeah... This can be a real sob to troubleshoot if you've got more than a trivial amount of switches. And before you begin make double sure that every access-port has bpdu-guard running. This to prevent a rogue switch hooked up somewhere in the periphery (like a developer somewhere that got a switch on his desk you didn't know about) throwing extra BPDU's at you. I've seen some (supposedly dumb) unmanaged switches that had no business doing STP send out BPDU with a 0-ID. Since that day I run BPDU-guard religiously on every access-port.

– Tonny
yesterday










ZaZa is a new contributor. Be nice, and check out our Code of Conduct.










draft saved

draft discarded


















ZaZa is a new contributor. Be nice, and check out our Code of Conduct.













ZaZa is a new contributor. Be nice, and check out our Code of Conduct.












ZaZa is a new contributor. Be nice, and check out our Code of Conduct.
















Thanks for contributing an answer to Network Engineering Stack Exchange!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fnetworkengineering.stackexchange.com%2fquestions%2f57647%2fmstp-and-rapid-pvst%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Plaza Victoria

Puebla de Zaragoza

Musa