Tag :: PIM

Bidirectional Protocol Independent Multicast (PIM) allows routers to build trees to deliver multicast traffic from sources to receivers. It is a variant of sparse-mode PIM that efficiently addresses the use case where receivers for a multicast group are also sources for that group. While sparse-mode PIM builds shared trees and source-specific trees, bidirectional PIM only builds shared trees. A shared tree for a multicast group is rooted at the Rendezvous Point (RP) for that group. The RP for a bidirectional group is an IP address, which may or may not be real, but is reachable via all routers in the multicast domain. There may be multiple RPs in a multicast domain.

As Ethernet technologies made their way into the Metropolitan Area Networks (MAN) and the Wide Area Networks (WAN), from the conventional enterprise level usage, they are now widely being used by service providers to provide end-to-end connectivity to customers. Such service provider networks are typically spread across large geographical areas. Additionally, the service providers themselves may be relying on certain internet backbone providers, referred to as “operators”, to provide connectivity in case the geographical area to be covered is too huge. This mode of operation makes the task of Operations, Administration and Maintenance (OAM) of such networks to be far more challenging, and the ability of service providers to respond to such network faults swiftly directly impacts their competitiveness.

4.22.1F introduces support for ip address virtual for PIM and IGMP in MLAG and Vxlan. On a VLAN, the same IP address can

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.

Multicast VRF leak allows multicast traffic from a sender in one domain or VRF to be forwarded to a different domain or VRF, in which the receivers are connected. In the rest of this document, the VRF to which the multicast sender belongs to is referred to as the “source VRF” and the VRF that the multicast receiver belongs to is referred to as the “receiver VRF”.

This feature allows PIMv4 to work with Multiprotocol BGP (MP-BGP), where IPv4 prefix routes are reachable via IPv6 next-hops.

The purpose of this feature is to mitigate multicast traffic loss when a switch that is using PIM sparse mode as its multicast routing protocol is going under maintenance.

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

In a modular system there are two supervisors which ensures redundancy in event of Hardware and software failures. At any given time, only one supervisor is in control (managing most hardware, including all the linecards). We call it the active supervisor. The other supervisor is called standby supervisor, which serves as a backup in case the active supervisor fails. Stateful switchover is the transition when the standby supervisor takes over control of the entire system from the active supervisor (and therefore becomes the new active). This document describes PIM SSO works and its limitations.

PIM Static Source Discovery (SSD) is a feature implemented as part of PIM-SM. Familiarity with setting up and configuring PIM-SM (Sparse Mode) and PIM-SSM (Source-Specific Multicast) is assumed.

PIM Reverse Path Forwarding (RPF) is a mechanism that allows the multicast routers to send the PIM control packets to the upstream routers via the shortest path to form the RP/Source Tree.

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.