OSPF DR/BDR election

Sam-CCNP · ‎05-25-2023

Hi,

I have been doing packet captures and debugs (debug ip ospf adj and lsa-generation) on a 3-router OSPF lab in CML and noticed that DR/BDR elections are taking place several times during the formation of the new adjacency between the (existing) DR and BDR, and the new DROTHER that comes up.

The first election is after 2-WAY is established, which makes sense as per the interface state machine.

But then approximately 10 seconds after the adjacency goes to Full, another two elections take place on both the DR and BDR and I can't figure out why. The DROTHER only has a single election take place immediately after 2-WAY is established, and that is it - which is what I would expect of all three routers.

I have re-run the lab several times, and the result is always the same (logs are below).

*May 25 12:58:30.568: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on GigabitEthernet0/0 from LOADING to FULL, Loading Done
<omitted>
*May 25 12:58:39.348: OSPF-1 ADJ Gi0/0: Neighbor change event
*May 25 12:58:39.348: OSPF-1 ADJ Gi0/0: DR/BDR election
*May 25 12:58:39.348: OSPF-1 ADJ Gi0/0: Elect BDR 1.1.1.1
*May 25 12:58:39.348: OSPF-1 ADJ Gi0/0: Elect DR 2.2.2.2
*May 25 12:58:39.349: OSPF-1 ADJ Gi0/0: DR: 2.2.2.2 (Id)
*May 25 12:58:39.349: OSPF-1 ADJ Gi0/0: BDR: 1.1.1.1 (Id)
*May 25 12:58:39.349: OSPF-1 LSGEN: Scheduling rtr LSA for area 0, build flag 0x41 (from 0x30484D5)
*May 25 12:58:39.349: OSPF-1 ADJ Gi0/0: Neighbor change event
*May 25 12:58:39.349: OSPF-1 ADJ Gi0/0: DR/BDR election
*May 25 12:58:39.349: OSPF-1 ADJ Gi0/0: Elect BDR 1.1.1.1
*May 25 12:58:39.349: OSPF-1 ADJ Gi0/0: Elect DR 2.2.2.2
*May 25 12:58:39.350: OSPF-1 ADJ Gi0/0: DR: 2.2.2.2 (Id)
*May 25 12:58:39.350: OSPF-1 ADJ Gi0/0: BDR: 1.1.1.1 (Id)
*May 25 12:58:39.350: OSPF-1 LSGEN: Scheduling rtr LSA for area 0, build flag 0x41 (from 0x30484D5)

The only reason I can see that this might occur - based on RFC2328, 9.2 Events causing interface state change - is when:

NeighborChange
o Bidirectional communication has been established to a neighbor. In other words, the state of the neighbor has transitioned to 2-Way or higher.

But that already occurred once.

Any help explaining this behavior would be appreciated.

Thanks,

Sam

David Ruess · ‎05-25-2023

Hello,

