Manualshelf

Virtual Connect and HP A-Series switches (A5820) IRF Integration Guide

ManualsBrandsHP ManualsComputer AccessoriesHP Virtual Connect Flex-10 10Gb Ethernet Module for c-Class BladeSystem
12345678910
3
Design scenarios
Two typical design scenarios are available to connect Virtual Connect with network switches.
A common misunderstanding people tend to have when connecting Virtual Connect with IRF or Cisco
vPC/VSS switches is described in the following page. The design does not work.
The above concepts apply to all Virtual Connect models providing ethernet connectivity, which
include VC 1/10-F, VC Flex-10 and VC Flexfabric modules.
Scenario 1—This is a typical connection scenario, in
which Virtual Connect modules connect with non-
IRF/vPC/VSS capable switches.
Virtual Connect needs to configure one SUS (Shared
Uplink Set) per Virtual Connect module (two total).
Switch 1 and switch 2 each have one port channel
configured to peer with Virtual Connect SUS.
Scenario 2—This is the recommended connection scenario,
in which Virtual Connect modules connect with
IRF/vPC/VSS logical switch.
Virtual Connect needs to configure one SUS per Virtual
Connect module (two total). The logical switch also has two
port channels configured to peer with Virtual Connect SUS,
which is known as Active/Active Virtual Connect design.
Active/Standby Virtual Connect design is also available,
but because it does not use all available uplink bandwidth,
it is not discussed here in more detail. For more information
on Active/Standby design, see scenario1:4 in the HP
Virtual Connect Ethernet Cookbook
(http://h20000.www2.hp.com/bc/docs/support/Support
Manual/c01990371/c01990371.pdf).
This design provides two main benefits over the previous
design:
If either switch fails, traffic remains on the same port
channel and rehashes to the remaining physical link in
less than one second. The server does not require failover
tests.
For the incoming traffic from upstream core switch to
server direction, all traffic can be sent to Virtual Connect.
Previously, if the destination MAC (media access control)
was on the other switch, the traffic would have to
traverse the inter-switch trunk, so the flow was not
optimized.