Curtis Call wrote:

> I have a Question about the DR Election procedure as detailed in RFC 2328
> Section 9.4. The fourth step of the process specifies that if the router
> performing the procedure has been elected as BDR or DR, or lost it's position
> as such that it should repeat the process once more in order to ensure that it
> does not advertise itself as both the BDR and the DR. My question is, why is
> this not done by other routers as well in order to keep them from believing
> that the DR and the BDR are the same?

Section 9.4 says: "The reason behind the election algorithm's complexity is the
desire for an orderly transition from Backup Designated Router to Designated
Router, when the current Designated Router fails. This orderly transition is
ensured through the introduction of hysteresis: no new Backup Designated
Router can be chosen until the old Backup accepts its new Designated Router
responsibilities."

It also ensures that no DROthers attempt to bring up an adjacency with the
newly elected BDR before the BDR is aware of his new role, but this isn't
critical.

>
> For instance, if router X, determines that router Y is the BDR, and then
> promotes it to be the DR as well, why is there not an immediate check to redo
> the BDR election? Is the reason this isn't considered necessary due to the
> fact that router Y will go through the election procedure again and will pick
> a new BDR so it's hello packets will cause router X to generate a
> NeighborChange event and recalculate the BDR and DR?

I think what you're saying is that during DR Election, after the DR fails, the
DROther
routers don't need to repeat steps 2 and 3 because the DR Election algorithm will

be triggered again when the "old BDR, and new DR" sends out Hello packets. This
is correct. To further elaborate, consider a network of 4 routers (A-D). Rtr A
is
DR, Rtr B is BDR, and C and D are DROthers (with Rtr C having either a higher
priority and/or a higher router ID than Rtr D, making it more eligible).

Assume now that Rtr A (the DR) fails. This generates a NeighborChange event
for all routers (because "there is no longer bidirectional communication with a
neigbor"). They all run DR Election algorithm. The output of the algorithm is:

Rtr B: DR=Rtr B BDR=Rtr C
Rtr C: DR=Rtr B BDR=Rtr B
Rtr D: DR=Rtr B BDR=Rtr B

When Rtr B (the newly elected DR) sends out his next Hello packet, another
NeighborChange event occurs for DROthers (Rtr C and D) because "one of the
bidirectional neighbors is newly declaring itself as either DR or BDR." They
will
again run their DR Election algorithms, and the output will be:

Rtr C: DR=Rtr B BDR=Rtr C
Rtr D: DR=Rtr B BDR=Rtr C

There will be one more NeighborChange event for routers Rtr B and Rtr D when
Rtr C's next Hello Packet is received. This NeighborChange event is redundant,
and the output of the DR Election algorithm is unchanged. On May 31st, Jon Moy
posted in response to a question from Narendra Narayana saying:

> Narendra-
>
> It doesn't hurt to run extra Designated Router calculations,
> so the OSPF spec always errors on the side of running too many,
> rather than too few.
>
> John
>

-Rob

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]