Reference Guide

Dell Networking strongly recommends that the VLTi (VLT interconnect) be a static LAG and that you disable LACP on the
VLTi.
Ensure that the spanning tree root bridge is at the Aggregation layer. If you enable RSTP on the VLT device, refer to RSTP
and VLT for guidelines to avoid traffic loss.
If you reboot both VLT peers in BMP mode and the VLT LAGs are static, the DHCP server reply to the DHCP discover offer
may not be forwarded by the ToR to the correct node. To avoid this scenario, configure the VLT LAGs to the ToR and the
ToR port channel to the VLT peers with LACP. If supported by the ToR, enable the lacp-ungroup feature on the ToR
using the lacp ungroup member-independent port-channel command.
If the lacp-ungroup feature is not supported on the ToR, reboot the VLT peers one at a time. After rebooting, verify that
VLTi (ICL) is active before attempting DHCP connectivity.
When you enable IGMP snooping on the VLT peers, ensure the value of the delay-restore command is not less than the
query interval.
When you enable Layer 3 routing protocols on VLT peers, make sure the delay-restore timer is set to a value that allows
sufficient time for all routes to establish adjacency and exchange all the L3 routes between the VLT peers before you enable
the VLT ports.
Only use the lacp ungroup member-independent command if the system connects to nodes using bare metal
provisioning (BMP) to upgrade or boot from the network.
Ensure that you configure all port channels where LACP ungroup is applicable as hybrid ports and as untagged members of a
VLAN. BMP uses untagged dynamic host configuration protocol (DHCP) packets to communicate with the DHCP server.
If the DHCP server is located on the ToR and the VLTi (ICL) is down due to a failed link when a VLT node is rebooted in
BMP mode, it is not able to reach the DHCP server, resulting in BMP failure.
If the source is connected to an orphan (non-spanned, non-VLT) port in a VLT peer, the receiver is connected to a VLT
(spanned) port-channel, and the VLT port-channel link between the VLT peer connected to the source and TOR is down,
traffic is duplicated due to route inconsistency between peers. To avoid this scenario, Dell Networking recommends
configuring both the source and the receiver on a spanned VLT VLAN.
After you enter the clear arp command on a Z9500 configured as the primary VLT peer switch, an ARP request destined
for the secondary VLT peer that arrives from a host and is tunneled through the primary peer updates the ARP entry in the
Route Processor (RP) on the primary peer. However, the same ARP request packet is dropped on the Control Processor
(CP) because it is not destined to the primary peer and the CP has no corresponding ARP entry that can be refreshed with
this packet. As a result, there is an ARP entry mismatch in the RP and CP tables. There is no impact on switch behavior.
Bulk synchronization happens only for global IPv6 Neighbors; link-local neighbor entries are not synced.
If all of the following conditions are true, MAC addresses may not be synced correctly:
VLT peers use VLT interconnect (VLTi)
Sticky MAC is enabled on an orphan port in the primary or secondary peer
MACs are currently inactive
If this scenario occurs, use the clear mac-address-table sticky all command on the primary or secondary peer
to correctly sync the MAC addresses.
If static ARP is enabled on only one VLT peer, entries may be overwritten during bulk sync.
Configuration Notes
When you configure VLT, the following conditions apply.
VLT domain
A VLT domain supports two chassis members, which appear as a single logical device to network access devices
connected to VLT ports through a port channel.
A VLT domain consists of the two core chassis, the interconnect trunk, backup link, and the LAG members connected to
attached devices.
Each VLT domain has a unique MAC address that you create or VLT creates automatically.
ARP tables are synchronized between the VLT peer nodes.
VLT peer switches operate as separate chassis with independent control and data planes for devices attached on non-
VLT ports.
One chassis in the VLT domain is assigned a primary role; the other chassis takes the secondary role. The primary and
secondary roles are required for scenarios when connectivity between the chassis is lost. VLT assigns the primary chassis
role according to the lowest MAC address. You can configure the primary role.
In a VLT domain, the peer switches must run the same Dell Networking OS software version.
Separately configure each VLT peer switch with the same VLT domain ID and the VLT version. If the system detects
mismatches between VLT peer switches in the VLT domain ID or VLT version, the VLT Interconnect (VLTi) does not
activate. To find the reason for the VLTi being down, use the show vlt statistics command to verify that there
Virtual Link Trunking (VLT)
793