Creating a LAG between an ESXi vSwitch and a Physical Switch

In this lab I am going to create a LAG (Link Aggregation Group) between an ESXi vSwitch and a physical switch. You can use Cisco, Force10 Dell, Juniper, or any other manufacturer for the physical switch. Depending on the switch you use, the commands may vary on the physical switch for creating a LAG (referred to as port-channel by Force10 Dell and etherchannel by Cisco). I will not get into details of creating a LAG; please reference my earlier posts Creating a Link Aggregation Group (LAG) in FTOS and Setting up Cisco EtherChannels – Static, PAgP, and LACP for this information.
1.

– I already have a static LAG containing two 1 gig ports setup on the physical switch. And this LAG is part of VLAN 100. Two other 1 gig ports are also part of this VLAN. One of these ports is connected to a laptop with the IP of 192.168.1.221. VLAN 100 has an IP of 102.168.1.220.

2.

– I also have two Ethernet cables running from the NIC 2 and NIC 3 ports on the physical ESXi 4.1 server to the switch. The cables are connected to the two ports which are part of the LAG . You can see below that vmnic 2 and vmnic 3 are both part of vSwitch1 on my ESXi server. See my earlier post pNIC, vNIC, and vmNIC Confusion if you need a brush-up on some virtual terminology.

3.

– From the above snapshot, you can see I also have two hosts connected to vSwitch1. I will be using the Kubuntu 10.10 Server Virtual Machine (VM) to ping across the LAG to the VLAN (192.168.1.220) and physical laptop (192.168.1.221). However, before I do that I still need to setup the LAG correctly between the vSwitch and the physical switch.

4.

– What I need to do at this point is setup NIC teaming on the vSwitch. NIC teaming is the procedure of applying policies to a vSwitch or port group to either load-balance based on a specified algorithm or provide failover in-case of hardware failure. I will be setting-up load-balancing.

Below I edit the properties of the VM Network port group. Under the “Load Balancing” drop down box, you can see that there are four options available.

Route Based on the Originating Virtual Port ID – this is the default setting and a virtual port ID is assigned to anything that plugs into the vSwitch. Then based on this virtual port ID, the VMkernel assigns a pNIC as an uplink to the guest on the vSwitch. Whenever the guest tries to communicate through the vSwitch out to the physical LAN, the VMkernel will always attempt to pass the traffic through the assigned pNIC (as long as this pNIC is up).

Route Based on IP Hash – with this option a vSwitch can use multiple uplinks at the same time to communicate out to the physical LAN. However, for this option to work, 802.3ad link aggregation must be configured on the physical switch.

Route Based on MAC Hash – operates similar to the virtual port ID policy. vSwitch guests are assigned a single uplink to use, however, this time the VMkernel uses the MAC address to assign and distribute available uplinks. If the link were to fail, the remaining NIC(s) would handle the traffic.

Use Explicit Failover Order – with this option only one NIC is active at any given time; the other NIC is on standby in-case a hardware failure were to occur with the active NIC.

5.

– From the above options I use “Route Based on IP Hash”. As you can see from the below snapshot, from the Kubuntu virtual machine, I am able to ping both the VLAN IP on the physical switch and the physical laptop’s IP!

Successful ping from VM to physical LAN