HP Virtual Connect: Common Myths, Misperceptions, and Objections, Second Edition

#8: VC doesn’t provide deterministic load balancing for multiple LACP

channels

Incorrect: Virtual Connect utilizes a deterministic load balancing algorithm for frames load balanced

across a single LACP channel and VC provides a deterministic algorithm for determining active vs.

standby LACP channels assigned to the same Virtual Connect network (vNET).

VC’s algorithm for frame load balancing within a LAG (port trunk/channel) is automatic based on the

protocol information in the frame. If the frame contains Layer 4 information (for example, TCP, UDP),

Virtual Connect will use it and Layer 3 information (source and destination IP addresses) to determine

conversation streams and statistically load balance individual streams on different ports in the LAG. If

a frame only contains Layer 3 information (IP addresses), Virtual Connect will use the source and

destination IP addresses to determine the conversations to load balance. For all Layer 2 only frames,

VC simply uses the Source and Destination MAC addresses to determine conversations to load

balance across the different ports in the LAG.

When multiple LAGs are configured in a single vNet, VC determines the active LAG based on LAG

bandwidth. The LAG with the most bandwidth (port speed + number of active ports) becomes the

active LAG. All other LAGs in the vNet are put in standby mode (like NIC Teaming). If all LAGs are

equal, VC Enet module ID (MAC address) and uplink port numbers are used to break the tie.

#9: VC Ethernet doesn’t support VLAN Trunking to Server Blade NICs

Incorrect: Virtual Connect does support VLAN Trunking to Blades. VC firmware release 1.31 and

above provides full support for VLAN Trunking to HP server blade NICs. Using Cisco switch port

mode descriptions, VC supports “access” mode, “trunk” mode, and “dot1qtunnel” mode to any server

blade NIC. The VC administrator can choose which mode to use to customize the VC configuration

for their environment.

Further, the VLAN Trunking enhancements included in version 1.31 actually provides more flexibility

than a traditional switch in order to provide enhanced server virtualization and transparent movement

within the data center or across data centers (disaster recovery). This feature, called Mapped VLAN

IDs, allows the administrator to translate tagged VLAN IDs originated by a server to the correct VLAN

ID used by the external network. This VLAN translation (mapping) is completely transparent to the

server blade and the external network. Mapped VLANs are controlled and configured by users with

the LAN administrator role within Virtual Connect for security purposes.

#10: VC Ethernet and Fibre Channel modules require a clunky hardware

failure recovery (RMA) process

Incorrect: Virtual Connect provides high availability and fault recovery using configuration check

pointing/synchronization across adjacent VC Ethernet modules within each c-Class enclosure. In the

unlikely case a VC module fails (Ethernet or Fibre Channel), the complete configuration is retained by

the VC Domain using modules in interconnect bays 1 and 2. When the failed module is replaced,

the configuration is automatically restored to the newly inserted module. In other words, VC supports

plug-n-play of replacement VC modules or additional modules to expand the VC Domain’s

capabilities. Because HP server blades are connected to more than one redundant VC module, “no

single point of failure” configurations are easy to deploy.

VC also supports exporting the VC Domain configuration for manual configuration restoration.