HP Brocade 8/24c HP Virtual Connect: Common Myths, Misperceptions, and Objecti - Page 9

: VC Ethernet doesn't support VLAN Trunking to Server Blade NICs

Page 9 highlights

#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. 9

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32

9
#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.