Filter
Top Products
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.
You can configure VLT nodes, which function as RP, as Multicast Source Discovery Protocol (MSDP)
peers in different domains. However, you cannot configure 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, configure 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 configure VLT
nodes as RPs.
Backup RP is not supported if the VLT peer that functions as the RP is statically configured. With static RP
configuration, 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 configured through the
multicast peer-routing timeout value command. You can configure an optimal time for a VLT
node to retain synced multicast routes or synced multicast outgoing interface (OIF), after a VLT peer
node failure, through the
multicast peer-routing-timeout command in VLT DOMAIN mode. Using
the bootstrap router (BSR) mechanism, both the VLT nodes in a VLT domain can be configured 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 to be achieved by the PIM BSR protocol.
Configuring VLAN-Stack over VLT
To configure VLAN-stack over VLT, follow these steps.
1. Configure the VLT LAG as VLAN-stack access or trunk mode on both the peers.
INTERFACE PORT-CHANNEL mode
Virtual Link Trunking (VLT)
989