Multicast Bidirectional PIM

While labbing the same topology, i found something diff from ur configuration. Here it is:

  1. “ip pim bidir-enable” should be enable on R4 & R5 as well.
  2. “ip pim rp-address bidir” should be configured on R4 & R5 as well.

Then only i am getting the same output as u mention in your most. Let me know i have done mistakes anywhere ya i understood it wrongly.

1 Like


Thanks for the nice article.

Shouldn’t the second-to-last R3 output only show f0/1 in the outgoing interface list? Since R5 is the only receiver?

Hi Paul,

You mean this output?

(*,, 00:04:07/00:03:19, RP, flags: BC
  Bidir-Upstream: FastEthernet0/0, RPF nbr
  Outgoing interface list:
    FastEthernet0/0, Bidir-Upstream/Sparse, 00:04:07/00:00:00
    FastEthernet0/1, Forward/Sparse, 00:04:07/00:03:19


Hi Rene,


Question on this part of the lesson: “to register sources to the RP. Each source is able to start sending to the source whenever they want.” Do you mean to say that the source can start sending to the RP whenever they want? Because there is no registration messages between the source and the RP multicast flows just continue until the source starts sending - Do I have this correct?

1 Like

Hi Michael,

With “normal” PIM the designated router on the segment will encapsulate the first multicast data packet in a register message and forwards it to the RP. When the RP doesn’t want to receive this traffic, it sends a register stop message back to the designated router.

It seems you understood it correctly. Any source can just start sending multicast traffic to the RP. There are no registration (stop) messages so it’s just being forwarded.


Hi Rene,

I really enjoy the way you teach and the content is very well organized.
I have a question regarding PIM Bidirectional.
For have in all Pim enabled Router the *,G to the RP on downstream Router, we need to enable globally the pim bidirectional.
What if i have on third party router that doesnt’ support pim bidirectional? is it will be enable to from *,G to the RP?

Hello Junior,

Today, it’s unlikely to find a network with multicast routers that don’t support bidirectional PIM. Back in 2007 however (when bidirectional PIM became a standard), most multicast routers didn’t support it so you needed something to make it compatible.

In the PIM hello packets, there’s an option that indicates whether the router supports bidirectional PIM or not. When the routers elect the designated forwarder, all routers on the subnet have to support bidirectional PIM. If one router doesn’t support, bidirectional PIM is disabled on that subnet.


Hi Rene,

I do not understand based on the last output shown below
(Now we see FastEthenet0/0 as the Bidir-Upstream interface and FastEthernet0/1 in the outgoing list. This is something different than what you have seen before right?)

Isn’t your earlier output already showing FastEthenet0/0 as the Bidir-Upstream interface and FastEthernet0/1 in the outgoing list?

R3#show ip mroute    
(*,, 00:09:39/00:03:10, RP, flags: BC
  **Bidir-Upstream: FastEthernet0/0**, RPF nbr
  **Outgoing interface list:**
     **FastEthernet0/0, Bidir-Upstream/Sparse**, 00:09:39/00:00:00
    **FastEthernet0/1, Forward/Sparse**, 00:09:39/00:02:42


Earlier output below:

R3#show ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(*,, 00:04:07/00:03:19, RP, flags: BC
  **Bidir-Upstream: FastEthernet0/0**, RPF nbr
  **Outgoing interface list**:
    **FastEthernet0/0, Bidir-Upstream/Sparse**, 00:04:07/00:00:00
    **FastEthernet0/1, Forward/Sparse**, 00:04:07/00:03:19

Above you see that the FastEthernet0/0 interface is the upstream (towards the RP) and FastEthernet0/1 is the outgoing interface (towards R5). Now we will configure R4 to join the multicast group as well so that they can communicate with each other:

Hi System,

I did the same below for the lab to work too. Let me know if you have found the answers to your query. Thanks.

“ip pim bidir-enable” should be enable on R4 & R5 as well.
“ip pim rp-address bidir” should be configured on R4 & R5 as well.

Hello Kenneth

You are correct in that the output was the same as that shown earlier in the lab. Of course, this is indeed different from the output shown in R2 which is shown just previously. I will ask Rene to clarify his statement.

Thanks for the heads up!


Hey System,

He is using R4 and R5 as “host” on the network, not multicast routers, that is why he didn’t enable any directional commands on them and why you don’t need them.

1 Like

Hello Rene,
When labbing the same topology,
I was not to see the entry with in the routing table neither R2 or R3 when running continuous ping from R4.
Should i configure in R4 and R5 both commands:

ip pim bidir-enable
ip pim rp-address bidir


Hello Harold

Keep in mind that R4 and R5 are playing the role of hosts in this topology, so they’re not actually part of the Multicast bidirectional PIM functionality, so this should not be configured on these routers. Verify that your configuration is correct and that all other functionalities are working. Note that the actual ping from R4 will not be successful initially as there are no receivers yet at that point in the lab.

I hope this has been helpful!


Hi Rene and Laz,

While I’m following the multicast Bidir lab step by step I can’t replicate the designated forwarder like you both do.

R2#show ip pim interface df 
\* implies this system is the DF
Interface                RP                DF Winner        Metric     Uptime
FastEthernet0/0          *     11         00:01:36

In my specific situation, when I run the command on all three routers (r1,r2,r3) I find that the only designated forwarders are all three interfaces on my r1 router and not those interfaces found on both r2 and r3.

I have the following bidir commands on (r1,r2,r3)

R1-3#sh run | i bidir
ip pim bidir-enable
ip pim rp-address bidir

I’ve followed along character for character and would like some guidance.

When I ping on the r4 router and then perform a show ip mroute on r1, I don’t see anything.

Any ideas what I could be overlooking?

My lab below:

R1#sh ip pim interface df
\* implies this system is the DF
Interface                RP               DF Winner        Metric     Uptime
Loopback0                *          0          00:59:29
GigabitEthernet0/0          *     0          00:59:29
GigabitEthernet1/0          *     0          00:59:06

Thank you,

Jay Karson

Hello Jay

I tried labbing this up again and it seems that I am getting the correct output as stated in the lab. However, while I was labbing it up I did make an error, and actually had the same output as you! (divine intervention? :thinking:) What I did was I messed up the IP addresses on both of the interfaces on R2, so I wasn’t getting any OSPF neighbor relationships being formed. I fixed it and all was well.

I suggest you verify that OSPF is functioning on all devices, and that neighbors are appearing on all routers. Check that unicast routing is functioning from end to end, and also check that your multicast configuration is correct. I know that you checked it one by one, but I see that the current configs did work out on my topology.

Let us know if you discover any typos that you may have had that caused the problem…

I hope this has been helpful!


Laz thank you for your understanding!
I do have the ospf neighbors in area zero and all have the same OSPF config with all interfaces up.
I’m uploading a picture of my Lab at the L3 layer for you to see
sion - sh ip ospf nei
shipb - sh ip int brief

Jay K.

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