White Papers

Primary and Secondary VLT Peers
Primary and Secondary VLT Peers are supported on the Aggregator.
To prevent issues when connectivity between peers is lost, you can designate Primary and Secondary roles for VLT peers . You
can elect or configure the Primary Peer. By default, the peer with the lowest MAC address is selected as the Primary Peer.
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 traffic 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 configuring IGMP Snooping with VLT, ensure the configurations on both sides of the VLT trunk are identical to get the
same behavior on both sides of the trunk.
When you configure 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 configuration, 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 traffic.
The delay-restore feature waits for all saved configurations to be applied, then starts a configurable 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.
816
PMUX Mode of the IO Aggregator