Multicast Bidirectional PIM

Hi Laz,

I figured it out.

In the lab’s requirements it says,

“Now let’s enable PIM sparse mode on all interfaces:”

The above statement is what led others to put bidir on all five routers.
The above statement was also misunderstood as “put sparse-mode on ALL routers too.”

A better way to say what Rene meant is,
Now let’s enable PIM sparse mode on all of the interfaces found on routers R1-R3 only.
*Remember that (R4&R5) are simulated hosts.*

My mistake, like my predecessors was the assumption that ip pim sparse-mode belongs on ALL interfaces of ALL routers as mentioned above without the limiting factor that Rene only meant routers one through three only.

Hello Jay

It’s great that you found the solution! And yes I can understand how that statement can be misleading. I was reading it through as well, and the question did pop up in my mind of whether or not R4 and R5 should also be configured like that, but I dismissed it cause I realized that R4 and R5 are acting as hosts. Not everyone will realize this however.

I will let @ReneMolenaar know to take a look and clarify this statement.

I’m glad it worked out!


1 Like

What would be the pros and cons of bidirectional pim v pim sparse mode ?
Would there be any specific use case for each or would both get the job done at the end of the day ?

Hello Sean

As stated in the lesson, bidirectional PIM is more efficient for situations where you have many multicast sources and receivers, whereas PIM sparse mode is more efficient for few sources and many receivers. When we have many sources and destinations, then PIM sparse mode is ineffiecnet because:

  • the RP builds both (*,G) and (S,G) entries
  • an SPT is built towards each and every source
  • traffic only flows down the shared tree
  • PIM register/register-stop mechanisms are used to register sources to the RP

Bidirectional PIM on the other hand:

  • (S,G) entries are not built and the (*,G) entry is allowed for the shared tree
  • an SPT is never built towards the sources
  • traffic can move both up and down the shared tree
  • no PIM register/ register-stop mechanisms are used to register sources to the RP, as each source can start and stop whenever it likes (there is no way for the RP to tell a source to stop sending multicast traffic)

These characteristics make bidirectional PIM more efficient for use where you have many sources and many receivers. But you can also see that the same characteristics make sparse-mode more efficient for situations where you have only a few sources.

Yes, both would get the job done, however, you may find your network struggling to cope if you have too many sources and you are using sparse mode. Ideally, for situations where you have few sources and many receivers (broadcast IPTV for example), sparse mode should be used. For situations such as videoconferencing, you should use bidirectional mode.

I hope this has been helpful!


1 Like

Thank you for this excellent answer.

1 Like

Can you provide any information on RP Address as per the RFC’s for BiDir.
In particular rfc 5015
I can’t find any Cisco documentation on how to configure this RPA if it is virtual and not assigned to an interface or loopback of a device.

Rendezvous Point Address (RPA)
An RPA is an address that is used as the root of the distribution
tree for a range of multicast groups. The RPA must be routable
from all routers in the PIM domain. The RPA does not need to
correspond to an address for an interface of a real router. In
this respect, BIDIR-PIM differs from PIM-SM, which requires an
actual router to be configured as the Rendezvous Point (RP). Join
messages from receivers for a BIDIR-PIM group propagate hop-by-hop
towards the RPA.

Hello Sean

I believe this Cisco whitepaper explains it quite nicely. The context concerns the Nexus series of Cisco devices, but the principles expressed are the same. In the Bidir Rendezvous Point section on page 4 it states the following:

Because Bidir PIM relies exclusively on shared trees to distribute multicast traffic, a rendezvous point is required. Remember that all shared trees are rooted at a rendezvous point, so the concept of the rendezvous point in sparse-mode is also used here. However, in sparse-mode the rendezvous point had some special functions that it needed to perform. Mainly it needed to handle the registration process and the creation of source trees between sources and the rendezvous point. Neither of these two functions exists in Bidir so the concept of the rendezvous point is a little different. The rendezvous point still serves the function of getting sources and receivers to learn about each other, but in the case of Bidir it can be thought of as a vector. That means that the rendezvous point address doesn’t need to reside on a physical router interface but can just be an address in a subnet (it needs to be a routable address). This is not to say that the rendezvous point can’t be a physical router, it just means that is no longer a requirement

