Wireless Networks Thread, Port trunking on HP Switches not helping transfer speeds in Technical; I've got plans to trunk the connection between our core switch and a gigabit switch used for our servers across ...
6th August 2010, 01:40 PM #1
- Rep Power
Port trunking on HP Switches not helping transfer speeds
I've got plans to trunk the connection between our core switch and a gigabit switch used for our servers across 4 cables, but I thought I'd try it first on a couple of spare HP 2650 switches (48 port 10/100 with 2 gbit ports)
I have been into the management console on both switches, set 2 ports on both to be part of trk1 and configured them for LACP. I plug the network cables in and it works - but it seems to make no difference between the file transfer speed whether I have 1 or 2 cables plugged in between the two switches!
Here's my setup:
Computer(gigabit) <-> Gigabit port on switch <-> 2x 100MB trunk <-> Gigabit port on switch <-> Computer(gigabit)
Or in terms of just the connections:
Gigabit - 2x 100MB - Gigabit
I've tried a few different speed test programs, and also tried upgrading the switch firmware to the latest. If I connect the laptops directly via gigabit over the 2 switches I do see a marked improvement in the transfer rate, but with the trunk is identical to without.
My question is - is there some setting I've missed, or would I even notice the difference in single server to single client connections?
IDG Tech News
6th August 2010, 01:55 PM #2
You won't notice a difference on a single transfer. Think of it a little like a motorway. The speed limit for each individual car is still 70mph, but by adding extra lanes (cables) you can get more cars on at the same time
Thanks to Soulfish from:
chriscubed (6th August 2010)
6th August 2010, 01:58 PM #3
If you wish to batter your network and test the speeds its capable of there are tools to do this.
Iperf | Download Iperf software for free at SourceForge.net
6th August 2010, 02:52 PM #4
- Rep Power
I see - so trunking wouldn't mean that the signal from one source is distributed amongst the different cables in your trunk, rather if you had two sources then they would effectively have their own cable each, meaning there's more available bandwidth for each one? Simplified example I know, just trying to understand the principle first
Thanks for your help
6th August 2010, 03:50 PM #5
Correct. It means you can have 20 computers pulling 100MB each, rather than just 10 computers. (Yes, technically you can't due to overheads and manufacturing tolerances, but it makes the point).
Also remember that sender + recipient devices send and expect to receive packets in a specific order. If a transfer was done using two links, you'd run into problems with packets arriving out of order (or incur an overhead for rearranging them).
Last edited by pete; 6th August 2010 at 04:51 PM.
Reason: typo conflating MB with computers
Thanks to pete from:
chriscubed (22nd September 2010)
6th August 2010, 04:00 PM #6
- Rep Power
Just done another test, similar to before but added in an extra computer at each end of the switches to run another test in parallel. A single test runs at approx 12MB/s, but run two tests at once and the bandwidth drops to 5.5MB/s, which is roughly half, if not worse!
To me, this confirms my suspicions that the trunking isn't providing the extra bandwidth it should. Does anyone have an idea of what I could to do troubleshoot this?
Just to recap, I have only changed the trunking settings from the defaults on these switches, no VLANs or other config. Is there anything I might have missed?
7th August 2010, 05:32 PM #7
There is another type of trunk that you can create (rather than LACP). I'd suggest trying that.
8th August 2010, 10:21 AM #8
The way that trunking works is that a frame arrives at a switch and a lookup is done to see which interface it needs to be sent out of. When the outgoing interface is a trunk then further processing needs to be done before the frame can be queued for transmission, this processing is to decide which port of the trunk the frame should be used to transmit the frame and the hashing algorithm used varies between manufacturers and switch models. The HP switches you're using only do a basic layer 2 hash, they take the SA and DA (source MAC address and destination MAC address) and perform a calculation on them that will output one of x values where x is the number of member ports in the trunk (in this case it will result in 1 of 2 values as there's 2 ports making up the trunk). This result then decides what outgoing port to transmit the frame on. This means that for any SA/DA pair the same transmit port will always be used (unless the make up of the trunk alters through a config change or hardware failure), what's happening in your case is that there's 2 SA/DA pairs and they both hash to the same value so both use the same outgoing port. Once you start introducing more devices to the network you'll find that SA/DA pairs hash to either value and you'll start seeing some load balancing. Trunking is more effective when you have more devices on the network, the basic layer 2 hash that HP use means it's next to pointless for networks with very small numbers of endpoints.
On better switches you usually get a choice of algorithms to use and they're not restricted to layer 2, you can choose algorithms that take IP and TCP/UDP ports in to account as well which then means individual streams can be better load balanced. I'm not aware of any HP switches from the E range (Procurve stuff) that support anything other than layer 2 SA/DA though., not looked at the new A range stuff (H3C/3Com) enough to know either way.
Even with these higher layer hash algorithm the max size of each individual stream will still be restricted to the size of the ports making up the trunk (100Mbit in your case) as each stream always hashes to the same value. Foundry/Brocade do offer a round robin algorithm on their MLX/XMR platforms which would in theory allow you to split a stream across multiple ports and thus get a transfer rate higher than the speed of a single member port however it's usually a good idea to try and keep frames in the correct order as there's no order correction at the MAC layer and various issues could occur.
Thanks to funkymunky from:
chriscubed (9th August 2010)
9th August 2010, 12:21 PM #9
- Rep Power
Ric_: I had already tried the other type available which was non-protocol as I understand it.
funkymunky: That's an amazing reply! You have given me a better understanding of what the technology is about and helped me solve the problem.
I ran a new test where each client contacted both servers for 5gb of data, meaning 4 tests - and instead of 2 tests getting 5.5 MBps, I had 4 tests each getting 5.5MBps. To confirm, I ran a test with 1 client and 2 servers, and had 2 connections of 11MBps. Essentially my tests were misleading me as I didn't understand the hashing process.
It seems that this basic L2 hash is far from ideal for low numbers of connections as you say - but this was really just a test for the main project, swapping 4 virtual servers from individual gigabit connections to a 24 port gigabit switch, trunked through the 4 original gigabit connections and other servers utilising gigabit connections also:
It was setup like this:
Main switch -gigabit- Server 1
Main switch -gigabit- Server 2
Main switch -gigabit- Server 3
Main switch -gigabit- Server 4
Main switch -6x 100M- 6x Other servers
But now it is more like this:
Main switch -4x gigabit trunk- Server switch -individual gigabit connections- all our servers
All the trunk connections seem to be getting fairly even use, obviously with the number of servers and large number of clients the poor L2 hashing algorithm is less of an issue.
Again, thank you all for your help, I'm already pleased with the results!
9th August 2010, 04:07 PM #10
Glad it helped
By ICTNUT in forum Wireless Networks
Last Post: 5th January 2011, 03:00 PM
By Sunderwood in forum Classified Adverts
Last Post: 31st March 2010, 11:00 PM
By DSapseid in forum Wireless Networks
Last Post: 25th September 2009, 03:35 PM
By Gibbo in forum Wireless Networks
Last Post: 3rd June 2008, 10:39 AM
By douglash in forum Wireless Networks
Last Post: 25th February 2008, 11:20 AM
Users Browsing this Thread
There are currently 1 users browsing this thread. (0 members and 1 guests)