• Author : Swati Patel

 
 

Multicast EVPN MLAG

Description [L2-EVPN] and  [Multicast EVPN IRB] solutions allow for the delivery of customer BUM (Broadcast, Unknown unicast and Multicast) traffic in a L2VPN and L3VPNs respectively using multicast in the underlay network. This document describes the solution to support [L2-EVPN] and  [Multicast EVPN IRB] with MLAG. This document contains only partial information that is new or different for the Multicast EVPN MLAG solution. Please refer to [L2-EVPN] and  [Multicast EVPN IRB] documents first before continuing with this document. Multicast EVPN MLAG Traffic Receivers IGMP reports from the CE may arrive at any one of the MLAG peers. Both the MLAG...
Continue reading →

Multicast EVPN All-Active Multihoming

Description [L2-EVPN] and  [Multicast EVPN IRB] solutions allow for the delivery of customer BUM (Broadcast, Unknown unicast and Multicast) traffic in a VLAN and L3VPNs respectively using multicast in the underlay network. This document describes the solution to support all-active multihoming for customer multicast traffic as described in [IGMP PROXY] . More information about VXLAN EVPN all-active multihoming may be found in [VXLAN EVPN All-Active Multihoming]. Multicast All-Active Multihoming IGMP PROXY support As described in [IGMP PROXY], in an all-active redundancy mode, IGMP reports from the CE may arrive at any one of the multihomed peers. The multihomed peer which...
Continue reading →

Pim SSM IPV4 Non-DR OIF Installation for Fast Failover

Description In a Mlag setup with Pim SSM, one peer becomes the DR for a layer 3 interface and is responsible for routing multicast traffic on that interface. If this DR fails, the other peer, who was originally non-DR but becomes the new DR, may need to establish  SPT trees to get the multicast traffic or at the very least, add interfaces to OIF list of many multicast routes. This can be very disruptive to multicast traffic flow if there are thousands of routes.  This feature “Pim SSM Non-DR OIF Installation” helps to reduce convergence times and decrease traffic loss...
Continue reading →

Multicast Listener Discovery (MLD)

The MLD protocol is the IPv6 equivalent of IGMP for IPv4. Multicast routers use MLD to find out about multicast receivers on their local networks. A MLD agent periodically queries for listeners interest in receiving IPv6 multicast data traffic using MLD Query messages. Listeners send MLD Report and MLD Done messages. MLD Reports contain multicast addresses and potentially source addresses that interests the listeners. A MLD agent keeps track of these multicast addresses and source addresses for its attached links on which MLD is enabled. Since only one router needs to send queries, a querier election takes place to select...
Continue reading →

Follow

Get every new post on this blog delivered to your Inbox.

Join other followers: