OSPF DR/BDR Election explained

Lessons Discussion
143

why does on the video says that router-id will influence the DR/BDR election rather than Ospf priority?

144

Hello Don

The election process for the DR and BDR begins with the OSPF priority. By default, the OSPF priority is the same on all OSPF routers. Therefore, it is the OSPF router with the highest router ID that becomes the DR. So, in the video, Rene is assuming that the priority is the same for all routers.

For a more detailed look at this election process, take a look at this NetworkLessons note:

https://notes.networklessons.com/ospf-dr-bdr-election-process

I hope this has been helpful!

Laz

1 Like
145

we know for the point to point network we don t have OSPF DR/BDR election. but why ??

146

Hello Azondekond

You can configure a particular interface to operate as a point-to-point OSPF topology. This will indeed result in no DR/BDR elections. Why?

Well, remember that DR/BDR elections take place on a per-network-segment basis. In other words, an election takes place between OSPF routers that exist within a broadcast domain, or within a VLAN, or within a single subnet. The OSPF routers will have interfaces with IPs in the same subnet. The purpose of the election is to minimize the number of neighbor relationships that are necessary within such a topology. Such an arrangement is found only when multiaccess technologies are used, such as Ethernet. This is all detailed in the lesson.

However, if you have a point-to-point link between two OSPF routers, then by definition you know that there can only be two OSPF routers on the subnet of that particular link. Serial connections are point-to-point connections that can only have a single device on the other end, unlike Ethernet, which can potentially have hundreds.

So when we define a particular link of a router as a point-to-point network, no DR/BDR elections need to take place because, by definition, only a single OSPF peer can exist on that link. Allowing elections to take place would be a waste of CPU and memory since such a mechanism has no purpose on a point-to-point link.

I hope this has been helpful!

Laz

147

Hi Andrew, There is one query regarding the election of DR/BDR.

The first point is all routers should’ve different R’ids in case OSPF neighborship to be started or established, in case we have it same for 2 or more routers then Neighborship will not form then why do we have criteria after Router ID? If neighborship is not forming then loopback and Highest IP address must not come into the picture.

I think it can be used in this scenario:-

““Because of this, two OSPF routers with the same router ID will not become neighbors but you could still have duplicated router IDs in the network with routers that are not directly connected to each other.””

148

Hello Ajeet

The way that Andrew states this list in his post can be a bit misleading. Let me try to clarify.

Strictly speaking, the DR/BDR election takes place with only two criteria, with the following order of precedence:

  1. The OSPF priority is examined and the highest wins the election. If there is a tie, then…
  2. The highest router ID is used.

That’s it.

Now because the router ID MUST be unique, it will always be a tiebreaker. Now, why did Andrew mention loopback and IP address on an interface? Well, these are the criteria used to determine the router ID on a device. So a router ID is chosen based on:

  1. a manually configured router ID value
  2. the highest loopback address
  3. the highest IP address on an interface of the router

For more info, check out this NetworkLessons Note on OSPF DR/BDR election criteria.

I hope this has been helpful!

Laz

PS I’ve updated Andrew’s answer to be clearer. Thanks!

1 Like
149

Thanks Lazaros, I got the answer.

1 Like
150

Good Lesson!

Thank you Mr. Rene!

1 Like
151

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 ?

152

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

153

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?

image
image1572×668 77.5 KB

154

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

155

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 .

156

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

157

it makes sense . thanks for the clarification

1 Like
158

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

159

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

160

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:

image
image493×559 43.8 KB

R1’s neighbour:

R1-show-neighbor
R1-show-neighbor846×82 10.6 KB

R1’s debug output after R3 is turned on:

image
image924×924 134 KB

R2’s neighbor:

R2-show-neighbor
R2-show-neighbor847×82 9.87 KB

R2’s debug output after R3 is turned on:

image
image893×907 126 KB

R3’s neighbors after adjacency completed:

R3-show-neighbor
R3-show-neighbor868×105 13.2 KB

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

161

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

162

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