Wireless Access

Hi Guys,

I want to activate link aggregation port on my aruba switch to have a port trunk from my switch to my server's lan ports.

My Esxi config is this:

(Port 1 to 4) i've enabled in Esxi NIC Teaming function with:

Load balancing: Route based on a IP Hash,

notify switches: Yes,

Failback: yes.

Aruba config:

port 3,4,5:

LACP Enabled: Active;

Trunk Group: Trk1;

see the attached image for other details...

When i'm going to enable on my aruba switch LACP in port 2 (that it is my last server's port in my nic teaming), my esxi web server stop to work, and i can't ping my esxi ip until i free one port from aruba LACP port trunk.

I would like to ask if anyone has experienced of nic teaming with esxi host, or if at least my aruba switch config was set up correctly?

Thank you very much for help,

Michele.

Your truking parner column shows NO meaning they are not trunking. The configuration needs to match the ESXi teaming configuration.  Try teaming with the non-LACP using these cli's “no trunk 3,4,5 lacp” then “trunk 3,4,5 trunk”

If it is still not working, can you post few more cli’s: show int trk1, show run int 3, show run int 4, show run int 5, show run | include trunk

Correct: LACP is supported only on vSphere Distributed Switch (so, switch side, you need a LACP Trunk to be configured)...if you are using Route based on IP Hash then you're probably using vSphere Standard Switch...thus use a Non Protocol (non-LACP) Trunk switch side, as suggested.

FYI:

in Aruba OS swtich, the command "trunk x-y trk1 LACP" is LACP dynamic, and "trunk x-y trk1 trunk" is LACP static.

Hi Trinh, that's incorrect.

On ArubaOS-Switch the command:

trunk x-y trk1 trunk

will use ports x to y to create a non-protocol static trunk group with the group name trk1...so no LACP.

I don't know how ESXi host and its virtual switch portchanel configuration.  This observation is between Aruba switch and others.  

When trunk from Aruba switch to another switch, the "trunk x-y trk1 trunk" works with static portchannel, and "trunk x-y trk1 lacp" works with dynamic. 

So, if the other switch that configures with static portchannel and links to Aruba switch that was configured with LACP, the portchannel will not form as show in the picture.

Note: This is not official Aruba guidance - merely my experience working with VMWare and AOS.

My friends who eat, breathe, and sleep VMWare tell me that using LACP with VMWare is not considered a best practice on their side. 

A few key things I've learned while labbing it up (and by extension, breaking stuff in spectacular ways) with AOS is that at the very least you need to do the following:

port groups connected to user/AP anchor controllers:

• Allow Promiscuous Mode
• Allow Forged Transmits
• Allow MAC Changes

On teamed uplinks to vSwitch/DSwitch:

The AOS virtual appliance installation guide says to use LACP on teamed vSwitch uplinks - But since this is not a VMWare BP, and poses a variety of issues of its own on the VMWare side, Teaming method should be Source IP Hashing (I think? Maybe MAC hashing? I need to do some further experimenting to be sure). If you encounter an issue where clients are rapidly associating/disassociating, it's likely something to do with your switch uplink teaming on your anchor controller going haywire... Took me hours to figure that out when I first encountered it. 

Teamed uplinks are not bridged internally within VMWare so they don't pose a spanning tree issue with your uplink switch. You can have two ports with identical config and assigned as uplinks to the vSwitch, and it will not cause the switch to freak out and put one port in blocking mode. This is vastly easier than trying to LACP the only two links on the system - I highly recommend having a separate vmkernel interface on the box just to avoid management headaches. This is very similar to how Windows does NIC teaming. 

A few other considerations: 

While not using VLAN 1 is considered best practice, remember that VMWare does not allow specifying a native VLAN on a trunked switch, so whatever you use as native VLAN on your uplinks will be the the native VLAN within VMWare, and is untagged. This gets a little quirky with port groups set for VLAN trunking.  If your switch supports both tagged/untagged traffic on the same VLAN (not uncommon with data center grade switches), you can have a trunked port group without worrying about this, but otherwise you'll need to make sure your VLANs within AOS are set correctly. 

So if you use VLAN 4000 as your default VLAN and it is untagged on the uplinks, you need create a port group with no VLAN specified, or a trunked one (VLAN 4095 in VMWare designates a trunked port group), and when configuring your AOS device, you can still set the management VLAN as 4000 and either set the port to access mode, or trunked, with 4000 native.

Note that while AOS refers to these interfaces as "gigabitEthernet", VMWare presents them to the guest OS as 10G. The physical controller/conductor appliances also refer to them as "gigabitEthernet" even when they are SFP+ with a 10G module.

Since they are functionally 10G interfaces in VMWare, you  won't need to set up a portchannel (and trust me, you really don't want to go there... If you think LACP on the uplinks is wonky, doing it on virtual ports is even more so)

Virtual Interface 1 (AOS: mgmt) : Not Connected 

Virtual Interface 2 (AOS: GE 0/0/0) : Connected to trunked port group

Virtual Interface 3 (AOS: GE 0/0/1) : Connected to trunked port group (only if needed)

Virtual Interface 4 (AOS: GE 0/0/2) : Connected to trunked port group (only if needed) *This interface will not be present on virtual Mobility Conductor appliances

For in-band management on a virtual Mobility Controller:

interface mgmt
 shutdown
!

vlan 4000
vlan-name Management
vlan Management 4000

interface vlan 4000
 ip address 10.40.0.1 255.255.255.0
!

controller-ip vlan 4000

master-ip 10.40.0.10 ipsec ****** interface vlan 4000

interface gigabitethernet 0/0/0
 switchport mode trunk
 switchport  trunk native vlan 4000
 trusted
 trusted vlan 1-4094
 jumbo
 lldp transmit
 lldp receive
!

The same on a Mobility Conductor (formerly Mobility Master):

interface mgmt
 shutdown
!

vlan 4000
vlan-name Management
vlan Management 4000

interface vlan 4000
 ip address 10.40.0.1 255.255.255.0
!

controller-ip vlan 4000

interface gigabitethernet 0/0/0
 switchport access vlan 4000
 trusted
 jumbo
 no spanning-tree
 lldp transmit
 lldp receive
!

VMWare Networking Best Practices 

Is there an Aruba BP document for dealing with the quirks of VMWare networking?