Dave Tucker recently wrote up a three-part series entitled “HP ProCurve/Cisco Interoperability”. His series reminded me of something I wanted to mention here regarding the way the ProCurves calculate spanning-tree costs when dealing with aggregated links (e.g. LACP).
There’s no better way to illustrate my point than by labbing it up, so I grabbed some patch cords and began cabling up a Cisco 3550 and HP 5412zl in the lab.
There are a total of five 100 Mbps connections between the two switches. Here’s how they are connected:
- Fa0/32 to B1
- Fa0/42 to B9
- Fa0/44 to B11
- Fa0/46 to B13
- Fa0/48 to B15
I’m going to skip pasting a lot of the configuration because that’s not really what I want to show. Instead, I want to show the difference in behavior.
As you can see from the diagram above, the Fa0/32-B1 connection is just a standard 100 Mbps interconnection between the two switches. The other four interconnections, however, are bundled up in an LACP link, for a total throughput of 400 Mbps. I’ve configured MST on both switches (no instances manually created), setting the priority to ensure that the 3550 is the root. The root, of course, will not have any blocked ports, and it will be up to the 5412zl to block the redundant path to the root bridge, right?
Let’s take a look at the spanning-tree cost that the 3550 has assigned to the 100 Mbps connection to the 5412zl over Fa0/32.
CAT3550# show spanning-tree interface fastEthernet 0/32 cost MST0 200000
That makes sense. 200,000 is the standard cost for a 100 Mbps link. What about the 4×100 Mbps port-channel I created?
CAT3550# show spanning-tree interface port-channel 1 cost MST0 50000
50,000. Again, just what I would have expected.
Now, let’s jump over to the ProCurve and see what’s happening.
HP5412# show spanning-tree instance ist | include Root Port Regional Root Port : B1
Wait, what? How could that be? Why would the switch choose the 100 Mbps path to the root bridge instead of the 400 Mbps path? Let’s take a look at the path costs that the ProCurve assigned to our connections.
HP5412# show spanning-tree b1 | begin Designated | Prio | Designated Hello Port Type | Cost rity State | Bridge Time PtP Edge ----- --------- + --------- ---- ---------- + ------------- ---- --- ---- B1 100/1000T | 200000 128 Forwarding | 000b46-6a9700 2 Yes No HP5412# show spanning-tree trk1 | begin Designated | Prio | Designated Hello Port Type | Cost rity State | Bridge Time PtP Edge ----- --------- + --------- ---- ---------- + ------------- ---- --- ---- Trk1 | 200000 64 Blocking | 000b46-6a9700 2 Yes No
Notice that, unlike the Cisco switch, the ProCurve switch did not automatically adjust the spanning-tree cost on our aggregated (LACP) link. This results in the single 100 Mbps link and the 400 Mbps LACP link having the same costs to the root bridge. Notice also that port B1 is forwarding, while Trk1 (the LACP link) is blocking. Thus, traffic from the ProCurve switch to the root bridge will take the slower 100 Mbps link instead of the much faster LACP link.
As Dave mentioned (referring to other default settings on the ProCurves), “The jury is out as to whether this is a good thing or not.” The ProCurve engineers, presumably, had a good reason for choosing not to automatically adjust the spanning-tree costs, but I’m not sure what it was. This is just something to keep in mind if you work in a mixed Cisco/HP environment, as the default behavior is definitely not what one would expect!