cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
16692
Views
5
Helpful
10
Replies

MST with a PVST+ CST ROOT

yuribank415
Level 1
Level 1

According to cisco you should be able to have a PVST+ switch act as the CIST ROOT if ALL vlans on the PVST+ switch have the lowest priority.

When I lab such a scenario I get PVST Simulation Inconsistent errors on my MST switches.

I also tried doing this with the common vlans between my PVST+ and MST switches, all assigned to the IST 0, but still with the same problems.

Could someone explain why this is happening, and if what I am trying to accomplish is even possible?

1 Accepted Solution

Accepted Solutions

gesadmin1
Level 1
Level 1

Yes it is possible, but not with how you have it configured. I could try to explain it but for the sake of brain power, take a look at this excerpt from Petr Lapukhov's blog where he talks about PVST+/MSTP interoperability:

"1) MSTP domain (either a single region or multiple regions) contains the root bridge for ALL VLANs. This is only true if CIST Root BID is better than any PVST+ STP root BID. This is the preferred design, for you can manipulate uplink costs on the PVST+ side and obtain optimal traffic engineering results.

2) PVST+ contains the root bridges for ALL VLANs, including VLAN1, which maps to CST of STP. This is only true is all PVST+ root bridges BIDs for all VLANs are better than CIST Root BID. This is not the preferred design, since all MSTIs map to CIST on the border link, and you cannot load-balance the MSTIs as the enter the PVST+ domain.

Cisco implementation does not support the second option. MSTP domain should contain the bridge with the best BID, to ensure that the CIST Root is also the root for all PVST+ trees. If any other case, MSTP border switch will complain and place the ports that receive superior BPDUs from PVST+ region in root-inconsistent state. To fix this issue, ensure that PVST+ domain does not have any bridges with BIDs better than the CIST Root Bridge ID."

View solution in original post

10 Replies 10

gesadmin1
Level 1
Level 1

Yes it is possible, but not with how you have it configured. I could try to explain it but for the sake of brain power, take a look at this excerpt from Petr Lapukhov's blog where he talks about PVST+/MSTP interoperability:

"1) MSTP domain (either a single region or multiple regions) contains the root bridge for ALL VLANs. This is only true if CIST Root BID is better than any PVST+ STP root BID. This is the preferred design, for you can manipulate uplink costs on the PVST+ side and obtain optimal traffic engineering results.

2) PVST+ contains the root bridges for ALL VLANs, including VLAN1, which maps to CST of STP. This is only true is all PVST+ root bridges BIDs for all VLANs are better than CIST Root BID. This is not the preferred design, since all MSTIs map to CIST on the border link, and you cannot load-balance the MSTIs as the enter the PVST+ domain.

Cisco implementation does not support the second option. MSTP domain should contain the bridge with the best BID, to ensure that the CIST Root is also the root for all PVST+ trees. If any other case, MSTP border switch will complain and place the ports that receive superior BPDUs from PVST+ region in root-inconsistent state. To fix this issue, ensure that PVST+ domain does not have any bridges with BIDs better than the CIST Root Bridge ID."

Ah great. Thanks for clearing that up for me. Petr's MST tutorial is wonderful.

Thanks for the responses guys!

Here is a link to the MST PVST+ tutorial if anybody else is interested:

http://blog.internetworkexpert.com/2008/09/24/mstp-tutorial-part-ii-outside-a-region/

Even if, again, it is certainly not a recommended configuration, having the CIST root outside of the MST region is a valid configuration. This document seems to suggest otherwise.

I've tried setting the priority on vlan 1 to 8192 and 4096 for the other vlans( 24k on the IST0 ) however I got the same results.

I guess cisco just decided to prevent people from doing this completely??

By making the whole stuff just impossibly complex maybe, but not on purpose;-)

I can help you troubleshoot that if you are interested. Else, if you can live with the restriction, or even better, if you can avoid PVST/MST interaction, then forget about it...

Regards,

Francois

Well I would be interested to know how one would go about doing this, for educational purposes.

My setup is as folllows

Triangle topology: Two MST switches in one region, and a PVST+ siwtch.

------

------------------

Lowest IST0 Priority is: 24576, on MSTswitch.A

I have vlan 1,2 and 3 on the PVST+ switch, and in the MST region.

on the PVST+ switch I have the following priorities.

8192 Vlan 1

