unable to promote vds 5.5 lacp uplink from "unsed" to "standby"

[ayoungdahl]

Last night I was working with a network admin at aggregating some uplinks between a 5.5 vds and some Dell Powerconnect M6220 switches.

After creating the lag on the vds I went to "Mangage Distributed Port Groups" to set the lag as a standby uplink for my port groups.

The  reconfiguration task completed successfully with a green check, but the lag uplink remained in the "unused" category; it was never promoted to standby.

I tried a few times with the same result.

The only thing resembling an error message that I've been able to find so far is from the event log:

                              The dvPort 200 was not in passthrough mode

Port 200 is one of the port id's which fall under the "Port channel" categories on my vds.

There are other similar entries for other lag port id's

Does anyone know what my difficulty in promoting the lag uplink to standby might be?

I have to confess that vds is a newer animal for me and this is my first attempt at link aggregation so it is fairly likely that I've made a misstep, but I haven't been able to figure out if I have and what it is yet.

I'll be spending my afternoon/evening/week(end) trolling through the log bundle and reviewing KBs to see if I can locate any clues.

If anyone has any ideas it would be great to hear them.

Thanks

[MKguy]

You cannot have any standby or unused links in a LAG. All ports must be fully active. This is because the physical switch won't be able to tell what the state of a port on the ESXi side is, resulting in the physical switch forwarding traffic in a standby black hole. Not sure why it won't prevent uplinks being set to unused as well.

See this KB article for reference:

http://kb.vmware.com/kb/1004048

Note: The only load balancing option for vSwitches or vDistributed Switches that can be used with EtherChannel is IP HASH:

    Do not use beacon probing with IP HASH load balancing.

    Do not configure standby or unused uplinks with IP HASH load balancing.

Or here:

http://longwhiteclouds.com/2012/04/10/etherchannel-and-ip-hash-or-load-based-teaming/

Can’t configure standby or unused uplinks.

[ayoungdahl]

What you're saying about LAG ports not being in standby makes a lot of sense.  The "Manage->Settings->LACP->Migrating network traffic to LAGs" link off the 5.5 web client instructs to do this very thing however.  I wonder if its misinformation or if the rules of the game have changed.

Unfortunately we're not going to be able to test any solutions becuase we've just discovered that there aren't stacking modules on the Powerconnect M6220's that we're trying to talk LACP with.  Each blade uplink talks with a different M6220 & without stacking these switches link aggregation won't work.  Whether or not this would prevent the LAG from moving to standby isn't clear to me but it appears that link aggregation is off the menu.

The LBT solution promoted by longwhiteclouds looks promising.  Now I only have to convince the network folks that this will be OK.

Thanks for our post

[MKguy]

I think I may have misunderstood your problem, the case of a migration from non-LAG uplinks to a LAG is an entirely different thing. What I was talking about applies to the regular uplink settings of a vSwitch/port group.

LBT is a great way to easily distribute traffic on multiple links without any special requirements on the physical network. LACP/etherchannel to the host makes sense if you use NFS storage or a single VM (vNIC) needs to be able to exceed the bandwidth provided by a single physical uplink. But unless that is necessary, I personally would prefer to keep it simple and stick with LBT.

Here are some great points on the whole LBT vs. LACP/etherchannel debate:

http://wahlnetwork.com/2014/01/13/vsphere-need-lag-bandaids/

http://wahlnetwork.com/2014/02/05/revenge-lag-networks-paradise/

[ayoungdahl]

Thanks for the links.  They're great articles!