Users Guide

VLT Nodes as Rendezvous Points for Multicast
Resiliency
You can congure 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 trac 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 trac destined for the multicast
group.
To enable an explicit multicast routing table synchronization method for VLT nodes, you can congure 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 trac from
the same incoming interface.
You can congure a VLT node to be an RP using the ip pim rp-address command in Global Conguration mode. When you congure
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 trac 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 trac from the source to the
receiver.
You can congure VLT nodes, which function as RP, as Multicast source discovery protocol (MSDP) peers in dierent domains. However,
you cannot congure the VLT peers as MSDP peers in the same VLT domain. In such instances, the VLT peer does not support the RP
functionality.
If the same source or RP can be accessed over both a VLT and a non-VLT VLAN, congure better metrics for the VLT VLANs. Otherwise,
it is possible that one VLT node chooses a non-VLT VLAN (if the path through the VLT VLAN was not available when the route was
learned) and another VLT node selects a VLT VLAN. Such a scenario can cause duplication of packets. ECMP is not supported when you
congure VLT nodes as RPs.
Backup RP is not supported if the VLT peer that functions as the RP is statically congured. With static RP conguration, if the RP
reboots, it can handle new clients only after it comes back online. Until the RP returns to the active state, the VLT peer forwards the
packets for the already logged-in clients. To enable the VLT peer node to retain the synchronized multicast routes or synchronized multicast
outgoing interface (OIF) maps after a peer node failure, use the timeout value that you congured using the multicast peer-
routing timeout
value command. You can congure an optimal time for a VLT node to retain synced multicast routes or synced
multicast outgoing interface (OIF), after a VLT peer node failure, using the multicast peer-routing-timeout command in VLT
DOMAIN mode. Using the bootstrap router (BSR) mechanism, you can congure both the VLT nodes in a VLT domain as the candidate RP
for the same group range. When an RP fails, the VLT peer automatically takes over the role of the RP. This phenomenon enables resiliency
by the PIM BSR protocol.
Conguring VLAN-Stack over VLT
To congure VLAN-stack over VLT, follow these steps.
1 Congure the VLT LAG as VLAN-Stack access or Trunk mode on both the peers.
INTERFACE PORT-CHANNEL mode
vlan-stack {access | trunk}
2 Congure VLAN as VLAN-stack compatible on both the peers.
INTERFACE VLAN mode
vlan-stack compatible
3 Add the VLT LAG as a member to the VLAN-stack on both the peers.
INTERFACE VLAN mode
member port-channel port—channel ID
858
Virtual Link Trunking (VLT)