The document goes on to explain this in greater detail. I suggest you review it and if you have further questions, you know where to find us.

I hope this has been helpful!


Thanks Laz,
I have looked through this whitepaper before as well as many other articles and don’t see anywhere where it mentions how to configure this as at the end of the day the RP address has to reside somewhere.
Secondly in nearly all other documentation I find including networklessons it says the traffic in Bidir pim the traffic must flow through the rp but where does this physical traffic go if the rp is not assigned to a physical device ?
This is very confusing as the rfc sees to contradict most tutorials I have saw on the topic.

Hello Sean

Actually, it doesn’t :crazy_face: I know, it’s strange. I can understand how the lack of a physical interface or device assigned the RP IP address is strange and difficult to grasp. In the document I shared above, the way this works is stated, but I will attempt to clarify.

First of all, you choose the IP address of your RP so that it belongs to a particular network segment. It can be an address of a physical interface, or not, but it must be within the network segment (subnet) that you want to serve the function of getting sources and receivers to learn
about each other.

It is configured using the ip pim rp-address <acl> bidir command on all participating routers if you want to configure it statically, and the document describes how to do it using Auto-RP as well. So that’s how it is configured. How does it work? Let’s use the diagram they use in the document:

You can see that RP is just an IP address in the particular segment between the routers. Traffic from the source is going to be forwarded hop by hop to that destination, or to that subnet. Joins from receivers will also be sent to that subnet. The multicat routing mechanism knows thats the RP because we configured it as shown above.

Let me now share what it says in page 9 of the document, which states it better than I could:

Let’s start at the receiver end. Receivers, as usual, will send IGMP reports which will trigger a (*,G) join from the router toward the rendezvous point, creating a shared tree from the rendezvous point to the receiver as shown on the show ip mroute output. Note that in the “mroute” entry the incoming interface (or Bidir-Upstream interface) is Ethernet0/0 which is the RPF interface to the rendezvous point address; that means that any traffic received on Ethernet0/0 will be forwarded downstream through the shared tree.

Moving to the source side of the topology, the state for the left router shows that it is the designated forwarder on Ethernet1/0. That means that whenever it receives traffic for a Bidir group on that interface it will forward it “upstream” toward the rendezvous point, out Ethernet 0/0. When the packets reach that network, the connectivity from the source to the receiver is achieved. So, in a way it is the subnet ( and not a physical router that is acting as the rendezvous point.

I added the highlights for emphasis.

Well, in this case, the traffic must flow through the specific network segment or subnet, so the same thing is achieved.

I hope this has been helpful!


1 Like

Thank you so much Laz for this excellent answer !!! and thank you for all the hard work you put into this site. I very much appreciate it. Thank you.

1 Like

thanks Rene, i have a follow up question on this … So in BIDIR , till we do not have any source present but receiver present , we will have (*,G) entry till RP right(same behavior as SM).

Now Multicast traffic starts from source and once it reached to first hop router , that router will open the packet and look up the MCAST destination address, find its for BIDIRR enrolled group , packet will send to RP as per unicast table right ?

if the above statement is correct, unicast table path to RP is over MPLS/SR , so MCAST packet will be encapsulated under MPLS , is that right ?

As per the RFC " Bidirectional PIM dispenses with both encapsulation and source state
by allowing packets to be natively forwarded from a source to the RP
using shared tree state.In contrast to PIM-SM, this mode of
forwarding does not require any data-driven events."

Hello Praveen

Yes that sounds right so far…

If your topology is MPLS then yes, that is correct. MPLS supports PIM-BIDIR as per Cisco documentation. Indeed a multicast packet would be encapsulated under MPLS. As per the RFC, natively forwarded form, in this case, would entail MPLS encapsulation. And of course, the use of a shared tree state simply means that the RP is determined based on the information contained within the shared tree.

I’m not quite sure I have addressed your question however, so if not, please clarify and we can try to help further.

I hope this has been helpful!