Users Guide

Tunneling IPv6 ND in a VLT Domain
Tunneling an NA packet from one VLT node to its peer is required because an NA may reach the wrong VLT
node instead of arriving at the destined VLT node. This may occur because of LAG hashing at the ToR switch.
The tunneled NA carries some control information along with it so that the appropriate VLT node can mimic
the ingress port as the VLT interface rather than pointing to VLT node’s interconnecting link (ICL link).
The overall tunneling process involves the VLT nodes that are connected from the ToR through a LAG. The
following illustration is a basic VLT setup, which describes the communication between VLT nodes to tunnel
the NA from one VLT node to its peer.
NA messages can be sent in two scenarios:
• NA messages are almost always sent in response to an NS message from a node. In this case, the
solicited NA has the destination address field set to the unicast MAC address of the initial NS sender. This
solicited NA must be tunneled when they reach the wrong peer.
• Sometimes NA messages are sent by a node when its link-layer address changes. This NA message is
sent as an unsolicited NA to advertise its new address and the destination address field is set to the link-
local scope of all-nodes multicast address. This unsolicited NA packet does not have to be tunneled.
Consider a sample scenario in which two VLT nodes, Unit1 and Unit2, are connected in a VLT domain using
an ICL or VLTi link. To the south of the VLT domain, Unit1 and Unit2 are connected to a ToR switch named
Node B. Also, Unit1 is connected to another node, Node A, and Unit2 is linked to a node, Node C. When an
NS traverses from Unit2 to Node B(ToR) and a corresponding NA reaches Unit1 because of LAG hashing, this
NA is tunneled to Unit 2 along with some control information. The control information present in the
Virtual Link Trunking (VLT) 1082