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.