Hello Rene, thanks a lot for your explanation.
However I have a question abount your statement:
R3 uses R1 to get to the RP
R4 uses R1 to get to the RP
So, seems that from unicast routing table perspective, both R3 and R4 has the same metric best path to reach the RP: via R1
However after you say:
R3 sends the PIM join to R1.
R4 sends the PIM join to R2.
For my understaning, R3 and R4, the DRs for their multiaccess-segment should send the PIM join also only toward R1, because they want reach the RP and the best path, as said in the previous paragraphe, it’s via R1.
@ReneMolenaar please can you explain to me the difference between the dr and the pim forwarder? It seems to me that the dr does everything that the pim forwarder does and more. I cannot see what part of the assert message/function is unique.
In a previous reply you said you can have both a DR and DF. Well if they were different routers on the segment, the DF would prune it’s link upstream via PIM and not be able to create a RPT. So the DR must be doing the function you described as being the DF. There is no clarity on what the difference is.
A PIM forwarder is the router that will be used to forward the multicast traffic itself.
A Designated Router is the router that will forward the PIM join message from the receiver to the RP when there is a multiaccess topology
The first one actually forwards user multicast traffic the second one is involved in communicating multicast control traffic.
Well, not quite. Pruning takes place downstream, not upstream. As you can see from the PIM Assert lesson, it is the Fa0/1 interface of R2 that’s pruned, which is the downstream interface. Remember, that R2 and R3 are part of the same network segment. That’s why one of the two must be chosen to send user multicast traffic, and one of the two must also be chosen to send PIM join messages. Not both. Otherwise, any multicast traffic, or any multicast join messages sent from R4 will reach the source twice.
Remember that the cost that appears in the routing table entry is the total accumulated cost from the router to the destination. From R2 to the destination network of 1.1.1.1, we have a cost of 10 for the Fa0/0 exit interface, plus a cost of 1 for the directly connected network of 1.1.1.1, for a total of 11.
Similarly, from R3, we have a cost of 11 for the Fa0/0 exit interface, plus a cost of 1 for the directly connected 1.1.1.1 network of the loopback interface for a total of 12.
I have done pretty much the same topology, but using PIM Sparse mode, globally I have R1 as a source on the TOP, then below an interconnection to a switch from the switch you have interconnections to R2 and R3, there is HSRP between them lets say all the network 192.168.1.0/24, then on the other side the same type of interconnection will be done as a receiver R4 on the network 192.168.2.0/24.
Never see the Assert mechanism in action, I am using PIM sparse mode with MSDP between routers R2 and R3 for anycast RP, the DR router on the receiver side is R2.
From what I have noticed the IGMP Membership is received by R2 and R3, I will tent to say since R2 is the DR he will be the one handling to deliver this to the RP, so on R2 I see the one that is delivering the mcast traffic, R3 I see it prunes itself from on the segment facing R4, but don’t understand really why, and actually I see RPF failures on R3 I will tent to say is because the switch still forwards packet from the source R1 that will be received on the LAN of R3 facing R4 on which the source aim to be seen on the segment of R1, is that correct ?
So globally how it handles to know that R3 needs to prune itself and how can mitigate the problem regarding the RPF failures.
Is there any information you need, please let me know.
First of all, Multicast PIM Assert is a feature that is useful in a dense mode multicast environment. If you configure PIM Sparse mode, then a different mechanism comes into play, which is the designated router.
The designated router is not something you have to actually configure, since by default it is enabled. By applying sparse mode in your topology, you are actually creating something similar to the following lab:
In this case, PIM Assert does not come into play.
Now I was not completely clear on the other configuration changes you made in your topology, such as HSRP, but take a look at the above lesson, and see if that clears up most of your questions. If not, let us know so wee can continue to resolve your issue!
In such a scenario, when R2 and R3 “see” each other’s multicast traffic on the 192.168.234.0/24 network segment, a negotiation between those two routers takes place. This is part of the PIM assert mechanism. They exchange information, including their own locally significant administrative distance to the source of the multicast stream as it appears in the local routing table of each router.
If this is the same, they then compare their IP addresses.
Hi Rene. Thanks for your explanation.
However I got a question on this topic as I’m confused with PIM DR and PIM assert.
You say:
R3 uses R1 to get to the RP.
R4 uses R2 to get to the RP.
Isn’t PIM DR supposed to handle this and only DR should send the PIM join to RP? Suppose R1 is the DR for the multiaccess-segment , why would R2 receive multicast traffic from RP (and forward to the multiaccess-segment) if it didn’t send the PIM join to RP?
I believe you are correct. R3 and R4 will send their PIM join messages via the designated router as described in the corresponding lesson. I will let Rene know to take a look and clarify his post.
Hi Rene,
Since RPF doesn’t prune,if R2 and R3 are directly connected and there’s no R4,how are R2 and R3 eventually all pruned?I understand.that the assert loser(let’s say is R2)will prune itself,but how is the winner(R3) pruned?
A.R2 send a prune message to R3 once it decides it lose
B.R2 send a prune message to R3 when it decides there’s no host on the line listening
C.R3 prune itself when it decides there’s no host on the line listening
When R1 begins to send multicast traffic, it will go to both R2 and R3. They will both forward traffic to the network segment with the switch, and due to the nature of multicast traffic, R3 will “see” R2’s multicast traffic, and R2 will “see” R3’s multicast traffic. It is this detection of duplicate traffic that will trigger the election.
Now in the scenario you suggested in your post, we remove R4 (the receiver). If there is no R4 to request traffic then you have eliminated the conditions under which a PIM assert election will take place. You also eliminate the multicast traffic as well, so the issue of how pruning will take place is moot. Does that make sense?
Hi Laz,
Thank you for your reply,
I might not be precise and i just mean that R2 and R3 are directly connected,and they have receiver connected, respectively,on their other interfaces.
Now due to the nature of PIM-DM,there will be duplicate multicast traffic on the R2-R3 segment,arrived on their non-RPF interfaces,which will be dropped by RPF,and trigger an assert election.Then,are the following statements correct:
“”“The loser of the Assert process will send a PIM Prune towards the winner (link between R2 and R3). Now, here are three situations: there are only the two routers on the segment: In this case the winner receives the PIM Prune message and it stops sending the traffic. there is a third router (downstream) on the segment: In which case, both the winner and the third router receive the PIM Prune message, and the third router responds to it by sending a PIM Join to override the PIM Prune sent by the loser. there is an IGMP receiver on the segment: in which case the winner won’t stop forwarding traffic, I assume that because of the IGMP active client.”“”
Thanks for your patience!
Kai
This is actually not true. The routers on the segment send PIM assert messages not PIM prune messages that contain information about the AD and the metric to the multicast source. The loser simply prunes its own interface.
Actually, in this case, the winner will continue to forward the multicast traffic until it receives a Prune message from a downstream router or until the multicast traffic itself stops.
Not quite. If you have a downstream multicast router that is further forwarding the multicast traffic, because it is part of the same segment as R2 and R3, it will receive the PIM Assert message. However, because it has not received this message on a non-RPF interface, it will ignore it. The PIM prune override will not kick in here.
In this case, the winner will not stop forwarding traffic. This is because the IGMP receiver sends IGMP Membership Reports to the routers on the network, indicating that it wants to receive traffic for a specific multicast group. The router will then continue to forward traffic for that group.
How does this mechanism work when sparse mode is used? The routers have to forward a JOIN from the receiver out of their RPF interfaces which basically tells the routers in the path to forward the multicast stream. Does only one of the routers do it in this case, or?
