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.

[gesadmin1]

Francois,

You have been so extremely helpful!!! I will take what you say into account.

[Mohamed Sobair]

Hi francois,

what about vlan 24,27 ? I couldnt get your point that from the prespective of the 3550 the HPs are likely to be a hub?

Mohamed

[Francois Tallet]

vlan 24 and 27 send their BPDU to the SSTP address, a Cisco proprietary mac address that is not recognized by the HP as reserved addresses. As a result, the HP are flooding those BPDUs just like user data. The 3550 gets back its own BPDUs for those vlans. That's why the 3550 is the root for vlan 24 and 27: it is the only peer running STP for those vlans.

For vlan 1, on the other hand, everything is different because its BPDUs are sent to the IEEE address. The HP switch receive those BPDUs and interpret them as RSTP BPDUs. An RSTP BPDU is treated like an MST BPDU from a different region in MST, so they are injected in instance 0. Well, in fact, considering the topology of the network, it's rather the HP that are sending BPDUs to the 3550, and the 3550 is blocking one of its uplink.

HTH,

Francois

[Mohamed Sobair]

Hi Francois,

Your answers are very helpful, but I would like to add 2 more questions?

why is this happening? why the 3550 sends vlan1 BPDUs to the IEEE address while sendind vlans 24,27 to thw Cisco propritary address?

I mean In some situation, there will definetely be Integration between Cisco and non Cisco Switches? what is the best recommended approach if the design requires Standard Spanning-tree protocol?

HTH

Mohamed

[Francois Tallet]

Hi Mohamed,

This is the way that the interaction between STP/PVST+ was designed 10 years ago. Honestly, it's not perfect but there is no clean solution anyway.

The problem is that on one side you have a standard spanning tree protocol that runs on physical links: the IEEE standard, whether this is for STP, RSTP or MST only sends a single BPDU for the whole link. On the other side you have a protocol that is sending one BPDU per vlan, considering each vlan has different virtual bridges (one control protocol per vlan).

How can you have one instance of STP (IEEE standard) talking to 4K instances of STP (Cisco's PVST+)? The current solution is that you dont;-) Vlan 1 was chosen as *THE* vlan which would interact with the IEEE unique STP (at that time, vlan 1 was a special vlan that you could not remove from trunks and that is still always allowed in the VTP database). That's what we're still living with today!

Regards,

Francois

[mturczan]

Francois,

PVST+/RPVST+ only interacts with IEEE STP over VLAN1, regardless if the native VLAN on the trunk is something other than VLAN1?

Regards,

Mark

[Gang Ma]

Case2 part of this following post describes the situation when Cisco is trunking to non-Cisco switch with native VLAN other than VLAN1.

http://blog.ine.com/2008/07/17/pvst-explained/