MSTP and PVST+ topologies

[gesadmin1]

I am driving myself mad trying to get MST to work with PVST+. I've got two ProCurve 2810-48Gs and a single Cisco 3550 set up in a triangle configuration. On the Cisco I've got VLAN1,10,24,and 27. On the HPs I've got VLAN1,24, and 27 configured. A single MST region with two MSTI's have been configured on the HPs (not counting the IST). On HP switch 1 MSTI1 is primary (priority 1 or 4096) and secondary on HP switch 2 (priority 2 or 8192). MSTI2 is primary on HP switch 2 and secondary on HP swtich 1. HP switch 1 is also the CIST root (spanning-tree priority 1 or 4096). When I look at the spanning-tree output on the 3550 I can see that it sees the HP as the root for VLAN1, but it sees itself as the root for VLAN24 and VLAN27. The HPs also see themselves as root for their respective MSTIs so I've got loops in both VLAN24 and VLAN27. I've searched high and low for some solid evidence as to why this is and I am back to square one. According to the Cisco documentation "As the MST region now replicates the IST BPDUs on every VLAN at the boundary, each PVST+ instance hears a BPDU from the IST root (this implies the root is located inside the MST region). It is recommended that the IST root have a higher priority than any other bridge in the network so that the IST root becomes the root for all of the different PVST+ instances" ( http://www.cisco.com/en/US/tech/tk389/tk621/technologies_white_paper09186a00800

94cfc.shtml#recommended_configuration). In reading this it should seem that proper blocking is happening in the correct spot, but it's not. I've looked at pretty much all of HPs documentation on this as well as Cisco's but I'm not finding a definitive answer. Any help in understanding would be great.

[Francois Tallet]

Forget about this document on MST because it describes the way Cisco MST switch interact with PVST:-(

You have in fact a classic case of interaction PVST+/standard STP (forget also about MST here). PVST+ has a single instance (the instance for vlan 1, as you discovered) that is sending its BPDUs to the IEEE address. It means that the HP only see vlan 1 as a peer, and that the Cisco device only sees the HPs on its vlan 1. The other vlans are sending PVST+ BPDUs, which are just flooded by the HP. So from the perpective of the other vlans, the HP look like a hub if you want. Your network is then a single 3550, with its ports looped back together.

Regards,

Francois

[gesadmin1]

Francois,

Thank you very much for responding to my inquiry. How should I proceed in this scenario?? Do I just run a single MSTI and place all of my VLANs in it?? Am I out of luck in terms of balancing the VLAN traffic across the two HP uplinks into the 3550?? If I want to make this work properly do I need to convert my entire network over to MST?? Thanks again for your help thus far.

[Francois Tallet · Accepted solution]

Hi!

You can still do some kind of load balancing with your 3550. The way I see your network, you must have a designated port and some backup ports on the vlans other than 1. By tuning the port priority on the 3550, you can select which of the uplink is going to block (higher priority means that the port is more likely to become backup).

Now, this interaction with third party bridges is really not efficient. Transitions will be according to legacy STP rules, and a failure between the HP switches for instance would require 50 seconds to recover on the 3550.

The best solution would indeed to run MST on the 3550. Now, I'm not a great product expert so I'm not sure if this platform can run 12.2. If not, you're probably going to be stuck with a pre-standard version of MST on the 3550. In that case, the 3550 won't be able to form a region with the HPs (meaning that you won't be able to do any vlan load balancing), but at least you will have fast convergence...

So basically:

=> if the 3550 runs what we call "standard MST", then run MST and everything will be fine (load balancing possible + fast convergence).

=> if this is not an option, you have two choices:

-1- keep a PVST+ model, with load balancing and slow convergence (the terrible interaction PVST+/IEEE standard is the reason why we developed a particular MST/PVST+ interaction mode)

-2- run pre-standard MST and get fast convergence without vlan load balancing.

Regards,

Francois

[gesadmin1]

Francois,

This is just an FYI, I was able to lab this up at home using PVST+ on the 3550 (it is running 12.2) and MST on the HP's. I configured it like in my original post and of course I got the same results. I then moved all of my VLANs (1,24,27) into MST0, or the IST in HP terms, and the uplink from HP switch 2 to the 3550 blocked, just like it should. Since the 3550 assumes it is the root of both VLAN24 and VLAN27 I am unable to manipulate the port priorites or costs to get the load balancing that I desire. It's not the end of the world though because now I can really understand what is happening under the hood with the PVST+/MST interaction. I have configured the 3550 to run MST and it works flawlessly with the HPs so we're good there. I'm just labbing it like this since this is what one of my production networks looks like, that is until I am able to upgrade the IOSs to 12.2 and turn on MST. Thanks again!!!

[Francois Tallet]

Hold on hold on, we'll get to the bottom of this;-)

The vlan to instance mapping is in fact irrelevant in your particular case because at the boundary of a region, all the vlans follow the IST.

What is confusing me is that you are saying that port of HP2 to the 3550 is blocking like it should. Should it? I don't think so (assuming that HP 1 is still the root). I think that you have introduced a mismatch in the MST configuration that puts HP1 and HP2 in different regions. I can explain what is happening now though. HP2 is blocking all the vlans, including vlan 24/27. As a result, there is no data traffic in those vlans through the pair of HPs: the 3550 does not see its PVST+ BPDUs back for vlan 24/27, and open both ports...

What you need to do:

Go back to your initial configuration where both HPs are in the same region. HP1 is the root. For vlan 1, the 3550 has a root port and an alternate port. For vlan 24/27 it has a designated port and a backup port (you succeeded in getting all the STP roles on your box, sweet!). If you want to move the position of the backup port to a different uplink, increase the port priority on this port, for this vlan.

For example: spanning-tree vlan 24 port-priority 240

If this does not work, it's going to drive me nuts too;-)

Regards,

Francois

[gesadmin1]

Francois,

It's very good of you to continue helping me out here. I thought that my MST config was 100%. I had the config-name set to global and the config-revision set to 1 on both switches. MSTI1 had VLAN24 on both switches and MSTI2 had VLAN27 on both switches. I will double check again when I get home this evening. I'd hate for you to go nuts like I have lol. Thanks again.

[gesadmin1]

Francois,

I was able to lab this scenario again when I got home this evening. I set up my config exactly like the last two and saw the blocking occuring at HP Switch 2 with only port g0/8 blocking on the 3550 in the VLAN1 STP instance. I sat back and thought for a second and, oh yeah, I didn't configure the uplinks on the HP side as tagged ports (trunks). Once I tagged both VLAN24 and VLAN27 STP reconverged and I saw what you described with the 3550 blocking on g0/8 on all three STP instances. I configured the port priority for g0/8 as 64 for VLAN27 and g0/4 as 64 for VLAN24. Voila, she's done. So the only reason that the 3550 is blocking (knowing that it is the root for both VLAN24 and VLAN27) is because it received it's own BPDU back and had no other alternative but to block the highest port?? Blocking at the root is not optimal but then again neither is running PVST+ and MST :-). After thinking about what I said in my previous post about it making sense that HP 2 was blocking, it actually doesn't make sense now...so the moral of the story is be sure to tag your ports lol otherwise you'll go nuts like we did.

[Francois Tallet]

Hi,

So when you said that the blocking was occurring at the level of the HP switches, you meant that traffic was not going through because the vlans were not allowed on the links right? From your previous post, I thought that MST was blocking the traffic (I thought you were seeing an alternate port).

The allowed vlan list on a port(i.e. whether the port is trunk, trunk with only a subset of the vlans allowed or access) should not have any impact on MST, if the HPs are strictly following the IEEE standard. So if MST does not block a port on the HPs when the links are trunking, it should not block either when they are access.

Anyway, the fact that the traffic was not flowing through the HPs for vlan 24/27 (regardless of the reason) explains why the 3550 was opening both its ports.

Blocking a port on the root bridge is not less optimal than anything else. Here, the problem is that your PVST+ BPDUs are bridged across the HPs. In particular, a link failure between the HPs will only be detected by the 3550 by the lack of reception of its own BPDUs. And also in that case, because the 3550 does not have a peer running Rapid-PVST, it can only unblock its port based on the slow STP transition through listening/learning stages. So the convergence will be slow (6 seconds to age out the information + 30 seconds for the listening/learning stages). Worse, if the link between the HP heals, you could have a temporary bridging loop until the 3550 sees its hellos going through (that should last hello time max) and block an uplink.

Regards,

Francois

[gesadmin1]

You said:

"So when you said that the blocking was occurring at the level of the HP switches, you meant that traffic was not going through because the vlans were not allowed on the links right? From your previous post, I thought that MST was blocking the traffic (I thought you were seeing an alternate port)."

Response:

Actually, when I did a sh spanning-tree on HP Switch 2 I saw the port state as blocked.

You said:

"The allowed vlan list on a port(i.e. whether the port is trunk, trunk with only a subset of the vlans allowed or access) should not have any impact on MST, if the HPs are strictly following the IEEE standard"

Response:

Here's why it makes sense to me (and thus why it's probably wrong lol) is because without the interface set as a tagged/trunked port, only the native VLAN can get through (in this case the native VLAN is 1). When PVST+ sends BPDU's the only one that comes through untagged is for the native VLAN. All other BPDU's are actually tagged with a VLAN ID. Please reassure me that I've got the concept correct so far?? Further, if I don't allow those VLANs across either by excluding them from the tagged/trunked port or just by having the port set as an access/edge port then those BPDU's will not be able to traverse the link.

You said:

"In particular, a link failure between the HPs will only be detected by the 3550 by the lack of reception of its own BPDUs."

Response:

That is exactly my perception of the scenario also.

Thanks again Francois!!!

[Francois Tallet]

Here's why it makes sense to me (and thus why it's probably wrong lol) is because without the interface set as a tagged/trunked port, only the native VLAN can get through (in this case the native VLAN is 1). When PVST+ sends BPDU's the only one that comes through untagged is for the native VLAN. All other BPDU's are actually tagged with a VLAN ID. Please reassure me that I've got the concept correct so far?? Further, if I don't allow those VLANs across either by excluding them from the tagged/trunked port or just by having the port set as an access/edge port then those BPDU's will not be able to traverse the link.

--> that explains why the 3550 was opening its ports. It does not explain how the HP could block a port. Do you remember the role of this blocked port btw?

HP2 could only elect an alternate port if it had a root port (I'm assuming that you have described to me all the cabling of course;-). So basically, its root port was to HP1 (which is the root), and alternate port to the 3550. Without entering into the detail of MST, both HP bridges look like a single CIST bridge if they are in the same region. That means that this virtual bridge (comprising the two HP) was blocking one port. This is only possible if:

- the 3550 was the root for vlan 1

- the 3550 had spanning tree disabled for vlan 1.

That's why I assumed you introduced a mismatch in the MST config.

Anyway, I don't think this issue is worth the time we are investing in it;-)

Regards,

Francois

[gesadmin1]

Francois,

Please understand how appreciative I am that you are spending your time with me and helping me understand this better. You are 100% correct (surprised?? lol). I labbed this up again when I got home this evening and I saw what is supposed to happen. Before when I said that the HP was blocking it was because when I looked at the spanning-tree output I hadn't waited long enough for it converge. Once I was patient enough I saw the 3550 block on port g0/8 for all three VLANs. This was when I had the uplinks configured as trunks and when I had them configured only as access ports. Can you clarify one thing for me?? My interpretation of what happens when BPDU's are propagated from each VLAN is flawed. So what actually happens is all BPDU's are sent on the native VLAN with a VLAN flag inside specifying which VLAN they came from. This is how they propagate regardless of the port configuration (i.e. trunk or access). Am I correct on this?? I think we can put this one to sleep. Thank you again for your help.

[Mohamed Sobair]

Hi,

I would like to welcom Francois here, Its been very long time since we looked at ur posts.

Mohamed

[Mohamed Sobair]

Hi Francois,

I have a question, when MST region and instances are configured, Vlan 1 is assigned to MST0. Is that correct? Why then both switches claiming to be the root for Vlan1?? there should be a single root Switch for this instance IF they were in the same region. Am I correct?

Mohamed

[Francois Tallet]

Thanks Mohamed!

Instance 0 (the CIST) is the only instance that live across different regions, so there is a unique root network wide for instance 0. And yes, vlan 1 is the CIST in PVST+. So instance 0 and vlan 1 will have the same root.

I think that's the way it has been described, the HP and cisco bridges don't claim they have different root for instance 0.

Regards,

Francois