- Integrated Systems
- About Us
- Integrated Systems
- About Us
07-08-2011 09:26 AM
VMware ESX physical NIC control on VC Active/Passive scenarios - teaming mode?
Rinaldo had a VMware NIC teaming and Virtual Connect load balancing question:
On the VC Ethernet Cookbook (august 2010 Edition) in the Scenario 1:5 – VLAN Tagging (802.1Q) with a Shared Uplink Set (SUS) with Link Aggregation using LACP (802.3ad) – VMware ESX
It’s reported to use Load Balancing based on Port ID.
As it’s a Active/Passive scenario, wouldn’t the second physical NIC transmit thru the horizontal stacking link o reach the Active uplink?
Shouldn’t the Load Balancing be disabled?
The active/passive scenario only refers to the uplinks out of the enclosure, all NICs will still be active as VC will route traffic internally to the module with the active uplink.
Chris also had some input:
Also, you circled “Beacon Probing” in the vSwitch image. That has nothing to do with load balancing traffic across pNICs. Beacon Probing is a method of Path Validation. You should make sure that the NICs have the latest firmware and driver, then change the Network Failure Detection to “Link State.”
This is documented in the “VC Flex-10 and vSphere 4 Networking Reference Architecture” and “VC FlexFabric and vSphere 4 Networking Reference Architecture” whitepapers I published. What isn’t called out is the specific firmware and driver versions that would be required. That is maintained in the “Virtual Connect Solution Recipe” whitepaper.
And Greg had a lot to say:
When the VC cookbooks and recipes walk through the ACTIVE/ACTIVE and ACTIVE/PASSIVE configs, they do so from the context of the Virtual Connect domain. That is uplink connectivity leaving the VCD networks have a single ACTIVE uplink each VC network presentation or has an additional STANDBY uplink for each VC network presentation.
In ACTIVE/ACTIVE VC configuration a single VLAN/broadcast domain in the core Ethernet fabric is represented as two separate VC Networks ie VLan100 = Vlan100_A and Vlan100_B. These VC networks are only serviced by ONE Shared Uplink Set that typically are serviced by ACTIVE uplinks.
In ACTIVE/ACTIVE VC configurations Server profiles should be constructed to ONLY present Vlan100_A, and Vlan100_B to Ethernet connections that physically service the SUSs they are defined within. If this is server profile Ethernet connection alignment is not done then the Ethernet packets must traverse a stacking link to reach the ACTIVE uplinks for that VC Network.
In ACTIVE/PASSIVE VC Configuration a single VLAN/Broadcast domain in the core Ethernet fabric is represented as a single VC Network. Ie Vlan 200. ACTIVE /PASSIVE topologies typically have a single Shared Uplink Set with a set of uplinks that span multiple VC modules and/or core switches. The LACP protocol will then keep all paths that do not have the same upstream peer as standby paths.
In ACTIVE/PASSIVE VC configurations server profiles should assign Vlan200 to separate Ethernet connections serviced by different VC modules. Ethernet packets sent from the host to toward the VC Module with the uplinks held in standby would be rerouted across the stacking links toward VC module with the ACTIVE uplinks for the VC network.
Note: Host network interface teaming can easily accommodate both ACTIVE/ACTIVE or ACTIVE/STANDBY. The Host OS typically has no knowledge that it is connected to an ACTIVE/ACTIVE or ACTIVE/PASSIVE VC topology.
Opinion: IMHO I fail to see the rationale for configuring ACTIVE/STANDBY OS teaming as it polarises and tends to unbalance network traffic flows. Equally I see little or any benefit standby interfaces or uplinks as they halve/reduce the network capability/capacity between the access and distribution layers of a network topology. ACTIVE/ACTIVE VC Uplinks topologies with purposely crafted Server Profiles and ACTIVE/ACTIVE Host OS Teaming should provide the most reliable and highest throughput combinations
Your thoughts on the matter? Here is a link to the VC Ethernet Cookbook: http://h20000.www2.hp.com/bc/docs/support/SupportManual/c01990371/c01990371.pdf