Administrator Guide
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 IPv6
The following features have been enhanced to support IPv6:
● VLT Sync — Entries learned on the VLT interface are synced on both VLT peers.
● Non-VLT Sync — Entries learned on non-VLT interfaces are synced on both VLT peers.
● Tunneling — Control information is associated with tunnel traffic so that the appropriate VLT peer can mirror the ingress
port as the VLT interface rather than pointing to the VLT peer’s VLTi link.
● Statistics and Counters — Statistical and counter information displays IPv6 information when applicable.
● Heartbeat — You can configure an IPv4 or IPv6 address as a backup link destination. You cannot use an IPv4 and an IPv6
address simultaneously.
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.
To change the duration of the configurable timer, use the delay-restore command.
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.
Additional ARP Refresh on VLTi
VLTi (ICL) connects two VLT nodes. Additional ARP refresh on VLTi is enabled by default.
In certain scenarios where ARP refresh occurs frequently within a few seconds as shown in the sample syslog (show
logging), you may want to disable the Additional ARP refresh on VLTi.
DellEMC# show logging
Jun 23 17:53:21.568 UTC %STKUNIT1-M:CP %ARPMGR-6-MAC_CHANGE: IP-4-ADDRMOVE: IP address
10.20.30.40 is moved from MAC address fa:11:22:33:44:55 to MAC address
fa:aa:bb:cc:dd:ee .
Jun 23 17:53:21.466 UTC %STKUNIT1-M:CP %ARPMGR-6-MAC_CHANGE: IP-4-ADDRMOVE: IP address
10.20.30.40 is moved from MAC address fa:aa:bb:cc:dd:ee to MAC address
fa:11:22:33:44:55 .
Jun 23 17:53:20.651 UTC %STKUNIT1-M:CP %ARPMGR-6-MAC_CHANGE: IP-4-ADDRMOVE: IP address
10.20.30.40 is moved from MAC address fa:11:22:33:44:55 to MAC address
fa:aa:bb:cc:dd:ee .
Jun 23 17:53:19.383 UTC %STKUNIT1-M:CP %ARPMGR-6-MAC_CHANGE: IP-4-ADDRMOVE: IP address
10.20.30.40 is moved from MAC address fa:aa:bb:cc:dd:ee to MAC address
fa:11:22:33:44:55 .
Jun 23 17:53:18.426 UTC %STKUNIT1-M:CP %ARPMGR-6-MAC_CHANGE: IP-4-ADDRMOVE: IP address
10.20.30.40 is moved from MAC address fa:11:22:33:44:55 to MAC address
fa:aa:bb:cc:dd:ee .
Jun 23 17:53:18.214 UTC %STKUNIT1-M:CP %ARPMGR-6-MAC_CHANGE: IP-4-ADDRMOVE: IP address
10.20.30.40 is moved from MAC address fa:aa:bb:cc:dd:ee to MAC address
Virtual Link Trunking (VLT)
901