HP Procurve 1800 Switch-to-Switch Trunks and LACP (and VLANs too!)

Question

I am considering connecting two (and possibly three) HP Procurve 1800 switches together with trunks or with LACP. I can't find any substantial answer to my questions via Google or here.

I did find this question Server-to-Switch Trunking in Procurve switch, what does this mean? but the answer to the question seems to be: a) Trunking could mean anything; and b) LACP is defined. The question Is a Trunk or LACP preferred? is not answered - and it is not switch-to-switch but switch-to-server.

I also found this question LAN Design Question with HP Procurve but it also does not answer the question posed above: Is a Trunk or LACP preferred? In any case, this question is relevant to the HP Procurve 2510 and not the HP 1800.

Neither of these questions seem to discuss our exact situation. There are three switches (all HP 1800s):

SW1(VLAN1) <-> SW2(VLAN1) <-> SW3(VLAN1)
               SW2(VLAN6) <-> SW3(VLAN6)

The switches are all HP 1800-24G (Hardware Version R01) with the following Software Versions:

• SW1: PB.03.01
• SW2: PB.03.01
• SW3: PB.03.04

The links between switches SW2 and SW3 all allow Tagged Packets only and have no PVID (according to the help documentation's recommendations). Other ports are either VLAN 1 or VLAN 6, and allow All Packets. All ports are autonegotiate except the occasional 100Mb Full Duplex settings; others are all 1Gb - none are 10Mb.

The problem is that SW2 seems to not respond to pings quickly and often loses packets (as monitored from the monitoring host on SW3). Other switches are fine and respond appropriately. Connection between hosts seem okay. HTTP response from both SW1 and SW2 on their management interfaces seem slow - slower than SW3.

I suspect a traffic bottleneck and would like to create a bigger pipe. The pings are to the IP address of the switch, and connections to the HTTP port also show slow response times. Presumably, the connections (HTTP and ICMP) are on VLAN1 as that is where the IP would be - and VLAN1 is the management VLAN anyway.

From reading other questions, it sounds like a "trunk" would make it possible to combine the traffic for both VLANs on the same wire - reducing the two connections down to one, or make the traffic go across multiple wires for multiple VLANs. It also sounds like trunks can be combined with LACP, but is that desirable?

My questions:

1. Is a trunk or LACP preferred in this situation? Why?
2. What does HP call a "trunk" in this situation?
3. How should the VLANs be handled in this situation?
4. Am I trying to solve the wrong problem?
5. Would a firmware upgrade help?

I'd like an answer to all questions in any case.

UPDATE I forgot to mention that I found this web page which seemed helpful, but also did not answer my questions directly. It sounds like (from the answers there) that trunking is for switch-to-switch communication and LACP is for server-to-switch communication.

Answer 1

LACP is the Link Aggregation Control Protocol. It is all about setting up link aggregation automatically and dynamically whenever more than one link is available and the other side speaks LACP as well. It typically is used with redundant server-switch interconnection since a static setup with link aggregation would break server connectivity as long as the NIC drivers (where link aggregation is implemented) have not been loaded, thus effectively breaking pre-boot server management or network boot capabilities.

For switch interconnects, usually a static setup is preferred - although I would consider it purely a matter of taste.

"Link aggregation" and "trunking" are usually used as synonyms. There is a defined IEEE standard for LA (802.3ad) and many proprietary vendor extensions have arisen before standardization, most of which have implementations even in newer switch models for backward compatibility reasons.

If you set up a link aggregation or trunk group (LAG/TG), you should define the same VLANs as members of the group for switches on both sides. You only should define more than one path (i.e. more than one LAG interconnection) between two switches if you a) know exactly what you are doing and b) have enabled STP on both connected switches.

If you just suspect a bandwidth bottleneck, use the port statistics counters of your switches to verify it - quite possible that the bandwidth usage will turn out fine and your problem is an entirely different one. Mostly, switches do have rather slow CPUs and fast ASICs able to do most of the processing without any burden on the CPU. Some operations still would eat CPU cycles, one that is quite "popular" is the reception of broadcasts or multicast packets. If your network is generating a lot of broadcast/multicast traffic, processing and discarding the packets itself might saturate the CPU of a switch beyond reason. Again, check the counters to see if an excessive number of broadcasts is seen on the net.

Answer 2

In the HP ProVision Operating System; the term trunk means differently to the Cisco term of Trunk

• Non-802.1Q interfaces (such as computers or printers) is known as UNTAGGED with ProVision, and in Cisco as an ACCESS port.
• 802.1Q interfaces (such as switch-to-switch, switch-to-server, and switch-to-VoIP phones) is known as a TAGGED port with ProVision, and Cisco is an TRUNK port.
• Aggregated Interfaces are known as a TRUNK port with ProVision, but ETHERCHANNEL with Cisco.