Administrator Guide

When VLT node receives traffic from non-VLT host intended to VLT host, it routes the traffic to VLT interface. If VLT interface
is not operationally up VLT node will route the traffic over ICL.
Non-VLT host to North Bound traffic flow
When VLT node receives traffic from non-VLT host intended to north bound with DMAC as self MAC it routes traffic to next
hop. When VLT node receives traffic from non-VLT host intended to north bound with DMAC as peer MAC it will not forward
the packet to VLT peer instead it will route the traffic to north bound next hop.
North Bound to Non-VLT host traffic flow
When VLT node receives traffic from north bound intended to the non-VLT host, it does neighbor entry lookup and routes
traffic to VLT interface. If traffic reaches wrong VLT peer, it routes the traffic over ICL.
Non-VLT host to Non-VLT host traffic flow
When VLT node receives traffic from non-VLT host intended to the non-VLT host, it does neighbor entry lookup and routes
traffic over ICL interface. If traffic reaches wrong VLT peer, it routes the traffic over ICL.
Router Solicitation
When VLT node receives router Solicitation on VLT interface/non-VLT interface it consumes the packets and will send RA back
on the received interface.
VLT node will drop the RS message if it is received over ICL interface.
Router Advertisement
When VLT node receives router advertisement on VLT interface/non-VLT interface it consumes the packets.
VLT node will drop the RA message if it is received over ICL interface.
Upgrading from Releases That Do Not Support IPv6 Peer Routing
During an upgrade to Release 9.4(0.0) from earlier releases, VLT peers might contain different versions of FTOS. You must
upgrade both the VLT peers to Release 9.4(0.0) to leverage the benefits of IPv6 peer routing.
Station Movement
When a host moves from VLT interface to non-VLT interface or vice versa Neighbor entry is updated and synchronized to VLT
peer. When a host moves from non-VLT interface of VLT node1 to non-VLT interface of VLT node2 neighbor entry is updated
and synchronized to VLT peer.
Configure BFD in VLT Domain
Dell EMC Networking OS supports Bidirectional Forwarding Detection (BFD) to detect communication failures on an interface
that is a part of a VLT link aggregation group (LAG).
In VLT domain, BFD provides high availability path when there are communication failures in any one of the VLT LAG links. The
VLT nodes and top of rack (ToR) use the VLT LAG links to carry the BFD packets. When any one of the VLT LAG links
connected to the ToR is down, the BFD packets reach the VLT primary or secondary using the VLTi (ICL) link.
When VLT peer-routing is enabled, BFD sessions are not established if BFD packets reach the wrong VLT node due to LAG
hashing in TOR. The wrong VLT node must have ARP or IPv6 neighbor discovery entries for VLT peer node's IPv4 or IPv6
address in the forwarding table, to forward the BFD packet to the VLT peer. Since ARP or IPv6 neighbor discovery entries are
bound to expire, it is recommended to add static ARP or IPv6 neighbor discovery entries for the VLT peer node's IPv4 or IPv6
address, to forward the BFD packets to the correct VLT node.
Sample BFD configuration in VLT domain
The following shows the sample configuration of BFD implementation in VLT environment:
1058
Virtual Link Trunking (VLT)