Addendum

Whenever a change occurs in the VLAN mode of one of the peers, this modification in setting is
synchronized with the other peers and depending on the validation mechanism that is initiated for MAC
synchronization of VLT peers, MAC addresses learned on a particular VLAN are synchronized and made
consistent to the other peers or MAC addresses synchronized from the other peers on the same VLAN
are deleted. This method of processing occurs when the PVLAN mode of VLT LAGs is modified.
Because the VLTi link is only a member of symmetric VLT PVLANs, MAC synchronization takes place
directly based on the membership of the VLTi link in a VLAN and the VLT LAG mode.
PVLAN Operations When One VLT Peer is Down
When a VLT port moves to the Admin or Operationally Down states on only one of the VLT nodes, the
VLT Lag is still considered to be up. All the PVLAN MAC entries that correspond to the operationally down
VLT LAG are maintained as synchronized entries in the device. These MAC entries are removed when the
peer VLT LAG also becomes inactive or a change in PVLAN configuration occurs, which might cause
inconsistency.
PVLAN Operations When a VLT Peer is Restarted
When the VLT peer node is rebooted, the VLAN membership of the VLTi link is preserved and when the
peer node comes back online, a verification is performed with the newly received PVLAN configuration
from the peer. If any differences are identified, the VLTi link is either added or removed from the VLAN.
When the peer node restarts and returns online, all the PVLAN configurations are exchanged across the
peers. Based on the information received from the peer, a bulk synchronization of MAc addresses that
belong to spanned PVLANs is performed.
During the booting phase or when the ICL link attempts come up, a system logging message is recorded
if VLT PVLAN mismatches, PVLAN mode mismatches, PVLAN association mismatches, or PVLAN port
mode mismatches occur. Also, you can view these discrepancies if any that occur by using the show vlt
mismatch command.
Interoperation of VLT Nodes in a PVLAN with ARP Requests
When an ARP request is received, the IP stack performs the following operations:
If the VLAN on which the ARP request is received is a secondary VLAN (community or isolated VLAN), if
Layer 3 communication between secondary VLANs in a private VLAN is enabled by using the ip local-
proxy-arp command in INTERFACE VLAN configuration mode, and if the ARP request is not received on
the ICL, the ARP reply is sent with the MAC address of the primary VLAN. Additionally, an ARP request
packet is originated on the primary VLAN for the intended destination IP address.
The ARP request received on ICLs are not proxied, even if they are received with a secondary VLAN tag,
because the node from which the ARP request was forwarded would have replied with its MAC address
and the current node discards the ARP request in such a case.
Scenarios for VLAN Membership and MAC Synchrnoization With VLT Nodes
in PVLAN
The following table illustrates the manner in which association of VLTi link and PVLANs, and MAC
synchronization of VLT nodes in a PVLAN is performed for various modes of operations of the VLT peers:
Virtual Link Trunking (VLT)
265