Administrator Guide

Table Of Contents
two VLT nodes. Assume that the VLAN 100 IP address in node 1 is 10.1.1.1/24 and VLAN 100 IP address in node 2 is 20.1.1.2/24.
In this case, if the ARP request for 20.1.1.1 reaches node 1, node 1 will not perform the ARP request for 20.1.1.2. Proxy ARP
is supported only for the IP address belongs to the received interface IP network. Proxy ARP is not supported if the ARP
requested IP address is different from the received interface IP subnet. For example, if VLAN 100 and 200 are configured on
the VLT peers, and if the VLAN 100 IP address is configured as 10.1.1.0/24 and the VLAN 200 IP address is configured as
20.1.1.0/24, the proxy ARP is not performed if the VLT node receives an ARP request for 20.1.1.0/24 on VLAN 100.
Working of Proxy ARP for VLT Peer Nodes
Proxy ARP is enabled only when peer routing is enabled on both the VLT peers. If peer routing is disabled on one of the
VLT peers, proxy ARP is not performed when the ICL link goes down. Proxy ARP is performed only when the VLT peer's
MAC address is installed in the database. Proxy ARP is stopped when the VLT peer's MAC address is removed from the ARP
database because of the peer routing timer expiry. The source hardware address in the ARP response contains the VLT peer
MAC address. Proxy ARP is supported for both unicast and broadcast ARP requests. Control packets, other than ARP requests
destined for the VLT peers that reach the undesired and incorrect VLT node, are dropped if the ICL link is down. Further
processing is not done on these control packets. The VLT node does not perform any action if it receives gratuitous ARP
requests for the VLT peer IP address. Proxy ARP is also supported on secondary VLANs. When the ICL link or peer is down, and
the ARP request for a private VLAN IP address reaches the wrong peer, then the wrong peer responds to the ARP request with
the peer MAC address.
The IP address of the VLT node VLAN interface is synchronized with the VLT peer over ICL when the VLT peers are
up. Whenever an IP address is added or deleted, this updated information is synchronized with the VLT peer. IP address
synchronization occurs regardless of the VLAN administrative state. IP address addition and deletion serve as the trigger events
for synchronization. When a VLAN state is down, the VLT peer might perform a proxy ARP operation for the IP addresses of
that VLAN interface.
VLT nodes start performing Proxy ARP when the ICL link goes down. When the VLT peer comes up, proxy ARP will be stopped
for the peer VLT IP addresses. When the peer node is rebooted, the IP address synchronized with the peer is not flushed. Peer
down events cause the proxy ARP to commence.
When a VLT node detects peer up, it will not perform proxy ARP for the peer IP addresses. IP address synchronization occurs
again between the VLT peers.
Proxy ARP is enabled only if peer routing is enabled on both the VLT peers. If you disable peer routing by using the no
peer-routingcommand in VLT DOMAIN node, a notification is sent to the VLT peer to disable the proxy ARP. If peer routing
is disabled when ICL link is down, a notification is not sent to the VLT peer and in such a case, the VLT peer does not disable the
proxy ARP operation.
When the VLT domain is removed on one of the VLT nodes, the peer routing configuration removal will be notified to the peer.
In this case VLT peer node disables the proxy ARP. When the ICL link is removed on one of the VLT nodes by using the no
peer-link command, the ICL down event is triggered on the other VLT node, which in turn starts the proxy ARP application.
The VLT node, where the ICL link is deleted, flushes the peer IP addresses and does not perform proxy ARP for the additional
LAG hashed ARP requests.
VLT Nodes as Rendezvous Points for Multicast
Resiliency
You can configure virtual link trunking (VLT) peer nodes as rendezvous points (RPs) in a Protocol Independent Multicast (PIM)
domain.
PIM uses a VLT node as the RP to distribute multicast traffic to a multicast group. Messages to join the multicast group (Join
messages) and data are sent towards the RP, so that receivers can discover who the senders are and begin receiving traffic
destined for the multicast group.
To enable an explicit multicast routing table synchronization method for VLT nodes, you can configure VLT nodes as RPs.
Multicast routing needs to identify the incoming interface for each route. The PIM running on both VLT peers enables both the
peers to obtain traffic from the same incoming interface.
You can configure a VLT node to be an RP through the ip pim rp-address command in Global Configuration mode.
When you configure a VLT node as an RP, the (*, G) routes that are synchronized from the VLT peers are ignored and
not downloaded to the device. For the (S, G) routes that are synchronized from the VLT peer, after the RP starts receiving
multicast traffic via these routes, these (S, G) routes are considered valid and are downloaded to the device. Only (S, G) routes
are used to forward the multicast traffic from the source to the receiver.
746
Virtual Link Trunking (VLT)