OSPF DR/BDR Election explained

Good Lesson!

Thank you Mr. Rene!

1 Like

I have a question here related to OSPF DR/BDR election. I have 2 routers and when I checked who is the DR and who is the BDR it shows me that both of them are DR and BDR is area 0.0.0.0 ? network is normal but what is the explanation of this behavior ?

Hello Ramy

There are a few things you should keep in mind about the DR/BDR elections.

  • First, remember that a DR/BDR election takes place on a per-segment basis. That means that a particular router may be a DR on one interface, and a BDR on another. Just saying an OSPF router is a DR is not enough information. We must know if it is a DR or a BDR on each OSPF adjacency it has on every interface.
  • Initially, all OSPF routers consider themselves DRs, and set the BDR to 0.0.0.0. That means that no BDR has yet been chosen. Once a neighbor relationship has been successfully achieved, then the DR and BDR for each segment should also have been chosen. If the BDR remains 0.0.0.0, then it is likely the neighbor adjacency has not been established. Use the show ip ospf neighbor command to ensure that the neighbor adjacency has been successfully created.

Use this information to continue your troubleshooting, and if you need further help, just let us know.

I hope this has been helpful!

Laz

I have a question related to ECMP

Router R6 advertises the prefix 172.10.3.0/24 using a routing protocol that supports ECMP. All routers are configured with an ECMP value of 4. All links shown in the diagram have the same cost. How many entries with a destination prefix of172.10.3.0/24 are in router R1’s routing table?

Hello Ramy

The quick answer is that R1 will have two routes in the routing table for 172.10.3.0/24, one via R2, and one via R3. If the routing protocol supports ECMP, and the metric to the destination is the same, then both will appear in the routing table.

One thing I didn’t understand is this:

What is an ECMP value? Are you talking about the variance command in EIGRP? Can you clarify so that we can help further?

I hope this has been helpful!

Laz

Hello Laz.
The ECMP used by OSPF . So the metric will be the cost . what will be the whole path through R2 and R3 ? . ECMP value of 4 means that all Routers are configured to support up to 4 Paths with equal cost and ECMP is enabled on all routers .
Also , if you can please explain further why 2 Paths ?

which two paths will be in the routing table of R1 ?
R1-R2-R4-R6
R1-R3-R5-R6
R1-R2-R5-R6
R1-R3-R4-R6

Thanks for your response .

Hello Ramy

Thanks for the clarification. By default, OSPF will install up to four paths in the routing table. The maximum-paths command is used under OSPF configuration mode to change this value anywhere from 1 to 32 paths.

Now the terminology can be confusing. The maximum-paths command will limit the number of routing table entries. Remember that a routing table tells the router the next hop to be used. You are correct that there are actually four possible paths as you stated in your post, but the routing table doesn’t care about what happens after the next hop. It only cares about the next hop.

So for your topology, even though there are indeed four possible routes from end to end that can be taken to reach 172.10.3.0/24, R1 really only has two choices as to where to send the packet, either to R2 or to R3. That’s why there will be two entries in the routing table and not four.

Now R2 and R3 each will have two entries in their routing tables as well, one to R4 and one to R5 since those are equal cost routes as well. However, R4 and R5 will each have only one route to the destination, via R6. Does that make sense?

I hope this has been helpful!

Laz

it makes sense . thanks for the clarification

1 Like

Hi (Laz),

I have a question that has come up after I did some labbing.

My scenario is this:

  1. I have routers R1 and R2 connected to a switch and I configure OSPF on them
  2. The DR/BDR election takes place and R2 is elected DR (higher RID) and R1 is elected the BDR
  3. Network is stable, with only hello packets going back and forth.
  4. Then, at a later time, I introduce R3.
  5. A 2-WAY state is established between R1-R3 and R2-R3, and, as expected a DR/BDR election takes place immediately on all three switches (R3 doesn’t wait for the 40s timer to expire because hello packets already contain a DR/BDR).

Everything so far is as expected, however, after a FULL adjacency is established between R2 (DR) / R1 (BDR) and R3 (DROTHER), two additional DR/BDR elections take place on both R2 and R1.

The result is the same because the DR/BDR have already been selected, but why they are being triggered is what is confusing me. RFC 2328, ‘9.2. Events causing interface state changes’ contains NeighborChange events that can trigger a BDR/DR election, but I can’t see how any apply to what I am witnessing.

I am seeing the elections using debug ip ospf adj.

