06-08-2009 02:37 AM - edited 03-06-2019 06:08 AM
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?
Solved! Go to Solution.
06-08-2009 09:00 AM
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."
06-08-2009 09:00 AM
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."
06-08-2009 02:49 PM
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/
06-08-2009 03:46 PM
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.
06-08-2009 04:56 PM
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??
06-08-2009 05:04 PM
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
06-08-2009 08:01 PM
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
06-09-2009 09:07 AM
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
Thanks and regards,
Francois
06-09-2009 04:05 PM
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.
06-09-2009 04:12 PM
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
06-08-2009 09:29 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide