The designated forwarder election is a very large part of the BIDIR‑PIM RFC.
There are a lot of DF packets, and there are more DF election rules,
and I encourage you to check out BIDIR‑PIM RFC 5015.
It goes very in depth on every DF election state
and the rules when transitioning.
In this course, we can't cover all the possible incarnations of DF election,
but we can look at the packets and see what options and
data are included to aid in this process.
The first part of any DF election is the offer.
This is a similar packet to the designated router election.
It's just suggesting that it can be the designated
forwarder because of its metric to the RP.
It's sent to the ALL‑PIM‑ROUTERS group on the
segment and includes the RP address, as well the best metric it has to it.
The DF Winner packet serves two purposes.
The first is to inform every router on the segment that this local
router is assuming the role of designated forwarder.
The other purpose of the packet is as a response to other
routers sending worse offers to inform them that there is a
winner with a better metric.
As with the offer packet,
the PIM options include for which RP the router
will be the designated forwarder, as well as the best Unicast metric.
The Backoff packet and DF election exists to announce that the DF has
acknowledged a better offer and instructs other routers on the segment
to wait until the forwarding responsibility is sent to the new DF
before sending any other DF offers.
This would be seen during the start of a DF transition
from a current elected DF to a new one.
If no forwarder yet exists on the segment, there will be no Backoff packet.
The DF election Pass is sent by the old designated forwarder as the
responsibility to a router that previously has sent a better offer.
This is also part of DF transition and is sent the ALL‑PIM‑ROUTERS group
to advise the new designated forwarder to take over.
Once again, we have the same options, the RP and the best Unicast metric.
In this module,
we've discussed one of the most complex
implementations of PIM which is BIDIR‑PIM PIM.
We spent time on the command line seeing how a designated
forwarder is elected and can change,
and then we spent time examining the flow of multicast
in a bidirectional implementation.
We finished by examining the PIM Hello packet and how it's different
in BIDIR‑PIM and then a PIM Join/Prune packet, and finally, the designated forwarder election packets in detail.