Thanks very much.

Sam

Hello Samir

First of all, that behavior is a little bit unusual. If you have a topology where the DR/BDR are already established, and you add another router that does not have a higher priority (such as R3 in your case), an election is not triggered. R3 will send out a neighbor discovery with a value of 0.0.0.0 for the DR/BDR, but will receive a response letting it know that the DR/BDR is already established, and it has a better priority. This exchange is not considered an election. I assume that’s what’s happening in your case, but it’s just a matter of terminology.

But even if R3 had a higher priority, it should still not trigger an election. This is because in OSPF, DR/BDR elections are preemptive. This means that even if a new router with a higher priority or RID comes into the network after the DR and BDR have been elected, it will not take over the role of DR or BDR until one of them goes down. This is done to maintain stability in the network.

Can you give us some more information about this? When you say “two additional elections” are they minutes apart, seconds apart, when do they take place exactly? And is there any event that occurs at around that time? Also, you mention that these two additional elections take place on both R2 and R1, but not R3?? So the current DR and BDR reaffirm their statuses as DR and BDR and R3 does not participate in this? Are you sure they’re elections and not just an exchange of hello packets?

Indeed, the only events that should trigger a new election is if the current DR or BDR fails (their interface goes down) or if there is network instability, or if the OSPF process restarts. Beyond that, if it occurs, it may be due to hardware or software problems.

Let us know more info, and if you can share an example of the debugs you see, maybe we can help you out further.

I hope this has been helpful!

Laz

Hi Laz,

An election does appear to be taking place after 2-WAY is established (on all three routers), and as I understand it, that is correct - even though the DR/BDR will remain the same. Source: RFC 2328, 9.2. Events causing interface state changes, NeighborChange and Routing TCP/IP Volume 1 (second edition) P349-350: Figure 8-3, Table 8-1

But that’s not the part that confuses, it’s the elections that take place after a FULL adjacency is established between R3 and R1/R2. Topology and debug outputs (debug ip ospf adj) are below:

R1’s neighbour:

R1’s debug output after R3 is turned on:

R2’s neighbor:

R2’s debug output after R3 is turned on:

R3’s neighbors after adjacency completed:

For R3, the debug only shows the first DR/BDR after 2-WAY establishment (I do not have the output to hand), which makes sense based on my understanding. And the rest of the output, EXSTART->EXCHANGE->LOADING->FULL also makes sense.

It’s just those two elections that I don’t understand, and I can reproduce this at any time. Including by having R3 already running but its interface shutdown before being re-activated. the result is always the same.

I’m using EVE-NG with vIOS image extracted from CML.

Thanks,

Sam

Hello Samir

All things seem to indicate that this behavior is contrary to the OSPF RFC 2328 however, I was thinking about it a little bit deeper, and I have come to the following conclusion:

My first clue came from your statement:

An election does appear to take place, you say, which means the debugging on the Cisco router will state “DR/BDR election.” However, strictly speaking, under these circumstances, if a true election took place, the DR/BDR would actually change. Imagine this scenario based on your diagram:

Imagine R1, R2, are initially elected DR and BDR and R3 and R4 are DROTHERs. R1 goes down, and R2 becomes the DR, and a true election takes place making R3 the BDR. Now imagine R1 comes back up. If a true election were triggered, R1 should become the DR once again since it has the lowest router ID. However, it does not. R2 remains the DR and R3 the BDR.

From my understanding, in this situation, you see an election taking place based on the debugs. However, R2 remains the DR. Therefore no real elections have taken place. If they did, they must follow the process in section 9.4 of RFC 2328, meaning R1 should become the DR. So my conclusion is that even though the debugs state an election took place, strictly speaking according to RFC 2328 an election has not taken place. A neighbor state has changed, and hellos have been exchanged with the info about the newly recovered R1, but an election has not taken place.

Although not stated explicitly, the DR/BDR election is indeed non-preemptive, which means that a stable OSPF topology will not rerun an election if a new OSPF router joined a network segment. In section 9.4 of the RFC, there is no mention of re-running the process once it is complete and the network is stable. Similarly, in section 9.3, it is specified, once an interface state has trasitioned past “waiting” no further elections are mentioned. Similarly, in section 9.5, it states:

“If the router itself is not eligible to become Designated Router (i.e., it is not an eligible router or it is an end system), it must be included in the list (indicating that the router will not attempt to become Designated Router)”.

This again hints at the non-preemptive nature of the election.

