cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1955
Views
5
Helpful
9
Replies
Highlighted
Beginner

What does MST run at the region boundry?

I know it runs RSTP for each instance within the region, but does it run RSTP at the region boundry as well?

9 REPLIES 9
Highlighted

Re: What does MST run at the region boundry?

I know it runs RSTP for each instance within the region, but does it run RSTP at the region boundry as well?

Hi,

Every MSTP region runs special instance of spanning-tree known as IST or Internal Spanning Tree (=MSTI0). This instance is active on all links inside a region and serves the purpose of disseminating STP topology information for other STP instances.As usual, IST has a root bridge, elected based on the lowest bridge ID (priority/MAC address). However, situation changes when you have different regions in the network (e.g. switches with different region names, different revisions, etc). When a switch detects BPDU messages sourced from another region on any link, it marks the link as MSTP boundary.

Now two regions should build a common spanning tree known as CIST – Common and Internal Spanning Tree. This tree is result of joining ISTs of each region in a special manner.

Hope to Help !!

Ganesh.H

Highlighted
Beginner

Re: What does MST run at the region boundry?

Thanks Ganesh, but does the CST use rapid failover or is it legacy listening, learning, forwarding, etc.?

Highlighted
Hall of Fame Cisco Employee

Re: What does MST run at the region boundry?

Hello,

On a region boundary, the MSTP is able to run both RSTP and STP, according to the type of the neighbor. With two MSTP regions in particular, the RSTP should be running between them.

This is what both the theory and the current IEEE 802.1Q say. Unfortunately, the real MSTP implementation on Cisco switches behaves differently:

  • If the boundary port in MSTP is operating in access mode (switchport mode access) then the MSTP will revert to the RSTP operation (if the neighboring device is in a different MSTP region or if it is a RSTP switch). If the neighboring switch runs legacy 802.1D STP, the MSTP will understandably revert to STP.
  • If the boundary port in MSTP is operating in trunk mode (switchport mode trunk) then the MSTP will unconditionally revert to the legacy STP mode although it could run RSTP.

This means, plainly, that in multi-regional MSTP deployment where the regions are interconnected by trunk ports, Cisco's implementation of MSTP will revert to legacy 802.1D STP, negating all advantages of the RSTP on which the MSTP is built. And that is, in my opinion, a very sad design decision.

A plea to Cisco product managers and matter experts: I understand some of the rationale behind this design decision if the neighbor is a pure RSTP switch. However, running a large switched network divided into several MSTP regions is a perfectly valid thing to do. The current MSTP implementation on Catalyst switches, complemented with the PVST SImulation, makes using this (correct) kind of MSTP deployment almost impossible to do because of PVST Simulation failures and reverting to 802.1D between regions, preventing any kind of rapid convergence between regions which is otherwise possible according to pure MSTP. Please consider revisiting these limitations for the multi-region MSTP deployment.

Best regards,

Peter

Highlighted
Beginner

Re: What does MST run at the region boundry?

Wow that's very interesting.  What are some of the reasons behind that, even if the neighbor is running pure RSTP?

Highlighted
Hall of Fame Cisco Employee

Re: What does MST run at the region boundry?

Hello,

This is going to be a longer post.

See  this thread for introduction - here, Mr. Francois Tallet from Cisco  explains some of the rationale behind the curious MSTP/RSTP interaction:

https://supportforums.cisco.com/thread/26958

Also study this document closely:

http://www.cisco.com/en/US/customer/tech/tk389/tk621/technologies_white_paper09186a0080094cfc.shtml

Cisco's  implementation of MSTP tries to speak to PVST or PVRST neighbors by  using a so-called PVST Simulation mode, in which a MSTP boundary port  takes the IST (=MSTI0) information and replicates it in outbound PVST  BPDUs for all currently created VLANs. This is done in order to make the  entire region appear as a single PVST switch to the outside world. This  way, all PVST BPDUs originated by the boundary port contain the same information taken from the IST data.

Conversely, information received in BPDUs arriving at a  boundary port is replicated onto the IST running inside the region.  This poses actually a very strong requirement: if the outside world  speaks PVST then all BPDUs received on a boundary port, both standard  STP and PVST BPDUs, must contain identical information - the same root  bridge ID (some documents say that this is the only parameter that must  be identical), the same root path cost, sender bridge ID and sender port  ID, and probably even the timers (the PVST Simulation is not well  documented and I have had no opportunity to play with it in detail).  This is because the MSTP/PVST interaction does not try to sensibly map  external VLANs from PVST to MST instances, and even if it tried, it  would not be able to cope with situations where two different VLANs in  the PVST world have, say, different root bridges while in the MSTP  world, they share the same instance. To put it simply, if several BPDUs  arrive at the boundary port from the outside world, they must be  consistent - in effect identical - so that they can be easily and  uniquely replicated into the MST region on the IST. If they are not,  Cisco switches will block the boundary port and put it into PVST  Simulation Inconsistent state, preventing a possible loop but at the  same time cutting off the MSTP region from the rest of the network.

From what has been said so far, it follows that a  proper cooperation between MSTP and PVST region using PVST Simulation  can be achieved only in these two situations:

  • The MSTP region is the root for all existing VLANs, or
  • The PVST region is the root for all existing VLANs in such a way  that it has a single spanning tree shared for all existing VLANs (i.e.  identical root, identical active ports and links etc.) and no extended system ID is used in the PVST region

Because of the extended system ID commonly used in all  recent switches, the second option is usually not possible: even with a  single spanning tree shared for all VLANs in the PVST region, the root  bridge has different bridge ID for each VLAN because the bridge ID  contains the VLAN number in its lowest 12 bits. This, however, violates  the PVST Simulation requirement that all received PVST BPDUs on a  boundary port must contain identical information.

