Spanning Tree issues HP Procurve 2810

[Giovanni Trapasso_1]

Hello,

I have 7 HP 2810-24 model switches which have just been installed in our new datacenter. Here is the setup:

- One 2810-24 which connected to the internet, which uses 2 fibre transceivers, ports 23 and 24 (not trunked), to connect to our datacenter.


Datacenter

- In our distribution rack two 2810-24 switches, each has a fibre transceiver connection to our internet switch. From these two switches feeding two separate rows of servers.

- In server row one, two 2810-24 switches

- In Server row two, two 2810-24 switches

- For all the different racks and server rows, I named the switches based on info, but they all end with either 00 or 01. The 00 switch in my distribution rack is connected to the other 00 switches, in both server rows, by 2 Ethernet ports that have been trunked together. Also The 01 switch in my distribution rack is connected to the other 01 switches, in both server rows, by 2 Ethernet ports that have been trunked together. In case of failures I have Spanning Tree enabled on all the switches and I have a single Ethernet backup links from the distribution switch 00 to all the 01 switches in the server rows, and the same from the distribution switch 01 to the 00 switches in the server rows. Hope this makes sense, crude picture below, the "t" represents the trunked lines, also there is another layer of switches lets call them 2-00, and 2-01 wired to the 00 and 01 switches the same way, but you should get an idea of the setup, . We also have 3 VLANs configured on the trunk links


-------- --------
ttt| 00 |-- --| 01 |ttt
t -------- | | -------- t
t | | t
-------- |------|----- --------
| 1-00 |--| ------------| 1-01 |
-------- --------


- The Spanning Tree root is the switch that connects to the internet, outside the datacenter.


Here is the problem:

- Spanning tree works great, we have an alternate route no matter which switch or connection goes dead. The intention is that the trunk links from the distribution switches to the various other server row switches were to be forwarding, and the backup links to be in blocked status. When a failure occurs the backup link would go into forwarding mode.

- Here is what actually is happening. All links from the distribution switch 00, both the trunk and the backup links are in forwarding mode, and all links from the distribution switch 01, both trunks and backup links, are in blocked mode. This is using the default values of Spanning Tree. (everything is working, but now how I wanted it)

- to get the trunk links from the distribution switch 01 to the other 01 switches to forwarding, and to force the backup links from distribution switch 00 to blocked, I changed the path cost on the backup links so that the trunk links would be the better choice. Things seem to work all trunks are in forwarding mode. The problem is that spanning tree would constantly recalculate and we would loose connectivity to the 01 switches in the server racks, at least pinging and monitoring would be affected, layer 2 switching didn't seem affected.


What I would like:

- how would I get all the trunk links up to forwarding status and the backup links to blocking without all the spanning tree issues?

[Giovanni Trapasso_1]

sorry about the diagram, you will have to make do with the explaination.

[Mohieddin Kharnoub]

Hi

Just draw a picture illustrates your topology with links speeds for better understanding.

Spanning tree won't recalculate unless you have a topology changes in the network, but why the changes happen?

clear drawing = better understanding :)

Good Luck !!!

[Giovanni Trapasso_1]

here is a url:

http://www.ualberta.ca/~trapasso/problem.txt

[André Beck]

Giovanni,

you write

> The Spanning Tree root is the switch that
> connects to the internet, outside the
> datacenter.

but this isn't reflected in your picture. It's the most crucial part to understand the Spanning Tree topology, though.

I assume you have trunks from each distribution switch to the root? If that is the actual topology, both distribution switches should be equidistant to the root and the blockings should be pushed further down, with your trunks towards the access switches becoming designated. ProCurve doesn't automatically adapt the path cost on trunks, though - they just tune the priority. This makes the path decision non-transitive, any switch should still prefer a trunk over a single link locally with the adjacent switch following, but it won't change the topology further down like a shorter path would. This idea can be argued either ways, it increases overall tree stability, but it is less aggressively optimizing for trunk paths and falls over with the slightest asymmetries. I still wouldn't expect the picture you're seeing here, though, unless there is some further asymmetry towards the root. That would instantly break the priority-only trunk tuning.

HTH,
Andre.

[Giovanni Trapasso_1]

I haven't replied, because I am working on the issue, and I think I solved it. Anyways, yes I don't have my root server there, it is connected to my top two switches via 2 fibre, one going to each switch, fibre because of distance.

What I did was change the cost on the trunks to 10000, read this in a doc about interoperability between HP and cisco. Tried this before but was having issues.

attached is a better image of things working. the red lines are the trunks.

[Giovanni Trapasso_1]

FOund the issue and the solution.

First off I had a flaky patch cable, causing links to go up and down, causing some stp instability.

also from a document called "HP ProCurve and Cisco Catalyst Interoperability" there was a note which stated HP does not recalculate trunked links where cisco does. so using the info in the document I reconfigured all my trunked Gig links to a path-cost of 10000 to match what Cisco does. After that my STP is stable, my trunks are primary.

thanks for all the replies.