Implementing LAG between Stack Switches and VMWARE ESXI 6.7.0

[axom]

Hi All,

This probably has a easy fix.
I am trying to configure LAG between 2 Cisco Stack Switches (SG350X) on one side and with a ESXI hypervisor hosted in a Lenovo IDRAC. There is only one NIC in the IDRAC with 4 slots in it.
The problem I experience is when I configure LAG between the 2nd switch and the NIC slot 2. When I plug the cable from the slave/2nd switch to the NIC 2nd slot we lose all our connections to the server. We have STP enabled. The master switch is connected to the NIC slot 1 without any issue.

interface GigabitEthernet1/0/6
description ***VMWare-NIC2***
channel-group 2 mode on
switchport access vlan 101

interface GigabitEthernet2/0/6
description ***VMWare-NIC4***
channel-group 2 mode on
switchport access vlan 101

Please let me know if I need to provide any other details.

Any guidance will be appreciated. Thank you!

[balaji.bandi]

Can you post-show run interface port-channel 2 from the switch?

have you configured on the ESXi side the same LAG config below example for LACP, the same way you can configure?

https://kb.vmware.com/s/article/1004048

If you decide to go LACP, you need to check the switch side also

channel-group 2 mode active

[axom]

Dear Balaji,

Thank you for your response. 

show running-config interface Port-Channel 2
interface Port-Channel2
switchport access vlan 101
!

The configuration the ESXI side is not exactly the same but its been configured. 

I do not have LACP Active on either sides as I had chosen to go without using any protocol.

[Georg Pauwen]

Hello,

the load balancing algorithm needs to be IP-SRC-DST.

On the SG350x switches you only have two options (MAC Address and IP/MAC Address), select 'IP/MAC Address' in 'Port Management > Link Aggregation > LAG Management'.

https://www.cisco.com/c/en/us/td/docs/switches/lan/csbms/350xseries/2_5_7/Administration/tesla-350-550/port-management.html#ID-0000263d

I am not sure if that is the exact equivalent of IP-SRC-DST.

If that doesn't work, the SG350x LAG/LACP implementation is probably not compatible with ESXI. These are small business switches that do not run a full IOS...

[paul driver]

@Georg Pauwen  LB won’t negate the pc from being established as you can and sometimes need to do have different lb modes either side of the pc

[Georg Pauwen]

@paul driver That might be true...is that documented somewhere, or based on your lab testing ?

According to the official ESXi docs:

--> Supported switch Aggregation algorithm: IP-SRC-DST, for example (short for IP-Source-Destination).

This is the only supported algorithm...

[paul driver]

@Georg Pauwen 

---

@Georg Pauwen wrote:

@paul driver That might be true...is that documented somewhere, or based on your lab testing ?

According to the official ESXi docs:

--> Supported switch Aggregation algorithm: IP-SRC-DST, for example (short for IP-Source-Destination).

It’s based on various actual production environments I have worked on, As others have stated @balaji.bandi @Elliot Dierksen 
Its possible down to the link negotiation as an issue not the LB method, However I haven’t read the latest documentation on EXSI regards LAG,  But I’m quite sure at this time it isn’t specifically down to the LB method that is negating the LAG from becoming active.

[Georg Pauwen]

@paul driver Interesting. Which ESXi versions were used in these production environments, and which firmware versions on the SG switches ? If you got it to work, it must work, obviously.

My initial thought was that it probably does not work at all, since these small business Tesla switches run some sort of hybrid (at best) IOS.

Anyway, no feedback yet from the OP. It might also just be the Lenovo iDRAC. Which cards were used in your environment(s) ?

[paul driver]

Hello
@Georg Pauwen  -

Usually it’s down to misconfiguration, mismatch static/dynamic protocols and spanning tree (L2 PCs), in some cases I’ve had to tweak LB methods to accommodate servers/esxi connections which if I remember didn’t cause any issues, especially dropping the link. .
So, requiring a specific LB method just for a logical aggregation link to become active isn’t something I have come across as such it would be interesting to see if this is indeed the root cause and if it is, then I stand corrected.

[Elliot Dierksen]

Everything @Georg Pauwen and @balaji.bandi mentioned is correct. I will add my experience that the migration from individual ports to using a LAG is tricky. I haven't had to do it in a while, but what I had to do was build a distributed vSwitch with the LAG and leave at least 1 NIC in the standard vSwitch. Once the connection comes up in the distributed vSwitch, you use "migrate networking" in Vcenter to move the connections to the distributed vSwitch. After that is completed and everything is working, you disconnect the remaining NIC and add it to the distributed vSwitch. Then you modify the switch config to add it to the port channel. Lastly you connect that NIC and make sure it gets added to the port channel.

[paul driver]

Hello
is the server side teaming ?

I assume it actually supports aggregation?-  if the connection comes up on a single interface without aggregation then it has to do with either requiring an aggregation protocol (in your case this isn’t being used as your are using a static pc) or server side isn’t configured correctly.