Multicast Bidirectional PIM

Lessons Discussion
21

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.

22

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!

Laz

1 Like
23

Hi,
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 ?
Thanks

24

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!

Laz

2 Likes
25

Thank you for this excellent answer.

1 Like
26

Hi,
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.

27

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

28

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.

29

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:

image
image900×567 75.2 KB

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
30

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
31

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."

32

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

33

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?

34

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

35

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 ?

36

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
37

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 ?

38

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
39

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

1 Like
40

“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!