This topic is to discuss the following lesson:
Hi Rene
First of all thanks a lot or sharing your knowledge. Your way of explanation is very simple & concise. Before start learning any particular topics ya concept, i check ur blog posting includes that topic or not. Jst now i find, Bi Directional PIM. Its so nice to learn from ur blogs. Appreciate the efforts. Thanks a lotzzzzzz…
While labbing the same topology, i found something diff from ur configuration. Here it is:
- “ip pim bidir-enable” should be enable on R4 & R5 as well.
- “ip pim rp-address 1.1.1.1 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
Hi,
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?
(*, 239.1.1.1), 00:04:07/00:03:19, RP 1.1.1.1, flags: BC
Bidir-Upstream: FastEthernet0/0, RPF nbr 192.168.13.1
Outgoing interface list:
FastEthernet0/0, Bidir-Upstream/Sparse, 00:04:07/00:00:00
FastEthernet0/1, Forward/Sparse, 00:04:07/00:03:19
Rene
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.
Rene
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.
Rene
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 239.1.1.1
(*, 239.1.1.1), 00:09:39/00:03:10, RP 1.1.1.1, flags: BC
**Bidir-Upstream: FastEthernet0/0**, RPF nbr 192.168.13.1
**Outgoing interface list:**
**FastEthernet0/0, Bidir-Upstream/Sparse**, 00:09:39/00:00:00
**FastEthernet0/1, Forward/Sparse**, 00:09:39/00:02:42
Thanks,
Kent
Earlier output below:
R3#show ip mroute 239.1.1.1
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
(*, 239.1.1.1), 00:04:07/00:03:19, RP 1.1.1.1, flags: BC
**Bidir-Upstream: FastEthernet0/0**, RPF nbr 192.168.13.1
**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 239.1.1.1 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 1.1.1.1 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!
Laz
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 239.1.1.1 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 1.1.1.1 bidirThanks.
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!
Laz
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 1.1.1.1 *192.168.24.2 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 1.1.1.1 bidir
R1-3#
I’ve followed along character for character and would like some guidance.
When I ping 239.1.1.1 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 1.1.1.1 *1.1.1.1 0 00:59:29
GigabitEthernet0/0 1.1.1.1 *192.168.12.1 0 00:59:29
GigabitEthernet1/0 1.1.1.1 *192.168.13.1 0 00:59:06
R1#
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? 
) 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
