Donald Sharp <[email protected]> writes: > From the RFC-4601(4.3.2): > > A router's idea of the current > DR on an interface can change when a PIM Hello message is received, > when a neighbor times out, or when a router's own DR Priority > changes. If the router becomes the DR or ceases to be the DR, this > will normally cause the DR Register state machine to change state. > Subsequent actions are determined by that state machine. > > The RFC, imo, doesn't really specify if you should do DR every hello > received or not. It implies > the original code prior to ee83d33acd....
I read these specs by finding a deterministic function from state to who is DR, and correct code ensures that all sequences of actions compute the function. So I don't follow "must do DR election on hello received"; I see it as "after a hello is received, the current value of DR must be correct". If the hello is from someone already a neighbor and has the same priority as the previous hello, and if the DR value is correct before receipt, then I'd expect it to still be correct. It may be true both that rerunning the election code resolves a prior issue and that the right fix was to find and remove the error in maintaining the DR under some transition. One thought is to add a "compute DR and assert if different" function and for debugging enable it; that should find the bug.
pgpOoaCeCHlZu.pgp
Description: PGP signature
_______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
