Re: MSTP & PVST+ interoperation

Oh my...

This thing IS quite interesting. And it makes me wonder how could I miss
it for so long! But well, if even Petr has some issues, that relieves me
somehow :)

This message (tries to) be a small resume of MST and PVST interaction on
cisco (current) switches. It was triggered by the impression that
brocade was able to do something that cisco can not do. This turned to
be false.

Topology:
2 L2 areas, one under MST control, one under PVST. More than one
boundaries, say 2.

*The MST area is (administrativelly) divided in regions that are
recognized by having common name, version and vlan mapping. Each region
runs some STP instances (MSTs) "shielded" from the rest of the world.
*Inside the region this allows for path diversity for different vlan groups.
*At region borders, links are considered boundary, and all MSTs are
clamped to the CIST, a common ST to all the MST area. A CST is formed
that hides region complexity by virtualizing the whole region as if it
were a single switch, with some liberties (like not having the same BID
at every port :)
*By extension, the whole MST area ends up presenting a sole CST to the
rest of the topology.
*PVST on the other hand has multiple STs that are visible at every place
the corresponding VLANs arrive, and that helps a lot in control/data
plane coherency (MSTP needs some admin help like not pruning any VLANS
and not using access ports :)

Now considering a couple of boundary switches B1 and B2, each STP makes
sure there is a path from B1 to B2 for every VLAN.
Joining both creates a cycle if not properly managed.
Given that only one path is shown via CST, it follows that it either
connects for all VLANS (and PVST should break the loop for all) or it
breaks (and PVST should connect for all).

The way PVST interconnects with PVST is by integrating the CST with PVST
vlan 1. That is the "master" vlan. All the other vlans on the PVST talk
in a special mode with the same CST, thus "folding" all STs. This
special mode is controlled by ensuring that the role the VLAN port
reaches is coherent with the Vlan 1 role.
Namely: If the port is ALT in vlan 1, it should be ALT in all the other
VLANS. If it is ROOT, same thing, if it is DESGN, same.

This state is easily achieved if the root is inside the MST area. All
boundary ports end up being designated.
It is trickier when the root is on the PVST side: on the border where
the PVST vlan 1 is the root port (the master switch for MSTP), the
dispute of the role on another VLAN will compare VLAN 1 root BID with
the other VLAN root BID and it should *loose* to get into root port role
and be consistent. This is not easy and requires:

-All PVSTs should have better root BIDs than the MST switches
-PVST root for Vlan 1 should be worse than any other PVST vlan

Or else, you get a nasty root port blocked, and an L2 domain partitioned.

Cisco could have done better ? Well, it would be easier if you could
choose which VLAN you want to follow. But not much more than that.
Also, extended BIDs of cisco make the default assignment exactly the
opposite of what's needed (Vlan 1 gets better than the rest).

And Brocade ? Well, you can not use topology groups and master vlans if
you use MST.

-Carlos

