7

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.

Improve this question
2
  • 4
    Set your Cisco devices to run MST.
    – user36472
    Mar 14, 2019 at 13:19
  • 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
    Mar 14, 2019 at 14:01

1 Answer 1

Reset to default
11

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

Improve this answer
3
  • 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
    Mar 14, 2019 at 19:22
  • @ToddWilcox you are absolutely right.
    – user36472
    Mar 14, 2019 at 19:23
  • @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
    Mar 14, 2019 at 20:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.