Link Aggregation allows combining multiple network interfaces as one virtual interface for the purpose of providing fault-tolerance and high-speed links. Most people focus on the latter as speeding up network deployments it always a high priority. Before going down this path its important to know how SDA Link Aggregation works to determinate if it will be beneficial in your environment. In some cases it will not help and you will have added an extra layer of complexity to your environment with little or perhaps no gain.
Assuming your current SDA is not using link aggregation, the first step is to determine how much network band width the SDA is using under peak load. If your current network connection is not fully saturated and by that I mean 80% utilized over a sustained period of time, link aggregation will not provide any benefits in terms of deployment times. This is because link aggregation does not create one channel with twice the bandwidth, it creates two channels with the same bandwidth (see below ) so if a single channel is not being fully utilized adding a second channel will simply add a channel that will not be fully utilized or perhaps not used at all. Further because of the way Link aggregation works (see below ) unless multiple simultaneous deployments are being used, link aggregation will not provide any benefit. In other words, a single deployment will run at the same speed whether link aggregation is used or not.
SDA Link Aggregation uses Link Aggregation Control Protocol (LACP) LACP will negotiate a set of aggregate links with the peer in to one or more Link Aggregated Groups (LAG). Each LAG is composed of ports of the same speed, set to full-duplex operation. LACP balances outgoing traffic across the active ports based on hashed protocol header information and accepts incoming traffic from any active port. The hash includes the Ethernet source and destination address, and, if available, the VLAN tag, and the IPv4/IPv6 source and destination address.
LACP does not scale at a 1 to 1 rate. So aggregating two 1GB channels will not give 2GB throughput. The reason adding two physical links does not increase your bandwidth proportionally is LACP does not load balance each tcp frame across each channel in the aggregation, but instead binds the entire network conversation to a single channel based on the hash (above ). Since the hash is always the same ( as the source and destination addresses do not change) a single host will be bound to a single channel for all network communications, unless the channel goes down forcing all traffic to the remaining channel. LACP does this to avoid a significant CPU overhead that occurs should tcp packets arrive out of order. For example if tcp frame one were sent over channel 1 and tcp frame 2 was sent over channel 2 then because of congestion or other network latency, frame 2 could arrive at the destination before frame 1. The destination computer must hold off delivery of frame 2 until it can deliver frame 1 so there is lag while the destination computer waits for frame 1 to arrive and then has to re sequence the frames in the correct order before sending them to the application. The downside to this solution is true load balancing is never really achieved. In general loading of 70/30 is more realistic. Further all source/destination pairs are bound to a single channel by the hash with no allowance for the actual load currently on the channel. This means one channel could be saturated (and experiencing latency ) while the other could be idle.
For this reason, a single deployment using link aggregation will still bind to a single channel and thus receive no benefit from it. Likewise if the bandwidth of a single channel connection is not fully utilized, Link aggregation will again provide no benefit in terms of deployment speed (it will of course provide network redundancy ). For example say at peak load on a SDA without link aggregation the bandwidth utilization across the SDA port is 60%. Since there is more than enough bandwidth adding link aggregation will simply use two Ethernet connections at a lower percentage ( 40%/20% for example ) with no network speed increase.
When it is appropriate to use Link Aggregation:
If the peak network utilization across the port the SDA is connected to is approaching 80% for extended periods of time (TCP overhead generally uses about 20% of network bandwidth so network throughput usually degrades at better than 80% utilization) AND this happens while doing multiple simultaneous deployments OR you wish to have network redundancy with no expectation of network speed increase then Link Aggregation may be helpful.
Before setting up Link Aggregation, ensure your switch supports LACP.
Switch configuration (configure LACP ):
All ports in a channel group must have the same configuration for Speed and Duplex settings
(its a good idea to hard code these on the switch leaving the SDA set for negotiate )
All ports must be assigned to the same VLAN and have matching switchport modes
LACP must be configured to use active mode as the SDA uses passive and one side of the aggregation is required to use Active mode.
SDA configuration
At this point, the SDA reboots and the IP address changes to the link aggregation IP address you entered. For more information, please see the SDA Admin Guide.
© 2024 Quest Software Inc. ALL RIGHTS RESERVED. Terms of Use Privacy Cookie Preference Center