ok, I have done some more testing and here are my findings, maybe it helps some others. Further explanation / comments very welcome!
Link Aggregation requires some sort of identification of a flow to make sure the packets arrive in order as much as possible (to avoid unnecessary TCP overhead for packets not in order). The load balancing uses different parameters to build a "hash" of the ethernet frame. Same hash = same LAG physical cable.
Hash parameters to classify a flow can include:
- incoming physical port
- MAC address
- VLAN
- IP address
- TCP/UDP port number
- all but the first with source / destination / source+destination
Which looks very simple in the first place (select src+dst mac and done) then apparently turns out to be much more a question of the individual manufacturer implementation then anything else. You read on the internet that the load balancing part of LAG is not specified by IEEE 802.3ad..
Also a LAG with an end device (like a Synology NAS) reduces its MAC addresses to 1 (so the MAC address from the 2nd, 3rd [..] end device port is ignored at this stage - as long as its part of the LAG). So the ethernet frame with traffic from a LAG end device always has the same MAC address as src. See also the CLI output from the SG550XG about the LAG with the NAS (00:11:32 is Synology).
As the one side of the traffic is different (think: "2 clients accessing the same NAS") this should result in two different hashes but it seems to be not that simple.
I have added a screenshot from 3 different switches I had handy during the test. The (entry level) HPE 1820 seems to have the most options (and fully saturating a DS1815+ with it from 2 clients works just fine both ways since years), while the Cisco SMB series seem to be reduced (maybe what I need is avail. in the higher Catalyst series - but this is way out of budget).
The SG550XG-8F8T and the SG500X-24 both have the same behavior:
2 clients > NAS: 2 legs (2 different flows per src mac),
NAS > 2 clients: 1 leg (only 1 flow per src mac)
It does not matter if I use 2x 1G or 2x 10G for the link to the Synology.
When using 4 clients (and not Synology) I can fully utilize the LAG between switches - this would be expected behavior as src and dst mac are different for both flows.
client A iperf server > LAG 2 legs > client B iperf client (1 flow per src mac)
client C iperf server > LAG 2 legs > client D iperf client (another flow per src mac)
= both legs fully saturated.
So I guess what I need is "TCP ports" as an option for load balancing on the SG models to make 1 NAS able to deliver more than 1 flow.
I also have to correct my findings about the Dlink DXS. While I had fully saturated LAG 2x 10G working at some point I was not able to reproduce this. So for now its delivering the same results than the SG550XG-8F8T and the SG500X-24 (sending TO the NAS from 2 clients works utilizing both LAG links, receiving from the NAS [1 MAC address] with two clients utilizes only one LAG link.
I also had a play with the different options on the DXS and they seem to have nothing to do with the label.. :
- 2 clients > NAS: 2 legs, NAS > 2 clients: 1 leg (all the same)
„Source Mac“, „Source Destination Mac“, „Destination IP“
- massive reduced speed (switch CPU remains at ~20 % load so thats not the bottleneck)
"Destination Mac", „Source IP“
- Source Destination IP I don't remember but I would not improve things.
This concludes my testing about LAG, Synology and transfer speed.
I'm trying to get a Cisco representative to confirm my assumption about the SG series not supporting TCP port as load balancing hash argument.
