2Gb Trunk: seeing 1Gb filled then trouble

[fcocquyt]

Hi,
we have a 1G + 1G = 2Gb trunk configured on our

Product: ProCurve Switch 2848 (J4904A)
Version: I.10.70, ROM I.08.07

We noticed (via cacti SNMP monitoring) when the first member fills close to the 1Gb we have big problems getting new sessions established on the trunk. eg our dev DB crashed trying to establish a connection.

Can someone explain how its supposed to work?
Our expectation is new TCP sessions should be allocated on the second channel of the trunk.
Is there a configuration to check on this ?

(we do see a small amount of traffic on the 2nd channel - is there a way to more evenly loadbalance the traffic on the channels of the trunk?)

thanks

[Marco Wessel]

If you're mostly pushing traffic between the same two hosts on this link, the behaviour you're seeing is due to the hashing performed to keep flows on the same connection. Not doing this would cause packet reordering which breaks a whole lot of things (though technically it shouldn't, but we all know how theory and practice often relate to eachother the same way bricks and kittens do.) Unfortunately, link aggregations are not very well equipped to handle traffic that mostly goes from A to B without much variance in A and B. The only way to truly get more bandwidth in that situation is upgrade to 10gigE or use multipathing.

[Kevin Richter_1]

There is a good description of outbound traffic distribution in chp 12 of the Management and Configuration Guide for the 2848 http://ftp.hp.com/pub/networking/software/Mgmt-Oct2005-59906023-Chap12.pdf (see section starting on page 12-26.)

As stated by the previous poster, out of order packet delivery is a bad thing. Therefore, nearly every layer 2 trunking algorithm takes pains to ensure this never happens. The 2848 distributes traffic based on Source and Destination MAC address pairings. As long as your traffic is between the same 2 hosts or any combination of hosts that ended up getting their traffic assigned to, say, link 0 in the trunk, then all traffic from those hosts would continue to pass on link 0. New host pairings could be assigned to the (idle) link 1 in the trunk, but the existing pairing will not move additional load to link 1 even when link 0 is "full."

All this works well for distributing traffic from multiple hosts on one switch to multiple hosts on another. Smaller tests with just a few hosts will not easily see good distribution of load.