Cfrgtkky

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.

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