BladeSystem Virtual Connect
Showing results for 
Search instead for 
Did you mean: 

Question on teaming NIC's for load balancing ESXi 4

Trusted Contributor

Question on teaming NIC's for load balancing ESXi 4

Joe was looking for advice on NIC teaming with VMware ESXi:




I am having a discussion with my customer over proper configuration of NIC Teaming in ESXi.   

His solution, when we completed his configuration, was much like Scenario 6 in the HP VC FlexFabric Cookbook.  Today he may have only one NIC per vSwitch per the information from VMware.  His statements about “Hash of Source and Destinations IP’s” for a failover algorithm is not supported but also not default.  I contend the 802.3ad is from the VC Uplink ports and are not seen at the downlink ports.  The vSwitch NICs do not see 802.3ad trunks from the uplink side of the Virtual Connect Modules.  Is this not the issue VMware is having with the customer?




Lots of info:




From Chris L.:

The VC and vSphere Networking Reference Architecture document outlines what is and isn’t supported.  As I state in the VC and vSphere Networking Reference Architecture whitepapers, all of the NIC hashing algorithms except the “Route by IP Hash” are supported by Virtual Connect.  I clearly state this is for DOWNLINKS, not UPLINKS.  Virtual Connect does not support LACP (or to use the term your customer understands, PortChannel) on the Downlink ports, which has NO bearing on the Uplink Ports connecting to the DC switching infrastructure.  VC does support LACP (PortChannel) on the uplink ports, just not across physical modules.


Uplink ports are different than the Downlink ports, and have different characteristics.


From Chris R.:

One NIC in a vSwitch is not going to give him High Availability (HA), if the VC goes down so does that vSwitch.

The one thing I remember from VC training is not to use IP hash.

Beacon Probing can be used instead of Smartlink, informal testing with a customer without Smartlink we lost two pings with Smartlink we only lost one.


Again from Chris L.:

Beacon Probing should not be used, unless 3 NICs can be allocated.  Beacon Probing becomes unreliable in most customer environments when only 2 NICs are used, so SmartLink should always be used when deploying Active/Active configurations.  You will see that setting enabled in all of the VC Cookbook and Reference documents.


Reply from Joe:

Thanks to all who have responded.  It helps confirm my direction and my practice but also helps with my language with customers.  Chris,  I have looked at your document, if I recall correctly it is dated 2009 but I am wondering if additional screen shots related to Teaming/Redundant setup would be useful.  In other words, demonstrate the default selections are appropriate such as link status vs beacon probing or the preferred  “Route based on the originating virtual port ID” for load balancing.




Any other comments or suggestions?