Tag :: Multicast

The multicast boundary specifies subnets where the source traffic entering an interface is filtered to prevent the creation of mroute states on the interface. The multicast boundary can be specified through one standard ACL. However, when providing multicast services via a range of groups per service, an interface could potentially join arbitrary groups and, hence, need arbitrary combinations of ACL rules.

This document describes how to integrate with Arista Media Control Service(MCS) supported APIs and the EOS releases that they are available in.

This document lists and describes the MCS supported features and the EOS releases that they are available in.

This document describes how to provision, upgrade and troubleshoot Arista’s Media Control Service (both servers and clients). The Media Control Service provides a deterministic high-performance service with an easy to use API interface to manage and monitor real-time broadcast workflows in IP networks. It allows fast programming of static multicast routes and IGMP snooping entries across L2/L3 interfaces with real-time tallies for feedback.

Source port filtering is enabled by default to prevent traffic from egressing out the same interface it ingressed on.

In network deployments, where border leaf or Superspine act as PEG and it is in the transit path to other multicast VTEPs, the multicast stream will not pass since the border leaf will decapsulate the packet even if it doesn't have a receiver. This transit node is called the Bud Node. The device should be able to send decapsulated packets to any local receivers as well as send the encapsulated packets to other VTEPs.

EOS currently supports EVPN Multicast by setting up PIM tunnels in the underlay with VXLAN as the transport. While this is an efficient delivery mechanism, it requires PIM to be deployed in the underlay. In certain cases, the overheads of provisioning/maintaining the multicast routers and the multicast routing state in the underlay may be significant. To support such scenarios, Ingress Replication (IR) or Head-End Replication (HER) can be used in the underlay to distribute overlay multicast traffic.

Fastdrop static is a feature that allows the static multicast routing agent to respond to cache miss messages and

IPv6 multicast routing protocols are used to distribute IPv6 datagrams to one or more recipients. IPv6 PIM builds and maintains multicast routing using reverse path forwarding (RPF) based on the unicast routing table. IPv6 PIM is protocol-independent and can use routing tables consisting of OSPFv3, IPv6 BGP or static routes, for RPF lookup. MLD is used to discover multicast hosts and maintain group membership on a directly attached link.

The ip address virtual command is generally used to conserve IP addresses in VXLAN deployments and can be used to provide an Anycast gateway. On a VLAN, the same IP address can be configured using this command on multiple VTEPS or on both MLAG devices. Release 4.22.1F introduced [ip address virtual support for PIM and IGMP]. Using that solution, users are required to configure pim ipv4 local-interface on the VLAN interface. PIM and IGMP then borrow the IP address from the local interface specified. Using this configuration, IGMP skips subnet checks for received control messages.

This solution allows delivery of IPv6 multicast traffic in an IP-VRF using an IPv4 multicast in the underlay network. The protocol used to build multicast trees in the underlay network is PIM Sparse Mode.

This feature provides support for packet and byte ingress counters for IPv6 multicast routes.

This solution allows delivery of both IPv4 and IPv6 multicast traffic in an IP-VRF using an IPv6 multicast in the underlay network. The protocol used to build multicast trees in the underlay network is IPv6 PIM-SSM.

This feature adds support for PIM SSM (Source Specific Multicast) for IPv6 Multicast Routing on platforms listed

This feature allows transport of multicast frames to an endpoint across an IP network by tunneling them through MPLSoGRE or MPLSoGUE. The tunneling of multicast frames is achieved with a traffic policy applied on the ingress interface which will match on all packets destined to a multicast IP address and redirect that traffic to a MoG nexthop group. The traffic policy will also specify “forced routing” in order to set the fwd_layer_index to 1 so that the L2 header is removed before encapsulation.

This solution allows the delivery of customer BUM (Broadcast, Unknown unicast and Multicast) traffic in a VLAN using

In networks where source and destination of multicast traffic all reside in the same VLAN, IPv6 multicast traffic is flooded to all ports in the VLAN by default. MLD snooping can be enabled to optimize the inefficient transmission, pruning out ports with no receivers.

This solution optimizes the delivery of multicast to a VLAN over an Ethernet VPN (EVPN) network. Without this solution IPv6 multicast traffic in a VLAN is flooded to all Provider Edge(PE) devices which contain the VLAN.

[L2 EVPN] and  [Multicast EVPN IRB] solutions allow for the delivery of customer BUM (Broadcast, Unknown unicast

This solution allows delivery of multicast traffic in an IP-VRF using multicast in the underlay network. It builds on top of L2-EVPN, adding support for L3 VPNs and Integrated Routing and Bridging (IRB). The protocol used to build multicast trees in the underlay network is PIM Sparse Mode.

Multicast EVPN IRB solution allows for the delivery of customer BUM (Broadcast, Unknown unicast and Multicast) traffic in L3VPNs using multicast in the underlay network. This document contains only partial information that is new or different for the Multicast EVPN Multiple Underlay Groups solution.

[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 feature provides multipath router id, a new multipath mode to control the behavior of RPF selection. In the

Multipath color is a new multicast multipath mode for controlling PIM RPF selection. In the default multipath

The solution described in this document allows multicast traffic arriving on a VRF interface on a Provider’s Edge (PE) router to be delivered to Customer’s Edge (CE) routers with downstream receivers in the same VPN.

The PIM routing protocol builds multicast routing state based on control packets and multicast data events. In our

PIM External Gateways (PEGs) allow an EVPN overlay multicast network to interface with an external PIM domain. They can be used to interconnect two data centers using an external PIM domain in between them.

In a Mlag setup with Pim SSM, one peer becomes the DR for a layer 3 interface and is responsible for routing multicast

RSVP-TE P2MP LER adds ingress and egress support for Point-to-Multipoint (P2MP) LSPs to be used in Multicast Virtual Private Network (MVPN) as an extension to the LSR support which adds transit support.

RSVP-TE P2MP LSR adds transit support for Point-to-Multipoint (P2MP) LSPs. Specifically the feature adds protocol support for the transit role as described in RFC 4875.

The IPv6 multicast route counters count packets and bytes per group, source and vrf . Every IPv6

The multicast route counters count packets and bytes per group, source and vrf. Every multicast route will be counted when the feature is turned on if there are sufficient hardware counter resources available. 

Multicast NAT is a feature that performs NAT translations on multicast traffic. It can be configured under SVIs,

In order to support PIM/IPv4 multicast routing on EOS switches with Broadcom Tomahawk4 ASICs, multicast support using ALPM is required. This works in both 3-level Algorithmic Longest Prefix Match (ALPM) capabilities and 2-level ALPM.

PimReg Filtering provides the ability to prevent unauthorized sources and groups from registering with a rendezvous-point (RP) router.  This is accomplished by adding the unauthorized source/group to a standard access-list. When the ACL is used on the RP, the RP inspects the source information on the PIM Register packet for a match before accepting/dropping the message.  

PimReg DR Filtering provides the ability to prevent unauthorized unicast addresses from registering with a rendezvous-point (RP) router.  This is accomplished by adding the unauthorized unicast address to a standard access-list. When the ACL is used on the RP, the RP inspects the source information on the PIM Register packet for a match before accepting/dropping the message. 

This feature introduces hardware forwarding support of IPv4 multicast traffic over IPv4 GRE tunnel interfaces in Arista Switches. Multicast source traffic can reach the receivers which are separated by an IP cloud which is not configured for IP multicast routing by utilizing a GRE tunnel.