If you do a search online, you will find that there is a general consensus, that OSPF is indeed non-preemptive.

Now, based on this, we come to the debugs you see and that you shared. I come to the conclusion that these are not real elections as stated in the RFC, however they are an output that Cisco has seen fit to include in their syslogs. They define a DR/BDR election as any new exchange of DR/BDR information. Although this exchange of information does indeed take place, as described in the RFC, it does not constitute an election. At best, it is simply a reaffirmation of the current DR and BDR, even if they don’t have the highest priority on the network.

I’d like to make it clear that all of this is just speculation, but it is based on the fact that we always take the RFC to supersede any and all other explanations. And remember, Cisco has implemented several features that deviate slightly from the standard OSPF as defined in RFC 2328 to enhance it including stub area types such as Totaly Stub and NSSA, OSPF authentication, and OSFP fast convergence features to name a few. So it is not unusual for Cisco to choose to deviate from this as well.

I hope this has been useful to you even just as food for thought.

Laz

Hi Laz,

Thanks for replying.

I also read section RFC 2328 section 9.4 but interpreted it differently. The way I understand it, an election does take place, it’s just that the process prevents preemption if routers are already claiming to be the DR and BDR. TCP/IP Vol1 page 343 has a clearer explanation, but the final paragraph at the bottom clarifies it best.

The election procedure of the DR and BDR is as follows:

  1. After two-way communication has been established with one or more neighbors,
    examine the Priority, DR, and BDR fields of each neighbor’s Hello. List all routers
    eligible for election (that is, routers with priority greater than 0 and whose neighbor
    state is at least two-way); all routers declaring themselves to be the DR (their own
    interface address is in the DR field of the Hello packet); and all routers declaring
    themselves to be the BDR (their own interface address is in the BDR field of the Hello
    packet). The calculating router will include itself on this list unless it is ineligible.

  2. From the list of eligible routers, create a subset of all routers not claiming to be the
    DR (routers declaring themselves to be the DR cannot be elected BDR).

  3. If one or more neighbors in this subset include its own interface address in the BDR
    field, the neighbor with the highest priority will be declared the BDR. In a tie, the
    neighbor with the highest Router ID will be chosen.

  4. If no router in the subset claims to be the BDR, the neighbor with the highest priority
    will become the BDR. In a tie, the neighbor with the highest Router ID will be chosen.

  5. If one or more of the eligible routers include their own address in the DR field, the
    neighbor with the highest priority will be declared the DR. In a tie, the neighbor with
    the highest Router ID will be chosen.

  6. If no router has declared itself the DR, the newly elected BDR will become the DR.

  7. If the router performing the calculation is the newly elected DR or BDR, or if it is no
    longer the DR or BDR, repeat steps 2 through 6.

In simpler language, when an OSPF router becomes active and discovers its neighbors, it
checks for an active DR and BDR. If a DR and BDR exist, the router accepts them. If there
is no BDR, an election is held in which the router with the highest priority becomes the
BDR. If more than one router has the same priority, the one with the numerically highest
Router ID wins. If there is no active DR, the BDR is promoted to DR and a new election is
held for the BDR.

So in my setup, R1 will remain the BDR as per step 3, because the newly activated R3 is not actually claiming to be the BDR. And R2 will remain the DR because of step 5, because, again, R3 is not claiming to be the DR.

I also did an experiment whereby R3, which was already running but not yet connected to the network and was announcing itself as the DR (in hello packets), was then connected to the network with R1 (BDR) and R2 (DR). An election did take place and the result was as I expected, i.e. R3 became the DR (higher RID) because of Step 5, and R1 remained the BDR because of step 3. R2 then became a DROTHER.

But that’s not the part I still haven’t figured out, it’s those other two elections. I have moved on to other areas of OSPF, but I’m hoping that the reason for them will become clear as I go more in-depth.

Thanks again.

Sam

Hello Samir

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 hope this has been helpful!

Laz

1 Like

Hi,

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.

Thanks,

Sam

Hello Samir

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.

I hope this has been helpful!

Laz

Hi Laz,

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:

Thanks.

Sam

Hello Samir

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.

I hope this has been helpful!

Laz

Hey Rene

I read the lesson and maybe i missed it but its not clearly explained how the election process happens

to reference my resource i went to https://study-ccna.com/designated-backup-designated-router/
and they have a great breakdown that you can maybe add to the page

"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."

Hello David

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.

I hope this has been helpful!

Laz