Yes, that makes sense. The question is, do you call that an election? Take a look at your paragraph again:
So when that OSPF router “accepts” the current DR and BDR, is that an election? That’s where I believe the confusion lies.
Yes, I understand. According to the RFC, that should not happen, but remember, as I mentioned before, Cisco’s implementation does not necessarily conform exactly to the RFC. It could be that Cisco has a “reaffirming” process, where the DR and BDR are rechecked in an election, as stated in the debugs, as soon as the neighbor state reaches FULL. Only if we do research concerning CIsco’s implementation and the inner workings of that operation can we find further information about why that is.
I have another (completely different) question regarding DR/BDR election which relates to the neighbor x.x.x.x priority <number> command and its use in an NBMA network.
I don’t understand its purpose as the priority of neighbor is always learned in the hello packet anyway - or am I wrong? Plus being able to set it yourself means it could (accidentally) be set differently on routers causing all sorts of inconsistent results.
The neighbor command is used for nonbroadcast networks, and the priority keyword applies only to NBMA interfaces. It does not apply to point-to-multipoint interfaces.
Note that no DR or BDR is elected in OSPF point-to-multipoint non-broadcast networks because each link is treated as a point-to-point link. Thus, in these networks, the DR/BDR fields in the Hello packets are not meaningful and are set to 0.0.0.0.
If you issue the ip ospf priority command in this environment, it will make no difference since the corresponding fields in the hellos will remain unchanged.
It is for this reason that you need to use the priority keyword in the neighbor command to indicate the priorities that can be used to determine which router will become the DR and which the BDR.
It was my understanding that neighbor priority command is valid only on NBMA networks (not point-to-anywhere networks because there is no DR/BDR) and is (supposedly) used to influence DR/BDR election.
I was confused as to its purpose as hellos contain the priority anyway and it looks like I am not the only person who has questioned the purpose of its existence:
Yes, the neighbor command is valid only on NBMA and point to multipoint networks. If you try to issue it on a broadcast network (which is the default for Ethernet) you will get something like this:
R1(config-router)#neighbor 192.168.12.2 priority 5
% OSPF: Configured Nbr 192.168.12.2 is incompatible with OSPF network type on GigabitEthernet0/1
When applied to an NBMA or point to multipoint network, the neighbor command is available and can be issued. The addition of the priority keyword and subsequent priority value, will not have any effect if the network type does not have DR/BDR elections, but will affect NBMA for example.
Concerning hellos, you are correct, and the Cisco Community posts you reference show a comprehensive explanation of the various scenarios involved with experimentation.
It’s worth noting here that OSPF and the intricacies involved in how it works and how Cisco has implemented it can generally change over time. Some IOS and platform versions actually allow you to use the neighbor command on a broadcast network type. In addition, you will find that CIsco doesn’t always stick to the exact specifications described in the RFC. One particular example is the use of point-to-multipoint NBMA and point-to-point non-broadcast network types which are not defined in the RFC.
In any case, ultimately the best way to determine the behavior of the protocol is to experiment with it as was done in the community post you shared, which sheds the most light on how it operates.
"On LANs, DR and BDR have to be elected. Two rules are used to elect a DR and BDR:
router with the highest OSPF priority will become a DR. By default, all routers have a priority of 1.
if there is a tie, a router with the highest router ID wins the election. The router with the second highest OSPF priority or router ID will become a BDR."
Thanks for your feedback. I will let Rene know to take a look and see if any modifications or clarifications need to be made. For a more detailed explanation of the actual election process itself, take a look at this NetworkLessons note on the DR/BDR election process.