Using static port channel VS LACP

[stheriault99]

Hi,

I configured my ESX hosts to connect back to my Catalyst 3750 stack with a static port channel (mode on).  It happened a few times, that one of my NICs on my ESX host, which is in my port channel, died and it stopped some of the communication of the VMs on the ESX host. Not all VMs stops communicating, just a few, and the only way to get them to communicate on the network again is to reboot the VMs. 

Is the above situation a normal operation of the static port channel and would LACP fix this issue?

Thanks.

[Steve Fuller]

Hi,

I've seen similar issues with static port channels and so will always use LACP where it's supported by both link partners.

The problem with static port-channels is that if one end of the link aggregate (LAG) unbundles a physical link from the LAG, but the link remains up, the partner will not know that link is no longer part of the LAG and continue to use it. This will most likely result in the black-holing of traffic.

This doesn't happen when using dynamic LAG because the two devices communicate across the LAG with LACP to organise and control the operation and members of the LAG.

The use of LACP might not be as simple as you'd like though, as depending upon the ESX version and the vSwitch type you're using, LACP might not be available. The support for LACP is only available if you're using the Nexus 1000V or the VMware Distributed Virtual Switch from vSphere 5.1.

Regards

[stheriault99]

Thank you for the explanation;  I do have vsphere 5.1 and nexus 1000v.

So with LACP, if the NIC fails for any reason, the interface in that LACP port channel will go in an err-disable mode, correct?

Also, I read a document stating that LACP should be configured at the VEM level, because if the VSM and VEM would loose communication, and the ESX host would reboot during this time, the port channel would not be able to establish itself.  What are your thoughts on that?

Thanks

[Robert Burns]

What you're referring to is "LACP Offload" and yes you should enable it.  This will allow the VEM to negotiate the port channel with/without access to the VSM.

The two main advantages LACP offers are 1) It will monitor the health of each link.  If there are any issues, it will bring it down and hash traffic to remaining link.  If there's a hard link down either LACP or static will respond, but LACP monitors deeper health issues where static does not.  2) LACP will check the configuration on each side for consistency.  This adds a little insurance to ensure you don't mis-configure the links by accident.  Before the channel is formed, consistency is checked, and then off you go.

Regards,

Robert

[stheriault99]

Thank you for all this great info; I appreciate your help!

So here is what I currently have configured on my VSM and Cisco 3750 stack, and i've underline the commandes that need to be added to enable lacp offload, can you confirm if this is what I need?

conf t

feature lacp

port-profile type ethernet uplink

vmware port-group

mtu 1500

switchport mode trunk

switchport trunk allowed vlan 10,988-989

switchport trunk native vlan 900

channel-group auto mode on

no shutdown

system vlan 10,988-989

description uplink

state enabled

And here is what I have configured on my Cisco 3750 at the other end;

interface Port-channel8

description Etherchannel connection to  ESX

switchport trunk encapsulation dot1q

switchport trunk native vlan 900

switchport trunk allowed vlan 10,988,989

switchport mode trunk

switchport nonegotiate

spanning-tree portfast trunk

interface GigabitEthernet3/0/24

description 22 - nic2

switchport trunk encapsulation dot1q

switchport trunk native vlan 900

switchport trunk allowed vlan 10,988,989

switchport mode trunk

switchport nonegotiate

channel-group 8 mode on need to change to active

spanning-tree portfast trunk

end

interface GigabitEthernet2/0/24

description 22 -  nic3

switchport trunk encapsulation dot1q

switchport trunk native vlan 900

switchport trunk allowed vlan 10,988,989

switchport mode trunk

switchport nonegotiate

channel-group 8 mode on need to change to active

spanning-tree portfast trunk

end