In vSphere 5.1, LACP implementation has some constraints and those were:
- Supports only one LAG per VDS per host.
- All uplinks in the dvuplink port group are included in this LAG.
- Only the IP hash load balancing algorithm is supported.
So essentially what we were missing are:
- Multiple LAGs per host.
- Multiple load balancing options.
Before I move onto how vSphere 5.5 has resolved these constraints, let me reiterate few basics about LACP.
LACP – Link Aggregation Control Protocol is a standards-based method (IEEE 802.3ad) to control the bundling of physical network links to form a logical channel for increased bandwidth and redundancy purposes.
LAG – A Link Aggregation Group is a grouping of multiple individual links – with compatible properties – formed into a single logical channel. This can be a manual process or performed by a controlling protocol such as LACP.
Hashing Algorithm – The hashing algorithm determines the LAG member used for traffic. LACP can use different properties of the outgoing traffic (e.g. source IP/Port number) to distribute traffic across all the links participating in a LAG.
LACP is installed as a kernel module and user world daemon lacp_uw. The module will be automatically loaded and the daemon executed after the host boots.
Now let me show you a typical setup to make you understand what is the enhancement VMware has made in version 5.5
But Why do you need multiple LAG?
- DC networks moving towards 10GbE, which require multiple etherchannels
- Hosts with mix of 1GbE and 10GbE NICs need multiple etherchannel support
Enhancement In vSphere 5.5
- Support multiple LACP LAGs
- Max 32 LAG per Host
- Max 64 LAG per VDS
- Support all supported hashing algorithms in LACP (22)
LAGs are composed of new LAG uplinks. Each physical NIC (vmnic) taking part in the LAG is assigned to a single LAG uplink.
Note: Uplinks must be going to either the same switch or a pair of switches appearing as a single logical switch (using vPC, VSS, MLAG, SMLT, or similar technology).