MST and Rapid spanning tree interaction.

Unanswered Question
Sep 25th, 2007

Hi

Iam doing some testing in connecting a legacy network running Rapid PVST+ to our core network that runs MST.

The legacy network will have 2 links to the MST core network both as access ports. As expected one port goes into blocking. We then configured the 2 ports as trunks to give us more flexability but noticed that the boundary ports on the MST core connecting to the Legacy Rapid PVST+ network now negotiated to operate in legacy STP mode loosing the fast convergence of rapid PVST+.

Does anyone know why this is happening.

We have read the relevant RFCs and Cisco docs and can find nothing to explain what is happening.

Any feedback apreciated.

Regards

Kev

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
jsivulka Wed, 10/03/2007 - 07:24

If the RST region is a third party IEEE bridge btw, this will have an impact on all the vlans (as it is running a single instance of RSTP for all the vlans). If it is a region running Cisco's Rapid-PVST, the topology change will be limited to the instance in the MST region to which the vlan is mapped.The problem is that MST is running on the physical port, on at the vlan level.

Francois Tallet Wed, 10/03/2007 - 08:43

When the Cisco switch detects PVST BPDUs (whether this is rapid-PVST or plain PVST), it indeed goes into a PVST interaction mode and does not honor the proposal-agreement mechanism. As you observed, the convergence speed is similar to STP.

In PVST simulation mode, the MST switch is in fact replicating the MST 0 information to each and every vlan configured on the trunk connected to the PVST device. In the earlier RSTP/MST specification, an agreement needed to convey exactly the information that was sent in the proposal. In order to make the proposal/agreement work over the port running PVST simulation, we would thus have had to support one state machine per vlan. It was decided that it was not worth it, and we fell back to STP support on those ports running PVST simulation. One of the main argument for this move was that the interaction MST/PVST was not desirable anyway, and that it should be seen as a temporary solution during a migration to MST.

Regards,

Francois

Actions

This Discussion