Multicast Bidirectional PIM

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!

Laz

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 1.1.1.1 <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 1.1.1.1 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 (1.1.1.0/24) 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!

Laz

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!

Laz

Hello Laz

What do you mean about the sparse-mode “traffic only flows down the shared tree” and bidirectional PIM " traffic can move both up and down the shared tree"? what is the shared tree?

Hello Rodrigo

One of the fundamental characteristics of PIM sparse mode is the use of a shared distribution tree, also known as the Root Path Tree (RPT). You can find out more about this in the following lesson:

As stated in the lesson:

This concept of joining the RP is called the RPT (Root Path Tree) or shared distribution tree. The RP is the root of our tree which decides where to forward multicast traffic to. Each multicast group might have different sources and receivers so we might have different RPTs in our network.

Now as far as my statement in context with my post above, traffic only flows down the shared tree. This means that traffic will flow from the RP to the destinations. This is ideal when we only have a few sources, but when we have many sources and many destinations, it can become very inefficient, because you’ll need the creation of additional shared trees to get traffic to flow in multiple directions. This will make more sense if you go over the above lesson first.

I hope this has been helpful!

Laz

Hi,
Given the statements "When we use PIM bidirectional mode the RP will never build a (S,G) entry and we only allow the (*,G) entry for the shared tree. " and “PIM bidirectional does not use the PIM register / register-stop mechanism”.

Correct me if I’m wrong but if that is the case then the sources must be constantly sending to the RP ?
Like for example if I had CCTV cameras in bidir pim they would have to keep constantly streaming to the RP as there is no Pim register stop/ join etc. and also only (*,G) states so the RP couldn’t request the source to start sending ?

Hello Sean

In bidirectional mode sources can send traffic whenever they want, so yes you are correct, if sources have something to send, they will be constantly sending it to the RP. However, when multicast packets arrive at the RP, they will be forwarded down the shared tree if there are receivers. If there are not, the traffic will be dropped.

That’s why it’s important to place the RP somewhere in “the middle” of your network as close as possible to sources and destinations.

I hope this has been helpful!

Laz

1 Like

Thanks Laz,
So just to reiterate - the RP has no way to tell the senders to start or stop sending the flow even if at some stage the RP knows that he has no receivers for this traffic?

Then if that is the case, does that not outweigh the benefits of Pim BiDir ?
My understanding with Bidir there is only (*,G) and No (S,G) and the main benefit is it saves the resources on the routers from keeping track of all these (S,G) states, But surely in an environment where I had many many CCTV cameras they would all be constantly streaming to the RP and eating all the bandwidth and resources as the RP has no way to tell them when he does or doesn’t want their stream ?

Does this lack of “Start/Stop” communication between the RP and Senders with BiDir pim not outweigh its benefits in the first place as you will have constant unwanted streams all day using up bandwidth and resources ?

Hello Sean

Whether the benefits are outweighed by the lack of a start/stop mechanism all depends upon the nature of your multicast applications.

Bidirectional PIM would not be suitable for a CCTV network for the reasons that you state in your post. This is because such a scenario has potentially many multicast sources (cameras), but very few receivers (control rooms, monitors etc…).

However, for scenarios where we have many sources and many receivers, you will find that it is better to have multicast traffic from sources reach the RP and be dropped in the event that there are no receivers, rather than to have a multitude of shared trees and multiple mroute state entries. The weighing of benefits to drawbacks must take into account the applications being run on the network.

But you also have to keep in mind that there is some intelligence in the multicast applications themselves. For example, in a PIM bidirectional multicast network, a videoconferencing system will send multicast traffic to the RP, but eventually, the application will be shut down once the conference is over. So the source of the multicast traffic won’t continuously be sending traffic 24/7 but will be shut down at some point. So you don’t only rely on the mechanisms of multicast on routers to ensure efficiency, but you trust that the applications themselves will only be run when needed.

I hope this has been helpful!

Laz

1 Like

Many thanks for your answers Laz. Very helpful and good info as always.

1 Like

“Another difference between PIM sparse mode and PIM bidirectional mode is that with sparse mode traffic only flows down the shared tree. Using PIM bidir mode traffic will flow up and down the shared tree! Also PIM bidirectional does not use the PIM register / register-stop mechanism to register sources to the RP. Each source is able to start sending to the source whenever they want”

I think you meant to say Each source is able to start sending to the RP whenever they want. Correct me if I am wrong.

Thank you!

Hello Muhammad

Yes, you are correct. I will let @ReneMolenaar know to make the necessary modifications.

Thanks!

Laz

Hi,
Can someone please explain the difference between designated forwarder (which is used in bidir) and designated router (used in sparse mode)?

Hello Nipun

The designated router is the router that will forward the PIM join message from the receiver to the RP.

The designated forwarder in BDIR is the router that will forward multicast traffic to the RP.

Notice that the designated router forwards control messages (PIM join) while the designated forward forwards actually multicast (user) traffic. Another way to say it is that the designated router functions on the control plane while the designated forwarder operates on the user plane.

For a more detailed explanation of the designated router and its function, take a look at this lesson:

I hope this has been helpful!

Laz

1 Like

Really helpful @lagapidis Thanks a lot.
I have another question.
How to configure PIM Bidir in bsr mode? I couldn’t add the bidr keyword in bsr commands.

Hello Nipun

In the Cisco IOS implementation of PIM, each multicast group individually operates in one of the following modes: dense mode, sparse mode, or bidirectional mode. Groups in sparse mode (PIM-SM) or bidirectional mode (bidir-PIM) use RPs to connect sources and receivers. All routers in a PIM domain need to have a consistent configuration for the mode and RP addresses of the multicast groups.

The Cisco IOS software learns the mode and RP addresses of multicast groups through the following three mechanisms: static group-to-RP mapping configurations, Auto-RP, and bootstrap router (BSR). By default, groups will operate in dense mode. No commands explicitly define groups to operate in dense mode.

The above is taken from this Cisco command reference for the ip pim rp-addresscommand.

Therefore, BSR should be capable of informing neighboring routers of the BIDIR mode when using BSR.

In the lesson, the RP was defined statically, and the bidir keyword was available. I went into the lab to check this out fpr BSR, and found that I had the bidir keyword available. Specifically:

R1(config)#ip pim rp-candidate gigabitEthernet 0/0 ?
  bidir       Group range treated in bidirectional shared-tree mode
  group-list  group-list
  interval    RP candidate advertisement interval
  priority    RP candidate priority
  <cr>        <cr>

The rp-candidate keyword is that used to indicate that BSR is employed.

Similarly, if you were to employ AutoRP, you have the bidir option available too.

R1(config)#ip pim send-rp-announce gigabitEthernet 0/0 scope 10 ?
  bidir       Group range treated in bidirectional shared-tree mode
  group-list  Group access-list
  interval    RP announcement interval
  <cr>        <cr>

Keep in mind that the bidir keyword is only available if BIDIR-PIM is enabled using the global ip pim bidir-enable command.

I hope this has been helpful!

Laz

Thanks.this helps @lagapidis

1 Like