Now,  to your original question about MST/RSTP interaction: Mr. Tallet  suggested that it is difficult in PVST Simulation to maintain the  Proposal/Agreement on a per-VLAN basis. I would like to argue with that a  little. Technically, there is no problem with it, and the PVRST is in  fact doing that already, on a per-VLAN-per-port basis. I suppose,  however, that it can be a system resource hog to maintain the  Proposal/Agreement state information on a boundary port for up to 4094  possible VLANs and to tie that into the MSTP (although at the same time,  I really don't think it would be more resource-expensive than in  PVRST). Also, I suppose that most Cisco switches that support PVRST also  support MST, and that could be the reason why it does not actually make  much sense to implement an additional functionality into the PVST  Simulation if the neighboring switch can be configured to run MSTP  anyway.

A point to highlight here is that all this hassle is  caused by the PVST Simulation - originally a good intention but now  complicating things far beyond what is reasonable. The original and pure  MSTP specification without PVST Simulation makes it very simple: on a  boundary, the IST information is transmitted as normal RSTP/STP BPDU,  and the outside world is expected to run a single spanning tree without  any per-VLAN semantics so it has only one BPDU which can be happily  replicated onto the IST. Performing a Proposal/Agreement on a boundary  would be a matter of a single BPDU. It is the PVST Simulation that is  causing all these problems.

While Cisco software  engineers have obviously made a reasonable choice regarding the MST/RSTP  interoperation when all switches are made by Cisco, they have at the  same time somehow missed two other possible combinations:

  • Two (possibly Cisco) MSTP regions speaking to each other
  • A Cisco MSTP region speaking to a non-Cisco switch running a single shared RSTP for all VLANs

In both these cases, the PVST Simulation is useless  because besides Cisco, only very few other vendors speak PVST/PVRST, and  between MSTP regions, there is no point in running PVST/PVRST at all.

I wish very much that somebody who could influence these matters would attend this thread...

Best regards,

Peter

Highlighted
Beginner

Re: What does MST run at the region boundry?

Thanks for the detailed response

So how does an MST region interact with a single shared RSTP?

Highlighted
Hall of Fame Cisco Employee

Re: What does MST run at the region boundry?

Hi,

In Cisco's case, the trunk port to the RSTP region will emit both 802.1D legacy STP BPDUs and PVST BPDUs. The RSTP neighbor will fall back to STP operation. The boundary port will take information from MSTP IST and send it out in the STP BPDUs and PVST BPDUs, and will accept incoming STP BPDUs and replicate them into IST into the MSTP region. It will thus work nicely even though there will be no rapid convergence.

Don't worry about the PVST Simulation in your case. The PVST BPDUs will not be interpreted by the RSTP region and will be simply tunelled through it as if the entire RSTP region was just a wire for the PVST. The RSTP region will still use only a single shared tree and will thus meet the PVST Simulation requirements for consistent BPDUs.

Best regards,

Peter

Highlighted
Rising star

Re: What does MST run at the region boundry?

Peter,

I've just come across this thread by chance, I unfortunately don't follow this forum any more (I'm now working on FabricPath;-)

I just wanted to mention that PVST simulation is only started on a port that receives "PVST" BPDUs.

As a result, a Cisco switch running MST will interact according to IEEE standard RSTP rules when connected to another Cisco (or non-Cisco) switch running MST and in a different region, or with another switch running RSTP. No PVST simulation there.

Then, for historic purposes;-) let me clarify why we don't do proposal/agreement in PVST simulation

- when we developed MST in IOS, we did not think we would market Rapid-PVST. We thought that our customers would transition directly to MST. So there was no rapid-PVST to interact with

- the first version of the proposal/agreement introduced by the IEEE mandated that the agreement was a copy of the proposal BPDU received, with the agreement bit set. So indeed, implementing the proposal/agreement mechanism on a per vlan basis was roughly as expensive and complex as running rapid-PVST on the port because we would have had to maintain a context per vlan.

Thanks and regards,

Francois

Highlighted

Re: What does MST run at the region boundry?

Hi,

I´m trying a little bit around in my Lab to get a better understanding about MSTP and would like to ask a question about the Region Boundary...

 

you`d find my LAB-network as attachment where the following things are not 100% clear to me :(

-) regarding to the text from @Peter Paluch I think I understand why the STP-Mode which is choosen is regular 802.1d STP instead of RSTP... but why does the other MSTP-Switch show the Port connected to the RSTP Switch not as Boundary Port as well?


@Peter Paluch wrote:

Hello,

 

On a region boundary, the MSTP is able to run both RSTP and STP, according to the type of the neighbor. With two MSTP regions in particular, the RSTP should be running between them.

 

This is what both the theory and the current IEEE 802.1Q say. Unfortunately, the real MSTP implementation on Cisco switches behaves differently:

 

  • If the boundary port in MSTP is operating in access mode (switchport mode access) then the MSTP will revert to the RSTP operation (if the neighboring device is in a different MSTP region or if it is a RSTP switch). If the neighboring switch runs legacy 802.1D STP, the MSTP will understandably revert to STP.
  • If the boundary port in MSTP is operating in trunk mode (switchport mode trunk) then the MSTP will unconditionally revert to the legacy STP mode although it could run RSTP.

 

This means, plainly, that in multi-regional MSTP deployment where the regions are interconnected by trunk ports, Cisco's implementation of MSTP will revert to legacy 802.1D STP, negating all advantages of the RSTP on which the MSTP is built. And that is, in my opinion, a very sad design decision.

hoping for an answer which clarifys my inexperience... thank you!

 

CreatePlease to create content
Content for Community-Ad