• Unlike PIM Sparse mode and PIM dense mode, the bidirectional PIM feature offers increased multicast scalability and reduced impact on router CPU and memory resources.

• The feature is well suited for many-to-many type of applications because the multicast routing state does not increase as the number of multicast sources increases and the amount of multicast state maintained by the router is reduced significantly compared with the other operating mode.

• Unlike PIM-SM, bidirectional PIM does not switch over to the source tree, and there is no register encapsulation of data from the source to the Rendezvous Point (RP).

• The feature removes the performance cost of maintaining a routing state table for a large number of sources.

• GRE based MVPN bidirectional PIM is not supported.

• MLDP-based MVPN bidirectional PIM is not be supported for Cisco IOS XE Cupertino Release 17.8.1.

• IPv6 traffic is not supported.

• Per OIF statistics is not supported for bidirectional PIM prefixes.

• Additional traffic might be received in some cases after you perform IP PIM bidirectional toggling.

• The maximum TCAM scale for the IPv4 Multicast routing table is 4K. This restriction on scalability is because of the hardware restriction of performing a single RPF check per TCAM entry. The number of DFs and RPAs on the router determine the total TCAM requirements. For a bidirectional prefix, the number of TCAM entries required is equal to “number of DF interfaces (for *, G/m prefix programming)” plus “the number of inherited accept interfaces for the corresponding *, G prefix).

In bidirectional mode, traffic is routed only along a bidirectional shared tree that is rooted at the RP for the group. In bidir-PIM, the IP address of the RP acts as the key to having all routers establish a loop-free spanning tree topology rooted in that IP address. This IP address need not be a router, but can be any unassigned IP address on a network that is reachable throughout the PIM domain. This technique is the preferred configuration method for establishing a redundant RP configuration for bidir-PIM.

Membership in a bidirectional group is signaled by way of explicit Join messages. Traffic from sources is unconditionally sent up the shared tree toward the RP and passed down the tree toward the receivers on each branch of the tree.

The figures below show the difference in state created per router for a unidirectional shared tree and source tree versus a bidirectional shared tree.

For packets that are forwarded downstream from the RP toward receivers, there are no fundamental differences between bidirectional PIM and PIM Sparse mode. Bidirectional PIM deviates substantially from PIM Sparse mode for traffic that is passed from sources upstream toward the RP.

The feature allows traffic to be passed up the shared tree toward the RP. To avoid multicast packet looping, bidirectional PIM introduces a new mechanism called Designated Forwarder (DF) election, which establishes a loop-free SPT rooted at the RP.

On every network segment and point-to-point link, all PIM routers participate in a procedure called Designated Forwarder (DF) election. The procedure selects one router as the DF for every RP of bidirectional groups. This router is responsible for forwarding multicast packets received on that network.

The DF election is based on unicast routing metrics. The router with the most preferred unicast routing metric to the RP becomes the DF. Use of this method ensures that only one copy of every packet will be sent to the RP, even if there are parallel equal-cost paths to the RP.

A DF is selected for every RP of bidirectional groups. As a result, multiple routers may be elected as DF on any network segment, one for each RP. Any particular router may be elected as DF on more than one interface.

On a network that has local receivers, only the router elected as the DF populates the outgoing interface list (olist) upon receiving Internet Group Management Protocol (IGMP) Join messages, and sends (*, G) Join and Leave messages upstream toward the RP. When a downstream router wishes to join the shared tree, the RPF neighbor in the PIM Join and Leave messages is always the DF elected for the interface that lead to the RP.

When a router receives a Join or Leave message, and the router is not the DF for the receiving interface, the message is ignored. Otherwise, the router updates the shared tree in the same way as in sparse mode.

In a network where all routers support bidirectional shared trees, (S, G) Join and Leave messages are ignored. There is also no need to send PIM assert messages because the DF election procedure eliminates parallel downstream paths from any RP. An RP never joins a path back to the source, nor will it send any register stops.

A router creates (*, G) entries only for bidirectional groups. The list of a (*, G) entry includes all the interfaces for which the router has been elected DF and that have received either an IGMP or PIM Join message. If a router is located on a sender-only branch, it will also create a (*, G) state, but the olist will not include any interfaces.

If a packet is received from the RPF interface toward the RP, the packet is forwarded downstream according to the olist of the (*, G) entry. Otherwise, only the router that is the DF for the receiving interface forwards the packet upstream toward the RP; all other routers must discard the packet.

To configure bidirectional PIM:

ip multicast-routing distributed

interface Loopback0
 ip address 2.2.2.2 255.255.255.255
 ip ospf 100 area 0


interface GigabitEthernet0/2/1
 ip address 30.1.1.3 255.255.255.0
 ip pim sparse-mode
 ip ospf 100 area 0
 negotiation auto


interface GigabitEthernet0/2/4
 ip address 100.2.1.2 255.255.255.0
 ip pim sparse-mode
 ip ospf 100 area 0
 negotiation auto
 
router ospf 100
 router-id 2.2.2.2

ip pim bidir-enable
ip pim rp-address 20.1.1.10 BIDIR-GROUPS bidir

ip access-list standard BIDIR-GROUPS
 20 permit 225.0.0.0 0.255.255.255

Starting with Cisco IOS XE Cupertino Release 17.9.1, bidirectional PIM is supported over Multicast Label Distribution Protocol (MLDP)-based MVPN. MLDP helps to transport traffic with label encapsulation over an MPLS core network.

An MVPN profile is configured for the global context or per Virtual Routing/Forwarding (VRF). This feature is only supported on profile 1 MVPN or default MDT - MLDP MP2MP - PIM C-mcast signaling.For more information on MLDP-based MVPN configuration, see MLDP-Based MVPN.

Note	Data MDTs can only be set up for (S,G) (Shortest Path Tree), and not for (*,G) (Shared Tree).