User guide

HP Virtual Connect for Cisco Network Administrators (version 4.x)
Document Number: C01386629 Date: January 2014
page 48
Appendix C: Frequently Asked Questions
Q1: Why do I see lots of dropped frames (discards) on standby VC uplink ports?
A1: An external switch has no concept of which VC link is the active uplink and which is the standby uplink. As far as the external
switch is concerned, one of the uplinks is just a whole lot busier. That means that the external switch is still going to send some
types of frames down the standby link and the standby link is going to discard them. This includes all broadcasts, multicasts, and
unknown unicasts (destination lookup failure in the CAM table on the external switch). Any of these frames that are received on the
standby link will be dropped and will be reflected in the counters.
Q2: Can I manually choose which port channel is the preferred channel for a vNet?
A2: No, VC does not currently support setting the ‘port role’ for vNets (or Shared Uplink Sets) with LACP enabled (connect mode
‘auto’). VC determines which port channel is active and which is standby, based on the following criteria, 1 - Number of
functional uplinks per port channel, 2 – Total bandwidth provided by each port channel, 3 – if the previous two are a tie, then the VC
module with the lowest MAC address (see TOE tag) will provide the active port channel. With the information above, the
Administrator could construct the primary port channel with one addition uplink in order to make it the preferred port channel.
Q3: Do I have to use the same load balancing algorithm on both sides of the same port channel?
A3: No, you can have different load balancing algorithms on each side of a port channel. But as a course of good
network design it is best to use the same load balancing in each device in the path to insure the most optimal traffic
flow.
Q4: I see Link Layer Discovery Protocol (LLDP) frames when I connect a network trace analyzer to a VC uplink port. What is VC
doing with LLDP and can I disable it?
A4: LLDP is the IEEE equivalent to Cisco Discovery Protocol (CDP). It is a Layer 2 protocol that allows one device to both
announce itself (and some of its feature set) to a neighboring device as well as discover other connected devices on the
network. It is extremely low-bandwidth and is unobtrusive. VC uses LLDP to determine when one of its uplinks or cross-connects is
directly connected to another VC module in the same VC domain so that it can form a stacking link. There is currently no way to
disable it.
Q5: VC Ethernet is just another switch
A5: Incorrect: While VC uses tried and true, IEEE standard, Layer 2 bridging functionality, its primary
purpose is to provide many server virtualization and management features that are nonexistent in
traditional switches. VC may perform some functions like a traditional switch; however, VC has many additional features which clearly
distinguish it from a traditional switch. Likewise, server virtualization hypervisors (for example, VMware ESX, Microsoft HyperV,
Citrix Xen) perform some functions of a traditional switch but, like VC, have many additional features which clearly distinguish them
from a traditional switch. As a result, it is incorrect to say that either technology, VC or hypervisor virtual switching, is “just another
switch”. VC and server virtualization hypervisors are very similar in the networking functionality that they provide to servers; a
hypervisor provides it for virtual servers and VC provides it for physical HP server blades. In the same way that a hypervisor provides
this functionality in a way that interoperates with the external network, VC also provides this interoperable connectivity between HP
server blades and the external network. Virtual Connect is not called a “switch” because it is not configured, deployed, or managed as a
switch and does not present itself to the external network as a switch again, much like a hypervisor. When Virtual Connect is linked to
the external network, the external network “sees” the same behavior from VC as it “sees” when a server hosting a hypervisor is
connected to the external network. Since VC is not configured, deployed, or managed like a traditional switch and presents itself to the
network as an endpoint (like a server), it is incorrect to call VC a “switch”.
Q6: I am trying to get 802.3ad Port Trunking to work but can’t seem to get it to pass traffic. What am I doing wrong?
A6: VC currently only supports LACP for 802.3ad port trunks. Cisco’s PAgP is not supported by VC. Future versions of VC
may add additional features to enhance this functionality. For LACP to work properly on a Cisco switch, the channel mode must be
set to either Active or Passive. VC can display detailed Ethernet and port trunk statistics by clicking the desired Ethernet module
under Hardware Overview in the left hand tree-view of VCM.
Q7: How do I setup a cluster heartbeat network in Virtual Connect?
A7: Create a vNet in VC and do not assign a VC uplink port to it. Next, assign a “heartbeat” NIC from each blade in the cluster
to this vNet. All heartbeat traffic will be contained within the vNet and will not be transmitted outside of the enclosure.
Q8: I need more than 16 VC uplinks. If I add more VC Ethernet modules to add more uplinks, am I required to use additional NICs
on my servers?
A8: No, you can add more VC Ethernet modules, stack them with the other VC Ethernet modules and just use the uplink ports. Any
VC uplink on any VC Ethernet module can be used to provide external connectivity for any downlink on any VC Ethernet module.
Q9: I need more NICs on my blade servers. If I add more VC Ethernet modules to add more downlink ports, am I required to use
additional VC uplinks ports to provide connectivity for these new downlink ports?
A9: No, you can add more VC Ethernet modules, stack them with the other VC Ethernet modules and the new downlink ports can be
configured to use the uplinks on the existing VC-Enet modules. Any VC uplink on any VC Ethernet module can be used to provide
external connectivity for any downlink on any VC Ethernet module.