Hello @Valerio Giorgi
First the more obvious question. Why is there no difference in bandwidth between a file transfer via single port and 3 port link aggregation?
A link aggregation is doing load balancing of the traffic based on conversations or flows. A conversation or flow consists of all the packets having the same packet attributes, for example same source and/or destination MAC, IP address, port number etc. So the switch groups all the packets with the same attribute in flows and performs the load balancing on the basis of the flow. All the packets of the same flow are always forwarded over the same single physical port of the trunk. Different flows are basically forwarded via different ports and there is hashing algorithm which determines which flow will be forwarded over which link.
You can find information on the trunk load balancing in the manual page 98.
https://support.hpe.com/hpesc/public/docDisplay?docLocale=en_US&docId=a00003478en_us
Load Balance
The hashing algorithm used to distribute traffic load among the physical ports of the trunk while preserving the per-flow packet order. The hashing algorithm uses various packet attributes to determine the outgoing physical port.The following sets of packet attributes can be used to compute the hashing algorithm:·
Source MAC, VLAN, EtherType, Incoming Port
·Destination MAC, VLAN, EtherType, Incoming Port
·Source/Destination MAC, VLAN, EtherType, Incoming Port. This is the default selection.
·Source IP and Source TCP/UDP Port Fields
·Destination IP and Destination TCP/UDP Port Fields ·Source/Destination IP and TCP/UDP Port Field
The default selection is based on source and destination MAC VLAN, Ethertype and incoming port. We can imagine that all the packets of a file transfer between 2 PCs have the same packet attributes which means they are in the same flow and consequently they were forwarded over the same physical link. That’s why there is no difference between using a single port and a trunk. A single flow will always be forwarded over the same single physical link.
The link aggregation doesn’t increase the bandwidth of single conversation between hosts. It can only increase the aggregated bandwidth between the switches and this can only be achieved if the switch has to forward packets of multiple flows.
So the link aggregation provides redundancy and load balancing but not necessarily increased bandwidth. Bandwidth is increased at the level of the inter switch communication. Not at the level of the host to host communication.
Keep in mind also that the speed of such a file transfer is limited by the bandwidth of the PC NICs. If both PCs have 1Gbps NICs how can you expect that the transfer can be done with 3Gbps? The receiving PC wouldnt be able to accept traffic at this rate because the NIC can only accept 1Gbps.
Regarding the transfer speeds in general. Copying files between PCs is not the most accurate way to measure network bandwidth because it can depend on file system type, read/write speed of the storage medium, PC utilization etc.
You can use a bandwidth measurement tool like iPerf for more accurate measurement.
Good morning,
Here my comments
Thanks a lot for your complete answer. So, according to you, how can I use Iperf software for correctly tests LACP improvement between two same 1920S switches??
I mentioned iPerf just as an example. It is not an HPE tool, there are multiple tools with similar functionality out there. You can find multiple resources on the internet.
If you test between two PCs on both switches there will be no improvement by using LACP compared to using a single port. Even if you use for example a hashing algorithm which considers source or destination TCP/UDP port and you are sending separate streams with different source or destination port, which are forwarded over different ports, the bandwidth will be restricted by the NICs of the PCs. If the NICs have max speed 1000Mbps then the throughput cannot be higher than this, no matter if you are using a single port or a 3 port trunk.
iPerf or similar tool should provide a more accurate result compared to the result you get when copying a file. When a file is copied there is additional delay caused by factors outside of the network.
The bandwidth improvement provided by a LACP link aggregation can only be achieved when there are multiple traffic flows between multiple hosts on both sides of the trunk. The more flows you have the even the load balancing would be.
I am not sure if iPerf offers testing scenario for link-aggregation. There are options for sending different streams or using different clients but I cannot go in detail about a 3rd party product.
You should keep in mind that the LACP hashing algorithms can provide random results. If you perform a test between 3 pairs of PCs for example, you shouldn’t take it for granted that the session of the 3 pairs will be assigned to a different link. It is quite possible that the hashing algorithm assign 2 or 3 session to the same physical link. Even distribution and utilization of the links is achieved only if you have a large number of flows which is normally achieved during productive operation.
And what is the best LACP configuration for best performance connections can you suggest me??
The selection of the hashing algorithm should have the goal to create as many as possible distinguishable flows. That’s why you need to analyze the traffic that should be going through the trunk and the packet attributes.
If you determine for example that large amount of the traffic has the same source and destination MAC addres, same VLAN, ethertype and incoming port, then the default hashing algorithm is not the best choise because all the traffic will be assigned to the same physical link.
If you have conversations from multiple hosts to a single server, then you can use the option Source MAC, VLAN, EtherType, Incoming Port for switched traffic and Source IP and Source TCP/UDP Port Fields for routed traffic (because the routed traffic has the MAC of the router)
If the majority of the traffic is from a single server to multiple clients, use the options with destination MAC or IP.
The principle is the select a hashing algorithm using packet attributes which are varying as much as possible.
Someone suggest me that is better to disable Spanning Tree , when i need to connect same switches together, is it correct??
When you interconnect 2 switches using a link-aggregation (trunk) then you have achieved one of the main goals of STP. You have redundant links between the switches and if one port fails the connection is still available. I think this may have been the idea behind the suggestion. You don’t need the link redundancy of STP because LACP also offers this redundancy.
But STP has also another function, it is also used to prevent local loops on the rest of the ports. It will recognize and block a loop if someone connects a cable directly between 2 ports. Or creates a loop connecting an unmanaged switch with 2 redundant connections etc.
To prevent such loops STP should be left enabled. Or if you want to disable it you should enable Loop Protection as described on page 62.
https://support.hpe.com/hpesc/public/docDisplay?docLocale=en_US&docId=a00003478en_us
I don’t know what exactly was is meant with “connecting same switches”. Even when the switches are of the same model they still interoperate using the standard STP or LACP protocol the same way they would interoperate with switches of another model or vendor supporting this protocols.
The only thing I can think of is that some switches of the same model can be configured as a stack. The stacking links between the stack members don’t need STP. But STP or loop-protect is still needed for the client ports. However 1920s doesn’t support stacking.
Hello,
I will answer the last question for the moment.
4) STATIC or DYNAMIC Trunk: now I use Dynamic , but what is the difference, and what is the best configurations in showed infrastructure??
Dynamic means that the LACP protocol is used. The LACP protocol provides verification that the member ports are connected to the same switch on the other side and trunking is also enabled for this ports. Both switches exchange LACP protocol data in order to negotiate and verify the trunk. If the LACP exchange fails it is assumed that the ports are not cabled correctly or configuration is not matching and the ports are blocked.
Static trunk means that no protocol packets are exchanged between the switches. After configuring the static mode the local switch assumes that the member ports are connected correctly to ports of the same switch on the other side and starts forwarding traffic. The remote switch does the same. This mode cannot prevent incorrect connection of the port so when it is used the admin should make sure that the cabling is correct.
The modes should be the same on both sides. If one side is dynamic and the other static, the dynamic trunk will be blocked. The load balance hashing algorithms apply to both modes
I need a bit more time for the rest of the questions, probably next week. I think we may need to consider other things as well. But of course if other members have suggestions they are welcome.
Hello,
I forgot to mention that the switch can apply the load balancing only to outgoing traffic. So that means it is important to know where typical destination devices like servers or routers and where the clients are relative to both trunked switches. For example if the clients are connected to the local switch and the servers to the remote switch (behind the trunk) a source address based algorithm is more appropriate. If the servers are connected to the local switch and the clients to the remote destination based algorithm is more appropriate. Here some considerations:
1) First example: in a infrastructure that use VLAN , but Server and Client are in the same subnet, where there are three main important Server ( DC, one using SQL DB and another ERP with SUSE Linux) , and about 50 clients that connects to this servers by this LACP fiber cable connections, what is your best LACP configurations??
If the traffic going out the trunk is from client to servers you can use all except Destination MAC and Destination IP. I would also exclude Source MAC VLAN, ether type, incoming port because it will map every client to a single port. Use either source IP, source port or source/destination IP, tcp/udp port because it will distribute the client traffic more evenly because different tcp/udp sessions will map to different physical ports.
If the outgoing traffic is from servers to clients, you can use all except Source MAC and source IP. Again I would also exclude Destination MAC and use dest IP/dest port or Source/Destination IP and TCP/UDP Port Fields.
If it is mixed or it is hard to determine maybe the best choice would be to use Source/Destination IP and TCP/UDP Port Fields.
2) Second example: in the same infrastructure showed in first example, for connect two switches for connects only devices, no servers, what is your best LACP configurations??
It depends on the typical traffic flow of this clients. Should they be able to communicate with each other? Or they only should go out to the Internet?
If they should only communicate with each other, then the default or Source/Destination IP and TCP/UDP Port Fields would be OK.
If all clients will only use Internet, then it is important to know that all the traffic will have either the source or destination MAC of the default router (depending of the direction). If the outgoing traffic of the trunk is from clients to the internet gateway then the Destination MAC option shouldn’t be used. All others can be used, options using IP and TCP/UDP ports should be preferred for the reasons explained above.
If the outgoing traffic is from the Internet gateway to the clients Source MAC shouldn’t be used.
If it is mixed I would use Source/Destination IP and TCP/UDP Port Fields
3) And If I separate by different VLAN Server and clients, the best configuration that you suggest me, will be always the best solutions, or this infrastructure changement needs a different LACP mode configuration?
If clients and servers are in different VLANs then some device in the LAN (a routing switch or router) has to do the routing. Like mentioned above the routed traffic (traversing VLAN bounderies) will always have the source or the MAC address of the router. That means we have to consider where is located the router the same way as explained above about the internet router. If it is difficult to determine how exactly the routed traffic flows, don’t use L2 load balancing algorithms. Using Source IP/source port is not OK for traffic from servers to clients. Maybe Source/Destination IP and TCP/UDP Port Fields would be the best.
Please note this are purely theoretical considerations. The real network will be more complicated and there may be other things that should be considered and I am forgetting here.
@Valerio Giorgi wrote: According to you, in a SQL DB ERP Server, where all clients are connected to it by a small java client, is it the Servers that have the most outgoint traffic to the client, or not?What kind of servers have more traffic from the clients to the server, for example?
Those questions haven't simple answers, it truly dependes on involved applications complexity and the way they use the network stack to start or to reply to peer requests.
The best thing you can do to try avoid traffic polarization (in favour of a good distribution) over egressing links (of a link aggregation controlled by LACP) is to adopt the most higher level load balancing hashing algorithm (in this oders, when possible: Layer 4, Layer 3, Layer 2), LACP implementation on the switch uses data from configured layer if available otherwise it should fall back to lower layers...until it stop with the minimum required data to compute the required hash used to select the egressing link. This approach is valid on both sides (Server side and Client side) in their egressing directions.
I'm not an HPE Employee
