Users Guide

If all ports in the VLT interconnect fail, or if the messaging infrastructure fails to communicate across the interconnect trunk,
the VLT management system uses the backup link interface to determine whether the failure is a link-level failure or whether
the remote peer has failed entirely. If the remote peer is still alive (heartbeat messages are still being received), the VLT
secondary switch disables its VLT port channels. If keepalive messages from the peer are not being received, the peer
continues to forward trac, assuming that it is the last device available in the network. In either case, after recovery of the
peer link or reestablishment of message forwarding across the interconnect trunk, the two VLT peers resynchronize any MAC
addresses learned while communication was interrupted and the VLT system continues normal data forwarding.
If the primary chassis fails, the secondary chassis takes on the operational role of the primary.
The SNMP MIB reports VLT statistics.
RSTP and VLT
VLT provides loop-free redundant topologies and does not require RSTP.
RSTP can cause temporary port state blocking and may cause topology changes after link or node failures. Spanning tree topology
changes are distributed to the entire layer 2 network, which can cause a network-wide ush of learned MAC and ARP addresses,
requiring these addresses to be re-learned. However, enabling RSTP can detect potential loops nonsystem issues can cause, such as
cabling errors or incorrect congurations. To minimize possible topology changes after link or node failure, RSTP is useful for potential
loop detection. Congure RSTP using the following specications.
The following recommendations help you avoid these issues and the associated trac loss caused by using RSTP when you enable
VLT on both VLT peers:
Congure any ports at the edge of the spanning tree’s operating domain as edge ports, which are directly connected to end
stations or server racks. Disable RSTP on ports connected directly to Layer 3-only routers not running STP or congure them as
edge ports.
Ensure that the primary VLT node is the root bridge and the secondary VLT peer node has the second-best bridge ID in the
network. If the primary VLT peer node fails, the secondary VLT peer node becomes the root bridge, avoiding problems with
spanning tree port state changes that occur when a VLT node fails or recovers.
Even with this conguration, if the node has non-VLT ports using RSTP that you did not congure as edge ports and are
connected to other Layer 2 switches, spanning tree topology changes are still detected after VLT node recovery. To avoid this
scenario, ensure that you congure any non-VLT ports as edge ports or disable RSTP.
VLT Bandwidth Monitoring
When bandwidth usage of the VLTi (ICL) exceeds 80%, a syslog error message (shown in the following message) and an SNMP trap
are generated.
%STKUNIT0-M:CP %VLTMGR-6-VLT-LAG-ICL: Overall Bandwidth utilization of VLT-ICL-LAG (port-
channel 25)
crosses threshold. Bandwidth usage (80 )
When the bandwidth usage drops below the 80% threshold, the system generates another syslog message (shown in the following
message) and an SNMP trap.
%STKUNIT0-M:CP %VLTMGR-6-VLT-LAG-ICL: Overall Bandwidth utilization of VLT-ICL-LAG (port-
channel 25)
reaches below threshold. Bandwidth usage (74 )VLT show remote port channel status
VLT and Stacking
You cannot enable stacking S5000 units with VLT.
If you enable stacking on a unit on which you want to enable VLT, rst remove the unit from the existing stack. For information about
how to remove a unit from a stack, refer to Remove a Switch from a Stack. After you remove the unit, you can congure VLT on the
unit.
VLT and IGMP Snooping
When conguring IGMP Snooping with VLT, ensure the congurations on both sides of the VLT trunk are identical to get the same
behavior on both sides of the trunk.
When you congure IGMP snooping on a VLT node, the dynamically learned groups and multicast router ports are automatically
learned on the VLT peer node.
922
Virtual Link Trunking (VLT)