Reference Guide

If the VLTi link fails, the status of the remote VLT Primary Peer is checked using the backup link. If the remote VLT Primary Peer is
available, the Secondary Peer disables all VLT ports to prevent loops.
If all ports in the VLTi link fail or if the communication between VLTi links fails, VLT checks the backup link to determine the cause of
the failure. If the failed peer can still transmit heartbeat messages, the Secondary Peer disables all VLT member ports and any Layer
3 interfaces attached to the VLAN associated with the VLT domain. If heartbeat messages are not received, the Secondary Peer
forwards trac assumes the role of the Primary Peer. If the original Primary Peer is restored, the VLT peer reassigned as the Primary
Peer retains this role and the other peer must be reassigned as a Secondary Peer. Peer role changes are reported as SNMP traps.
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 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.
VLT Port Delayed Restoration
When a VLT node boots up, if the VLT ports have been previously saved in the start-up conguration, they are not immediately
enabled.
To ensure MAC and ARP entries from the VLT per node are downloaded to the newly enabled VLT node, the system allows time for
the VLT ports on the new node to be enabled and begin receiving trac.
The delay-restore feature waits for all saved congurations to be applied, then starts a congurable timer. After the timer
expires, the VLT ports are enabled one-by-one in a controlled manner. The delay between bringing up each VLT port-channel is
proportional to the number of physical members in the port-channel. The default is 90 seconds.
If you enable IGMP snooping, IGMP queries are also sent out on the VLT ports at this time allowing any receivers to respond to the
queries and update the multicast table on the new node.
This delay in bringing up the VLT ports also applies when the VLTi link recovers from a failure that caused the VLT ports on the
secondary VLT peer node to be disabled.
Non-VLT ARP Sync
In the Dell Networking OS version 9.2(0.0), ARP entries (including ND entries) learned on other ports are synced with the VLT peer
to support station move scenarios.
Prior to Dell Networking OS version 9.2.(0.0), only ARP entries learned on VLT ports were synced between peers.
Additionally, ARP entries resulting from station movements from VLT to non-VLT ports or to dierent non-VLT ports are learned on
the non-VLT port and synced with the peer node. The peer node is updated to use the new non-VLT port.
NOTE: ARP entries learned on non-VLT, non-spanned VLANs are not synced with VLT peers.
PMUX Mode of the IO Aggregator
207