Hello Bhawandeep
This is an issue of terminology, and strictly speaking, you are correct. R4 is acting as a host, and would thus send a Join message using IGMP, and both R2 and R3 would receive it. The router which is the DR will then forward a PIM join message to the RP.
I will let Rene know to make that clarification in the lesson.
Thanks and I hope this has been helpful!
Laz
Nice lesson. There is one point that I donât understand at all.
If R4 is would be DR he sends via uplink PIM join with IP dest 224.0.0.13.
In this case, it doesnât matter which of the neighbors the route to the RP is better though since in any case the connection will be sent with fa0/0.
Since the above switch join will reach R2 and R3.
In the end, who (R2 or R3) forward join to the RP, if elected DR is R4? and how is it determined?
Hello Georgiy
In this topology, R4 is playing the role of the host that requests the multicast traffic using IGMP. In a real scenario, you would see a PC there. So R4 would never become the DR since it, in essence, is not a multicast router.
A DR is always chosen between two or more multicast routers that exist on a single network segment. This is determined by the multicast-enabled routers themselves when R2 and R3 detect each other on the same network segment.
I hope this has been helpful!
Laz
Hello Lazaros.
I asked about something else. The logic of work when R4 is a host is clear to me. But when he is a PIM router ⌠then itâs already unclear to me how this should work.
Hello Georgiy
Ah, I see. So youâre looking at a topology like this:
where R4 is also a multicast router, and H1 is the receiver, correct? In such a case, R4 will become the DR because it has the highest IP address.
That means that H1 will send a join message that all three routers, but only R4 will forward the PIM join message to the RP. How does it choose which path to take to reach R1? It will use unicast routing since the destination IP is that of the RP. Whatever path is chosen by OSPF will be used.
Remember, the DR is simply the router that will forward the join messages to the RP. It doesnât matter whether it is directly connected to the RP or not, just as long as the DR can reach the RP via unicast routing.
I hope this has been helpful!
Laz
Hi,
What if the link between R3 and R1 was not ethernet e.g. serial, youâll end up with sub-optimal routing from the RP to the Receiver because the shared tree is being built via the slower link, correct?
And what about RPF failure? Wonât that happen because the route to get to the RP is via R2, not R3? Or does RPF only check against the incoming interface?
Thanks.
Sam
Hello Samir
Well, not quite. Remember, the DR is the router designated to send the PIM join messages to the RP on a multicaccess network. This is completely a control plane mechanism. It doesnât forward actual multicast traffic. It is the PIM Forwarder that forwards the traffic, and it is through the PIM forwarder that the shared tree is built. More on the PIM forwarder can be found here:
The PIM forwarder is actually chosen based on AD and metric and not simply on the highest or lowest IP address so even if you have a serial link somewhere, the best path will be chosen for routing multicast traffic.
Secondly, even if you do have a serial link between R3 and R1, R3 will forward the PIM join messages using the unicast routing table of R3. If the best route is to send that join message via R2 to R1, it will do so. So even for the sending of the join message, the best route will still be chosen for that control plane traffic. This is not so much of a concern since these messages are generally very small and not too frequent, however, the best path should still be chosen.
Again, RPF is only applied to the actual user multicast traffic and not the control plane traffic such as join messages.
I hope this has been helpful!
Laz
Hi Laz,
Thanks for responding but Iâm still a little confused.
Arenât the PIM join messages, which are sent up the slower link (in my example), creating the path that the multicast traffic will flow down? So although they are control plane traffic, the route multicast takes will be the same as the JOINs, just in the opposite direction.
I also assumed that even if there was sub-optimal routing, it wouldnât be an issue most of the time because muti-cast traffic would switch from the shared tree to the root tree eventually anyway.
I also read the Multicast PIM Assert lesson, and it all made sense to me, but I was under the impression that it only applied to dense mode, whereas DR is for sparse mode situations.
Thanks again for you help,
Sam
Hello Samir
Actually, the PIM assert mechanism is used in both dense mode and sparse mode multicast environments.
As you know, in sparse mode multicast, the network assumes that only a few routers and subnets are interested in receiving multicast traffic, and the multicast traffic is forwarded only along the shortest path from the source to the receiver. In this scenario, the PIM assert mechanism is used to resolve conflicting routing information when multiple routers claim to be the shortest path to the source. When you have a multiaccess topology in a sparse mode multicast environment such as that in the PIM assert lesson, this may be the case.
As such, the router that is chosen as the forwarder will forward the actual multicast traffic, while the one chosen as the designated router will forward the PIM join message. You should configure both of these parameters such that the most efficient path is used.
Yes, even if that is the case, the multicast traffic would eventually take the most efficient route.
I hope this has been helpful!
Laz
Hi Laz,
Thank you for the detailed reply.
I wasnât aware that even in sparse mode, you could have duplicate multicast traffic flowing to the same multiaccess network. I though the designated router would prevent it by only sending PIM joins up one path.
I need to have a think about what scenarios could cause this to happen.
Thanks.
Sam
Iâd like to know if this statement is right :
In this lesson, R4 is both, mcast listener and mcast forwarder. Since R4 joins to 239.1.1.1 igmp group, but at the same time issuing a ping to 239.1.1.1
This topology is implemented with sparse-mode , and the R1âs lo0 (1.1.1.1) configured statically in all routers as the RP.
So, when R4 pings 239.1.1.1 it has to forward its own originated mcast traffic via the tunnel towards the RP (R1âs lo0 1.1.1.1).
R4 is in a Multi-Access Network (R2,R3,R4) , therefore the DR (Designated Router) Election is :
The RP receives the mcast traffic, and now it has to forward to the receiver (R4), both R2 and R3 would receive this traffic, the Assert Winner will be the only who will forward the mcast traffic. The Assert election in this case will be :
In this case R4 is directly connected in the same subnet as R2 and R3, so step 1 and 2 is skipped to step 3, R3 wins and is elected as the Assert, and therefore will forward the mcast to R4.
Summarizing the mcast traffic path would be :
Hello Juan
Yes, your description seems to be correct. Just a couple of clarifications:
In this scenario, R4 is actually not participating in multicast routing at all. Notice that PIM is not enabled on any of its interfaces. Although in the lesson, Rene does enable multicast routing on R4, it is not actually needed since R4 is acting only as a host requesting to receive multicast traffic. So it is not one of the candidate DRs nor one of the candidate assert winners found within the particular multi-access network.
Secondly, remember that the DR, once elected, is used only as the router through which PIM join messages are sent. This is not multicast traffic, but only PIM join messages. These are the messages that are sent from the host requesting the traffic, upstream to the RP.
Finally, the winner of the PIM Assert mechanism on the multi-access network is the router through which multicast traffic is forwarded. This is the actual multicast traffic that is sent downstream to the host that requested it. Does that make sense?
I hope this has been helpful!
Laz
