Exploring Enhanced LACP Support with vSphere 5.5

I recently realized that while I have been enjoying working with the enhanced LACP feature provided with the vSphere Distributed Switch (VDS) version 5.5, I’ve never actually taken any time to document the process. For those who want to create a Link Aggregation Group (LAG) in 5.5, or have already been through the process in 5.1 or older, I will share that the process is incredibly different. While there are a few more steps in the process and numerous wizards to walk through, the end results are spectacular. I think you’ll find the resulting LAG much more transparent and flexible than the days of yore. But, you’ll have to be the judge – so let’s dig in!

Note: You can find my opinions on why you would and would not want to create a LAG, too.

Migrating to VDS version 5.5

First things first. If you haven’t taken the time to upgrade your VDS to 5.5, we’ll need to get that squared away. I’ll walk through the process in my lab with an existing VDS version 5.1 that already has LACP enabled.

All steps are shown via the vSphere Web Client. There is no way to do this in the legacy C# vSphere Client. Don’t blame me. 🙂

Start by navigating to VDS > Manage > Settings and verifying your properties. Make sure there are no errors on the switch, the hosts attached are healthy, and you have a backup (just in case).

This VDS is still running 5.1 - upgrade time!
This VDS is still running 5.1 – upgrade time!

Right click on the VDS and choose the Upgrade Distributed Switch… option from the contextual menu. My wizard had only one option: version 5.5.0 with new features (such as enhanced LACP support). Assuming that all of your attached hosts are running ESXi 5.5 or greater, the compatibility check will return green check marks and allow you to proceed as shown below:

Green means go
Green means go

The VDS I’m upgrading already uses LACP and needs to undergo feature conversion. You may not see this step if you don’t have LACP enabled. A final prompt in the wizard will confirm that I wish to include enhanced LACP support on my VDS. Check the box and click finish.

The point of no return
The point of no return

It’s time for … another wizard! Yay. 😉

Enhanced LACP Support Wizard

It’s time to get schooled on enhanced LACP support by another wizard. It’s nifty that VMware has taken the time to educate folks on what the upgrade means and how to configure the new options.

The first screen, which I’ve included below, covers the new features:

LACP is a dish best served cold
LACP is a dish best served cold

Once you’ve assimilated all of the magical new toys at your disposal, it’s time to run a validation test for port group accessibility, LACP configuration, uplink teaming policy, host accessibility, and host connectivity. The wizard is picky about making sure you are really, really ready for this upgrade. So, don’t slack (and take a backup)!

Validating that your environment is happy enough for enhanced LACP
Validating that your environment is happy enough for enhanced LACP

If everything passes the test, move along to the next screen where we actually get to build a LAG. Make sure to choose a highly descriptive and business sounding name – like I did below:

You can't edit the other options right now, but you can later
You can’t edit the other options right now, but you can later

The completion screen gives you a recap that covers the LAG creation. I especially like the “your LACP basic support is ready to be enhanced” part. I read it in the voice of the HAL 9000. Didn’t you?

Note: Did you backup your VDS? Disaster loves the unprepared.

Enhance that LACP, yeah!
Enhance that LACP, yeah!

A task will kick off that reconfigures your VDS. Once completed, you can now dig into the guts of your new LAG and make some changes.

Editing the LACP Configuration

If you have a trained eye, you may notice that there’s a new menu option in the VDS > Manage > Settings area called LACP. In this area live all of your LAGs, as shown below:

Tremble at the almighty Spongebob LAG
Tremble at the almighty Spongebob LAG

If you select one of your LAGs – or in my case, the only LAG available – and then choose Edit (the pencil icon), you can make a few changes to the LAG.

  • The name of the LAG
  • How many ports the LAG will use
  • The LACP mode (I recommend Active)
  • Load balancing mode – now with a bazillion new hashes!

Here’s an example of these options for my Spongebob-01 LAG:

Welcome to a world beyond IP hash
Welcome to a world beyond IP hash

Now that a LAG is created, we need to ensure the network adapters are bound correctly and then do something useful with the LAG.

Placing Network Adapters into a LAG

Because I’ve upgraded my VDS with an existing LAG on it, vSphere did all the heavy lifting for me. The wizard automatically assigned my two uplinks (network adapters) to the Spongebob-01 LAG. But what if you wanted to do this yourself? Let’s review the process.

Managing which uplinks are in the LAG is as simple as editing your physical network adapter relationships on the VDS. To begin, select your VDS and navigate to Actions > Add and Manage Hosts. Then choose Manage host networking and select the attached host(s) that you wish to edit. Finally, choose the Manage physical adapters check box and uncheck any other boxes. You should see a wizard screen like what I have below:

My two physical adapters are bound to the Spongebob-01 LAG
My two physical adapters are bound to the Spongebob-01 LAG

The two network adapters I have, vmnic3 and vmnic4, are both bound to the uplink named Spongebob-01. The trailing 0 and 1 denote the port number within the LAG. If this were not so, I could click on vmnic3, select the Assign uplink option, and put it onto a LAG. Then repeat the process for vmnic4. I’ve provided an example below:

The relationship between the LAG and physical network adapters
The relationship between the LAG and physical network adapters

Putting Your LAGs to Work

This is where things deviate significantly from what you may be used to with VDS 5.1 and older. Previously, we had to set the load balancing policy of all port groups to “Route based on IP Hash.” Now, the LAG is represented as an uplink and can be selected in the failover order. Additionally, the load balancing policy is rendered useless by the LAG.

That’s right. The LAG will override your port group’s load balancing policy. It doesn’t matter what it’s set to when a LAG is Active.

Here’s an example with a port group on my VDS where I have included the informative warning on the load balancing policy:

Spongebob-01 is now an uplink, and the load balancing is overrided
Spongebob-01 is now an uplink, and the load balancing is overrided

You can also see the LAG ports in use by going to VDS > Manage > Ports. In this case, VMware uses the term port channel to denote the LAG and its members:

My two 10GbE uplinks are members of the LAG
My two 10GbE uplinks are members of the LAG

Keep in mind that you can only have one single LAG as an Active uplink. If you make other LAGs, they must remain Unused. Otherwise, you’ll see an error like so:

Don't get greedy; just one LAG per port group
Don’t get greedy; just one LAG per port group

Thoughts

I’ve yet to encounter one of these bad boys in the wild. Perhaps it’s just too soon in the patch cycle for many folks to adopt ESXi 5.5? Either way, the upgrade process is relatively straight forward once you get the hang of it. Additionally, the new LACP management area on the VDS is much better than the old method of hunting for LACP on the dvUplinks group.

If you are looking to enable enhanced LACP support on an existing switch, check out Enhanced LACP Support missing in my Distributed Switch 5.5 by Romain Decker.