4096 Vlan 2, 3

I've read that the way to accomplish this is by not using extended-ids, however my switches will not allow me to.

#no spanning-tree extend system-id

'This platform requires that the extended system-id feature remain enabled'

These 3 switches are Catalyst3550's

That might be educational for me too as I often mess this up;-) I don't see anything wrong with the config you describe. Extended sysid is orthogonal to the problem.

Just to make sure, I understand that:

- bridge B has priority 32k for MST0

- only vlan 1,2 and 3 are defined (specially important on the pvst switch).

Can you check (on both sides) the vlan range allowed on the trunks between the pvst switch and the mst switches?

Can you show me the inconsistency on the MST switch? I assume you have a PVST simulation failure inconsistency. You should have a syslog message telling you the reason that triggered this. Something like "%SPANTREE-SP-2-PVSTSIM_FAIL: Blocking root port : Inconsitent inferior PVST BPDU received on VLAN , claiming root ". Could you forward a copy of this message? That will tell us where to look for next.

Thanks and regards,

Francois

Great news!

I've finally got this working. I'm not sure what I was doing wrong before, but I setup the lab from scratch and I now get the expected results. Basically what you said in your earlier post is absolutely correct.

I've been playing around with the priorities and such to see what triggers inconsistency errors. It seems that the key for this to work is that the priority for vlan 1 on the PVST+ switch should be lower than that of IST0, and any other *common* vlans between the MST region and the PVST+ switch have a priority lower than vlan 1. ( On the PVST+ switch).

Here is a diagram of my lab setup with the assigned priorities.

http://64.151.112.212/topology.jpg

My question is why does the other vlans on the PVST+ switch have to be lower than vlan 1? Why does vlan 1 being the lowest priority on the PVST+ swich cause this to break.

Thanks Francois.

That's what I tried to explain in my first answer, but it's not very easy, sorry about that.

In a nutshell, you need to make sure that all vlans have a better root priority than instance 0. However, in the case instance 0 is not the root, it takes its root priority from vlan 1. So you need to make sure that all vlans have a better root priority than vlan 1.

Regards,

Francois

Francois Tallet
Level 7
Level 7

I will explain what the problem is likely to be. Hold on;-)

At the boundary PVST/MST, the MST switch uses a single instance to compute the state for all the vlans. It basically use the CIST, instance 0. On the PVST side, each vlan runs its own instance. The interaction works only if the state and role computed for instance 0 on the MST side is consistent with the state and role of all the PVST+ instances on the other side.

In your case, the root is on the PVST+ side. It means that vlan 1 (the unique vlan that is interacting with instance 0) had a better information than the one the MST region can advertise for instance 0. As a result, suppose that the role for the MST port is "root". On the PVST side, for vlan 1 the role is designated. Now, instance 0 gets its information from the PVST region. So say that vlan 1 has a root priority of 0. With extended sysid, it means that the priority is in fact 1 (0 + vlan #). So instance 0 hears from a root bridge with priority 1 on the port going to the PVST side. So far so good (I hope;-)

The way PVST simulation works is that at the boundary, the information for instance 0 is replicated on all the vlan. So basically, for all the vlans, the MST switch is now going to advertise some information about a root bridge with priority 1!

Suppose the only other vlan in your setup is vlan 2. You configured vlan 2 with a root priority 0 on the PVST side also (in order to beat instance's 0 priority, as recommended). Because of extended sysid, the priority advertised by vlan 2 is 2 (0 + vlan ID again). But it receives information from the MST switch with priority 1...i.e. better information. Here is your inconsistency! To summarize:

- instance 0 receives better information on vlan 1: the port is a root port.

- instance 0 receives worse information on vlan 2: the port should be designated.

Because the MST port only has one role and state, it cannot be both root AND designated. The code triggers and inconsistency.

I don't know if you could follow, it's quite confusing. That's why I would recommend steering clear of this scenario. On the top of that, I might not have understood exactly your exact setup.

Just in case, make sure that in you PVST domain, the priority for vlan 1 is just a little bit worse than the priority for the other vlans. Say, configure a priority of 8k for vlan 1 and 4k for the other vlans. If it does not help, then my guess was wrong;-) There are other configuration issues that can lead to the same problem, so you'll have to give more information on the vlans configured on the PVST side, as well as the vlans allowed on the trunks.

Regards,

Francois

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: