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.
The steps that Andrew is mentioning here actually come from the RFC. Specifically, section 9.4 Electing the Designated Router. Indeed the BDR is elected first, according to the RFC. The steps are numbered in the RFC, and step 2 chooses the BDR, and step 3 chooses the DR.
But the RFC also states the following:
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.
Finally, some additional resources that may be helpful can be found here:
The truth is that not all vendors adhere absolutely to all mechanisms that are described in the RFC. They do so only to the point where they are compatible with other vendors. They often choose to add their own additional mechanisms, enhancements, and rules that suit them best. So it is not unusual for Juniper, or other vendors, to veer away from absolute compliance.
Believe it or not, this is expected behavior. Remember that the DR/BDR election is not preemptive. That means that if there is a stable OSFP topology, and a DR and BDR have already been elected, a new election will not be triggered simply by changing the router ID.
Since a router with a lower router ID has become DR, that simply means that the DR/BDR election took place before the higher router ID was configured on the other router.
An OSPF topology will reevaluate the DR/BDR election only if another election is triggered. An election is triggered under specific circumstances. Take a look at this NetworkLessons note for more info.
Thank you for your response, In the note it says that Restarting OSPF Process will cause DR election to reoccur, does this mean in every time if I clear OSPF process, DR and BDR election will take place?
Yes, you’re correct. When you restart or clear the OSPF process, it resets the OSPF adjacency, effectively causing a new DR/BDR election. This is because the OSPF routers go through the full process of establishing neighbor adjacencies, which includes the DR/BDR election process. Keep in mind however that if you are clearing/resetting the OSPF process on a router that is a DROTHER, then the already established DR and BDR will remain, regardless of the priorities or router IDs that have been configured. The restarting of the OSPF process must take place on a router that is already a DR or BDR for the reelection to affect that particular router.
In a stable OSPF network, a BDR will maintain the same OSPF database and adjacencies as the DR in a network segment. The only difference between how the DR and BDR operate is that the BDR does not generate network LSAs during its operation.
Now having that in mind, how long does it take for a failover to occur? In other words, as soon as the DR fails, how long does it take for the BDR to become the DR?
Well, this is subject to the hello timer and dead interval settings.
If the current DR fails (e.g., due to power failure, link failure, or router shutdown), it stops sending Hello packets and ceases communication with other routers. OSPF routers in the segment detect the absence of Hello packets from the DR, but will only react to this after the dead interval elapses which is typically 40 seconds by default.
Because the DR and BDR maintain an adjacency, as soon as this adjacency fails after the dead timer elapses, only then will the BDR transition to a DR. So, to answer your question, the BDR will take over once the dead timer has expired. Once that has expired, the BDR becomes the DR and begins sending out Type 2 LSAs informing all routers that it is now the DR.
This may seem like a long time, but it’s not. OSPF will continue to route traffic based on established routes. If the DR failure results in a topology change, even that will be subject to the hello and dead interval timers. If this isn’t sufficient for your network, you will need to adjust the OSPF timers accordingly.
Can you please be brief about this? It’s quite difficult to comprehend this concept. I labbed this without stub area the forwarding address was still zero though it has multiple path to external routes.
If i make the external learned routes ares as NSSA the forwarding address become non-zero.
couldnt understand the differences and what influences the FA here ?
For reference, the text you shared comes from our NetworkLessons note on the topic of OSPF Forwarding Address. I have since updated this note to include more information and give a more complete explanation, so you can check that out.
In the meantime, let me just say that there are specific conditions that must be met for the forwarding address to become non-zero. I created another NetworkLessons note that gives such a scenario, and you can find a link to that at the bottom of the note above…