When routers come up and have OSPF initialized (router ospf <#>) they have about 40 seconds where they are all trying to figure out who the DR/BDR are. Initially they each assume they are the DR and send communications on the wire saying such. Then once they receive the hellos from other routers they see who the real DR/BDR are. That being said the state of what each router is can change whole they figure things out. The old adage of "OSPF DR election is not pre-emptive" is mostly true. During that 40 seconds it IS pre-emptive and can change while the messages settle in.

That 40 seconds is the Wait timer.

If you do the lab again and bring up just 2 routers to elect the DR and BDR, wait more than the 40 seconds and bring up the 3rd router the 3rd router will try to say its the DR initially when it come sup but is subsequently silenced by the real DR.

Hope that helps

-David

Sam-CCNP · ‎05-26-2023

Dear David,

Thank you for responding, and yes, that is what I did. To clarify.....

I brought up R2 (DR) and R1 (BDR) and then waited for them to reach FULL adjacency with each other (after 40-second wait period there was the DR/BDR election) and this was confirmed using sh ip ospf nei, plus from observing debugs and packet captures. Then several minutes later, I brought up R3, which did not wait for 40 seconds because it received a hello from a neighbor stating that it was the DR/BDR. The logs you see above are from the DR (the BDR was the same).

Thanks again for the assistance.

MHM Cisco World · ‎05-26-2023

check below

Sam-CCNP · ‎05-26-2023

Hi,

Thanks for responding and, as per my response to David above....

I brought up R2 (DR) and R1 (BDR) and then waited for them to reach FULL adjacency with each other (after a 40-second wait period there was the DR/BDR election) and this was confirmed using sh ip ospf nei, plus from observing debugs and packet captures. Then several minutes later, I brought up R3, which did not wait for 40 seconds because it received a hello from a neighbor stating that it was the DR/BDR. The logs you see above are from the DR (the BDR was the same).

Thank you for your help.

MHM Cisco World · ‎05-26-2023

when you add R3 you dont see new election ?

Sam-CCNP · ‎05-26-2023

Hi,

Thanks very much for responding so quickly.

Yes, I do, on all three routers a DR/BDR election happens after 2-way establishment, as I would expect. However, on the DR and BDR, a further two elections take place - the ones I can't explain. Full log below is from the DR:

*May 26 10:04:08.506: OSPF-1 ADJ Gi0/0: 2 Way Communication to 3.3.3.3, state 2WAY
*May 26 10:04:08.507: OSPF-1 ADJ Gi0/0: Neighbor change event
*May 26 10:04:08.507: OSPF-1 ADJ Gi0/0: DR/BDR election
*May 26 10:04:08.507: OSPF-1 ADJ Gi0/0: Elect BDR 1.1.1.1
*May 26 10:04:08.507: OSPF-1 ADJ Gi0/0: Elect DR 2.2.2.2
*May 26 10:04:08.507: OSPF-1 ADJ Gi0/0: DR: 2.2.2.2 (Id)
*May 26 10:04:08.507: OSPF-1 ADJ Gi0/0: BDR: 1.1.1.1 (Id)
*May 26 10:04:08.508: OSPF-1 LSGEN: Scheduling rtr LSA for area 0, build flag 0x 41 (from 0x30484D5)
*May 26 10:04:08.508: OSPF-1 ADJ Gi0/0: Nbr 3.3.3.3: Prepare dbase exchange
*May 26 10:04:08.508: OSPF-1 ADJ Gi0/0: Send DBD to 3.3.3.3 seq 0x14D9 opt 0x5 2 flag 0x7 len 32
*May 26 10:04:09.009: OSPF-1 LSGEN: Build router LSA for area 0, router ID 2.2.2 .2, seq 0x80000005
*May 26 10:04:13.064: OSPF-1 ADJ Gi0/0: Send DBD to 3.3.3.3 seq 0x14D9 opt 0x5 2 flag 0x7 len 32
*May 26 10:04:13.064: OSPF-1 ADJ Gi0/0: Retransmitting DBD to 3.3.3.3 [1]
*May 26 10:04:13.765: OSPF-1 ADJ Gi0/0: Rcv DBD from 3.3.3.3 seq 0x1E02 opt 0x 52 flag 0x7 len 32 mtu 1500 state EXSTART
*May 26 10:04:13.765: OSPF-1 ADJ Gi0/0: NBR Negotiation Done. We are the SLAVE
*May 26 10:04:13.765: OSPF-1 ADJ Gi0/0: Nbr 3.3.3.3: Summary list built, size 3
*May 26 10:04:13.765: OSPF-1 ADJ Gi0/0: Send DBD to 3.3.3.3 seq 0x1E02 opt 0x5 2 flag 0x2 len 92
*May 26 10:04:13.967: OSPF-1 ADJ Gi0/0: Rcv DBD from 3.3.3.3 seq 0x1E03 opt 0x 52 flag 0x1 len 52 mtu 1500 state EXCHANGE
*May 26 10:04:13.967: OSPF-1 ADJ Gi0/0: Exchange Done with 3.3.3.3
*May 26 10:04:13.967: OSPF-1 ADJ Gi0/0: Send LS REQ to 3.3.3.3 length 36
*May 26 10:04:13.967: OSPF-1 ADJ Gi0/0: Send DBD to 3.3.3.3 seq 0x1E03 opt 0x5 2 flag 0x0 len 32
*May 26 10:04:14.166: OSPF-1 ADJ Gi0/0: Rcv LS UPD from Nbr ID 3.3.3.3 length 76 LSA count 1
*May 26 10:04:14.166: OSPF-1 ADJ Gi0/0: Synchronized with 3.3.3.3, state FULL
*May 26 10:04:14.168: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on GigabitEthernet0 /0 from LOADING to FULL, Loading Done
*May 26 10:04:14.168: OSPF-1 LSGEN: Scheduling rtr LSA for area 0, build flag 0x 51 (from 0x3076298)
*May 26 10:04:14.169: OSPF-1 LSGEN: Scheduling network LSA on GigabitEthernet0/0 , build flag 0x40 (from 0x30762F9)
*May 26 10:04:14.174: OSPF-1 ADJ Gi0/0: Rcv LS REQ from 3.3.3.3 length 60 LSA count 3
*May 26 10:04:14.669: OSPF-1 LSGEN: Build router LSA for area 0, router ID 2.2.2 .2, seq 0x80000006
*May 26 10:04:14.669: OSPF-1 LSGEN: Build network LSA for GigabitEthernet0/0, ro uter ID 2.2.2.2
*May 26 10:04:15.410: OSPF-1 ADJ Gi0/0: Neighbor change event
*May 26 10:04:15.410: OSPF-1 ADJ Gi0/0: DR/BDR election
*May 26 10:04:15.410: OSPF-1 ADJ Gi0/0: Elect BDR 1.1.1.1
*May 26 10:04:15.411: OSPF-1 ADJ Gi0/0: Elect DR 2.2.2.2
*May 26 10:04:15.411: OSPF-1 ADJ Gi0/0: DR: 2.2.2.2 (Id)
*May 26 10:04:15.411: OSPF-1 ADJ Gi0/0: BDR: 1.1.1.1 (Id)
*May 26 10:04:15.411: OSPF-1 LSGEN: Scheduling rtr LSA for area 0, build flag 0x 41 (from 0x30484D5)
*May 26 10:04:15.411: OSPF-1 ADJ Gi0/0: Neighbor change event
*May 26 10:04:15.411: OSPF-1 ADJ Gi0/0: DR/BDR election
*May 26 10:04:15.412: OSPF-1 ADJ Gi0/0: Elect BDR 1.1.1.1
*May 26 10:04:15.412: OSPF-1 ADJ Gi0/0: Elect DR 2.2.2.2
*May 26 10:04:15.413: OSPF-1 ADJ Gi0/0: DR: 2.2.2.2 (Id)
*May 26 10:04:15.413: OSPF-1 ADJ Gi0/0: BDR: 1.1.1.1 (Id)
*May 26 10:04:15.413: OSPF-1 LSGEN: Scheduling rtr LSA for area 0, build flag 0x 41 (from 0x30484D5)
*May 26 10:04:15.911: OSPF-1 LSGEN: Rate limit LSA generation for 1/2.2.2.2/2.2. 2.2
*May 26 10:04:19.669: OSPF-1 LSGEN: Build router LSA for area 0, router ID 2.2.2 .2, seq 0x80000007
*May 26 10:04:53.967: OSPF-1 ADJ Gi0/0: Nbr 3.3.3.3: Clean-up dbase exchange

Thanks.

Sam

MHM Cisco World · ‎05-26-2023

check below

Sam-CCNP · ‎05-26-2023

Hi,

I'm not quite sure I understand your point.

In my scenario, R1 and R2's DR election has already taken place and the network has been in a stable state for several minutes (R2 = DR, R1 = BDR). R3 joins, and another election takes place on all 3 routers (as expected), which results in R3 becoming a DROTHER, which I also expect, even if the priority is set higher because there is no preemption.

But on R1 (BDR) and R2 (DR) a further two elections take place - as per indicated in the debug output - but I am unsure as to what has triggered them and is ultimately what I am trying to understand.

Thank you again for the help.

Sam

MHM Cisco World · ‎05-26-2023

R3 joins, and another election takes place on all 3 routers (as expected), which results in R3 becoming a DROTHER <<- add R3 but change the interface OSPF priority to highest value , if it real elect then R3 must elect as new DR.
if not then what we see in debug is OSPF R1 and R2 inform R3 that this IP for ELECETED DR/BDR no need to start new election.

David Ruess · ‎05-30-2023

Hello,

This output makes it seem like there is a neighbor change on the interface. Like maybe its flapping the interface or neighborship.

Can you provide the full output of the following commands for all 3 routers and label as such. You can put them in text files if its easier.

sh ip ospf interface

show run | sec router ospf

-David

MHM Cisco World · ‎05-26-2023

check below

Sam-CCNP · ‎05-26-2023

Hi,

The DR/BDR election itself is not what I am trying to understand.

What I am trying to understand, is why additional elections take place AFTER loading is complete. Even in your image, the election you have highlighted in your log is the same. i.e. it takes place after Full adjacency has been reached.

So, my question is "Why do additional election(s) take place AFTER the adjacency is already FULL?"

Thanks,

Sam

MHM Cisco World · ‎05-26-2023

OK, so why the election is happened after Router go to Full status.
the DR/BDR use Hello message
here you can see R2 not elect after full but R1 elect after full
so R2 receive Hello from R1 and finish the election process and send Hello confirm to R1, R1 also finish elect process and go to Full and then receive the confirm from the R2 (the second elect appear in debug)
there is no issue here.
and for more detail check the wireshark see the hello exchange and see that elect in one side appear after full when it receive hello message from neighbor

Sam-CCNP · ‎05-26-2023

Hi,

Thanks very much for replying.

Your above answer focuses on R1 and R2, but as per my scenario, they have already been running a significant amount of time and the network is already in a stable state (only hello packets being sent back and forth).

It's the addition of R3 (at a later time) and AFTER it establishes FULL adjacencies with R1 and R2, that I'm seeing additional elections on R1 (BDR) and R2 (DR), and that is the part I am trying to understand.

I'm going to do some more reading and labbing, and if I have an explanation, I'll post it here.

Thanks again for your assistance.