Yuri Bank @ 26/09/2012 15:36 -0300 dixit:
> Contrary to popular opinion, this is possible! You can have the Root
> bridge on the PVST+ side( I still don't recommend it though ).
>
> In order for this to work, you must configure the STP priorities in
> the following manner:
>
> A. Priority for VLAN 1 on the PVST+ switch should be lower than IST0
> on the MSTP side.
> B. All other VLANS on the PVST+ Root should have a priority lower than vlan 1.
>
> Example:
>
> PVST+ Switch:
>
> VLAN 1 Priority: 8192
> VLAN 2-100: Priority 4096
>
>
> MSTP Switch:
>
> IST0 Priority: 16384
>
>
> To summarize. MSTP must have a consistent view of the state of its
> PVST boundary port. Due to the nature of extend system-id, the
> priority values that the MSTP switch sees are inconsistent, and since
> IST0 is replicated on all other vlans (at the boundary) the MST switch
> thinks the port is ROOT on vlan 1, but DESIGNATED on all of the other
> vlans(since the priority on vlan 1 was lower!) So, you must make the
> MSTP switch believe the port, and all vlans it receives BPDU's from
> are better. (Another solution is to disable extend system-id, but that
> isn't possible on many platforms).
>
>
> I had the same question a while ago. Excellent explanation is here. (
> scroll to the bottom )
> https://supportforums.cisco.com/thread/163062
>
>
> -Yuri
>
>
>
> On Wed, Sep 26, 2012 at 5:00 AM, Carlos G Mendioroz <tron_at_huapi.ba.ar> wrote:
>> After some more thinking ... if the merging code agrees to a vlan to be used
>> as "designed" CST on the PVST side, then it would work. I guess that is the
>> Brocade master vlan. Nice to know, and an interesting thing if cisco does
>> not support something on the line.
>>
>> -Carlos
>>
>> Tony Singh @ 26/09/2012 08:17 -0300 dixit:
>>
>>> Not sure of the solutions for this but afaik you would be breaking stp
>>> rules hence port inconsistent state!
>>>
>>> Schedule an outage and migrate to mst.
>>>
>>> --
>>> BR
>>>
>>> Tony
>>>
>>> Sent from my iPhone on 3
>>>
>>> On 26 Sep 2012, at 11:04, Viet-Hung TON <vton_at_integra.fr> wrote:
>>>
>>>> Hi Carlos,
>>>>
>>>> In the boundary switch between the MSTP and PVST, as this router see the
>>>> *ROOT* is actually not in the MSTP domain, this device push the
>>>> interface in an inconsistency state *BKN* althoudh they see the root
>>>> bridge through this port. This case is really like the scenario 3:
>>>> *PVST+ and MSTP interoperation* in the blog:
>>>> http://blog.ine.com/2008/09/24/mstp-tutorial-part-ii-outside-a-region/
>>>>
>>>> But the problem we have is that we cannot change the Root bridge to the
>>>> domain of MSTP as mentions in the example.
>>>>
>>>> That's why I search for a solution which is like the VLAN master in
>>>> topology-group of Brocade that permit resolving this case.
>>>>
>>>> Thanks,
>>>>
>>>> Viet
>>>>
>>>> On 09/26/2012 11:46 AM, Carlos G Mendioroz wrote:
>>>>>
>>>>> Why do you say "the MST region wants to have the Root Bridge inside" ?
>>>>> As you say you control the MST area, this "wants" relates to which
>>>>> entity ? MST has internal regional root and "global" root bridges.
>>>>>
>>>>> AFAIK, cisco's MST implementation knows how to merge into a PVST area.
>>>>> And that is reflected by the "Bound(PVST)" label (region boundary,
>>>>> PVST).
>>>>>
>>>>> Are your areas multiply connected ?
>>>>>
>>>>> -Carlos
>>>>>
>>>>> Viet-Hung Ton @ 25/09/2012 21:01 -0300 dixit:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I have a region of MSTP that must communicate with a zone of PVST.
>>>>>> Because of historical reason, I must leave the Root bridge in the
>>>>>> PVST+ zone, but in theory, the MSTP region want to have the Root
>>>>>> Bridge inside, that's why interfaces of routers in this region are in
>>>>>> the unfunctional state when doing a "show spanning-tree":
>>>>>>
>>>>>> Root BKN* 20000 128.1 P2p Bound(PVST) *PVST
>>>>>>
>>>>>> Do you have any ideas how to resolve this problem considering that I
>>>>>> can just change the configuration in the MSTP zone but not to PVST
>>>>>> zones?
>>>>>>
>>>>>> Is there any things of Cisco like Topology-group with the Master Vlan
>>>>>> of Brocade, where we can take a Vlan in mode PVST and mapping all
>>>>>> others Vlans to this Vlan (only one instance of PVST)?
>>>>>>
>>>>>> Thanks for your help,
>>>>>>
>>>>>> Viet
>>>>>>
>>>>>>
>>>>>> Blogs and organic groups at http://www.ccie.net
>>>>>>
>>>>>> _______________________________________________________________________
>>>>>> Subscription information may be found at:
>>>>>> http://www.groupstudy.com/list/CCIELab.html
>>>>
>>>>
>>>>
>>>> Blogs and organic groups at http://www.ccie.net
>>>>
>>>> _______________________________________________________________________
>>>> Subscription information may be found at:
>>>> http://www.groupstudy.com/list/CCIELab.html
>>>
>>>
>>>
>>> Blogs and organic groups at http://www.ccie.net
>>>
>>> _______________________________________________________________________
>>> Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> --
>> Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI Argentina
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>

-- 
Carlos G Mendioroz  <tron_at_huapi.ba.ar>  LW7 EQI  Argentina
Blogs and organic groups at http://www.ccie.net