ip pim, DR election is somehow related to forwarder election?

[jean tang]

HI, friends  . I have some questions about PIM dr and forwarder election.

here's my topology

R1(f0/0)-----------(f0/0)R2(f1/1)----------------(f1/1)R4

                |                                    |

                |                                    |

                |-----(f0/0)R3(f1/1)-------|

all 4 routers run SM

R4 is RP & mapping agent for multicast group 224.1.1.1, and also the multicast source .

R1 joins this group. when R4 ping 224.1.1.1,  it works.

R3's f0/0 (10.1.123.3) will be FORWARDER and DR  for the segment of  R1/R2/R3.

but when I change R2 f0/0, ip pim dr-priority 2

R2#

(10.1.234.4, 224.1.1.1), 00:00:22/00:02:38, flags: JT

  Incoming interface: FastEthernet1/1, RPF nbr 10.1.234.4

  Outgoing interface list:

    FastEthernet1/1, Forward/Sparse, 00:00:22/00:02:37

not only R2 f0/0 become the DR, but also the forwarder for the segment too, why?

maybe priority is considered on both  DR and forwarder??

[boss.silva]

Hello,

PIM DR (Designated Router) is used in Sparse-Mode, which will be the router that is responsible for Register and Prune messages to the RP.

PIM DF (Designated Forwarder) is used in BIDIR-PIM for election of the router responsible of the segment for sending multicast traffic destined to an RP. The election mechanism is the same as the DR election process.

Does that answer your question?

Regards,

Bruno Silva.

[Peter Paluch]

Bruno,

In RFC 4601 for PIM-SM, there is indeed a concept of a Designated Forwarder (or simply called Forwarder) along and in parallel with Designated Router. To be honest, I was always confused by the existence of these two, their true difference and purpose. I cannot contribute to this thread by an answer, as I am myself in the position of a person seeking answers to the DR/DF difference, but I have to point out that even the PIM-SM uses the concept of DF coexistent with DR.

Check the RFC 4601.

Best regards,

Peter

[boss.silva]

Hi Peter,

As far as i can understand the RFC 4601, the forwarder in Sparse-Mode is the same as the DR. The RFC mentions their election using Assert messages. The section 3.6 talks about the situations that the forwarder would solve, which are basically everything that the DR does.

Regards,

Bruno Silva

[Mohamed Sobair]

Hello Jean,

The Designated Forwarder is Pim Bidirectional Concept , the role of DF is primarily sends Multicast recieved from the Source towards the RP not encapsulated because its rooted at the Shared tree. the Pim DF is a router that has least metric towrds the RP.

Be notice that in Pim Bidirectional, the DR is also DF , there is no specific DR in pim bidirectional.

In Pim Sparse mode, the RP recieves Encapsulated Multicast from the Source which is unicasted through Pim registration message, this process goes on till a register stop message recieved from the RP.

a last point here is: changing the DR-Priority shouldnt change the forwarder role, it should change the DR role, because a DR on a segment is that a router with a highest priority or incase of a tie, its the router with the highest IP address.

But, the DF, is always the router with lowest metric (cost) towards the RP and if there is a tie, it would be the router with the highest IP address on the Segment.

@ Peter,

The difference between DR and DF can simply be defined as follows:

The DF: is a router forwards multicast traffic upstream .on the shared tree.

The DR:  is a router forwards the multicast traffic downstream on the shared tree

I hope this answers your question,

Regards,

Mohamed

[Peter Paluch]

Hello Mohamed,

Thank you for answering! Please allow me to discuss some things, though.

The DF: is a router forwards multicast traffic upstream .on the shared tree.
The DR:  is a router forwards the multicast traffic downstream on the shared tree

Interesting. I would put it exactly opposite: the DF forwards multicast traffic downstream from RP towards joined clients. The DR sends the multicast traffic upstream the tree towards the RP.

My reasoning is based on RFC 4601 where in Section 3.6, it is suggested that there can be more routers on a transit LAN segment that have sent Joins towards the RP or the sender (i.e. upstream), and hence, when the multicast stream starts to flow downstream the shared tree, multiple routers will deliver it onto the transit segment. If - and when - this happens, the Assert process will elect the only router, i.e. the DF, that will continue delivering this stream onto the segment. This data flow is in the downstream direction, i.e. from the RP towards the joined clients.

Regarding the DR, the Section 3.1 is very clear about the fact the DR is responsible for sending Joins towards the RP, and also is responsible for sending the Register messages towards RP. Both tasks are related to the upstream direction.

Best regards,

Peter

[Mohamed Sobair]

Hello Peter,

This is absolutely correct.

what I meant is exactly the opposite of my previous post, I just mistyped the sentence where the DR  and the DFroles  functions.

Regards,

Mohamed

[boss.silva]

Hello Mohamed/Peter,

From what i understand: The DF is the router responsible for forwarding traffic torwards the RP. Each segment will have a DF. And this concept of DF is only used in Pim BIDIR.

The DR on the other hand, will be the router on either the source/client side responsible for sending the multicast traffic. It's available on either BIDIR or Sparse-Mode.

I can't see where the DF would fit in the Sparse-Mode.

Regards,

Bruno Silva.

[Peter Paluch · Accepted solution]

Hello Bruno,

The RFC 4601 talks about two distinct functions: the Designated Router (DR) and the Forwarder/Designated Forwarder. It is interesting to note that RFC 4601 uses the term Forwarder far more often than the Designated Forwarder, but it does reference it once - in Section 6.1.1, Step 3. The mere fact that RFC 4601 does talk about DRs and Fs/DFs separately - and this cannot be disputed - suggests that the concept of DF exists even with PIM-SM. However, the function of the DF in PIM-SM should not be related or likened to the DF function in Bidir-PIM.

The DR on the other hand, will be the router on either the source/client  side responsible for sending the multicast traffic. It's available on  either BIDIR or Sparse-Mode.

I am afraid I see it differently. We have also discussed this with Mohamed a few posts earlier here, and we came to an agreement that the DR in PIM-SM is responsible for

• sending multicast stream towards the RP as the Register source during the Register process
• sending PIM Joins and Prunes towards the RP or the multicast stream source

i.e. the "upstream" operations. The DF in PIM-SM solves the issue what happens in the case that more than one upstream router on a multi-access segment has issued a Join for the same group, and the stream is thus being delivered more than once to the segment.

Also, there is no Designated Router in Bidir-PIM - there are only Designated Forwarders in Bidir-PIM. You suggested that Bidir-PIM has a concept of DRs but the RFC 5015 talks exclusively about Designated Forwarders.

It is important to note that RFC 4601 states in Section 4.6.5 that an Assert Winner (i.e. the Forwarder) further also acts as the Designated Router on behalf of client IGMP/MLD Joins and Leaves. In other words, after a duplication of a multicast stream delivered to a multiaccess segment occurs, the DF is elected (before, there is no need to elect the DF), and the DF takes on the role of DR for client IGMP/MLD joins and leaves, so the role of DR and DF merges. The only thing that the new DR probably does not (or needs not) to take on itself is the Register process. I would have to confirm this in a lab, though, but as the RFC 4601 specifically states about the DF taking on the role of DR on behalf IGMP/MLD clients, the Register process seems to be somewhat independent of this.

Best regards,

Peter

[jean tang]

thank you all, friends.

Especially, thank you, peter.

actually, I didn't memtion the BIDIR mode.

I used SM on all routers and I think it only ralated to DR and forwarder

Regards