Understanding OSPF DR/BDR Concept

[network_geek]

Hi All,

I have made a lab in which I am testing OSPF on a broadcast segment. Whenever I restart a DROther or BDR in my lab and capture packets I can see that the Database Descriptor packets are shared by a DROther and then LS updates are being shared by DR but there was no LS Request message being generated.

Can anyone confirm is this the expected behavior or am I missing on something?

The topology is very simple and attached. R5 is the DR having the highest loopback address and R4 being the BDR.

[Giuseppe Larosa · Accepted solution]

Hello @network_geek ,

>> then LS updates are being shared by DR but there was no LS Request message being generated.

in a broadcast network the OSPF DR acts like a "proxy":

a DRother sends to ALLOSPFDR routers on link to 224.0.0.6 a new LSA

The DR receives the update(s) and forward them to all other routers using ALLOSPF routers on link 224.0.0.5.

Full adjacency is built with DR and BDR only so if you restart a DRother it will come back it will join the broadcast domain accepting the current OSPF DR and BDR and then it progresses from two Way to other states only with DR and BDR devices.

The "proxy" action is needed because the DR will know new info carried by the new OSPF neighbor and  it wil pass all the new LSAs to the other devices on segment using 224.0.0.5.

These updates are not solicited as the other devices cannot know when DR and the new OSPF neighbor have reached the FULL state.

What you see is normal and it is required by DR/BDR role.

DR and BDR avoids the need of full mesh of OSPF adjacencies  saving on CPU, bandwidth resources in exchanging the DB with everyone.

Hope to help

Giuseppe

[network_geek]

Hi @Giuseppe Larosa,

Thank you for your detailed answer but I am still confused as to why I am seeing a DROther sending DataBase Descriptors(DBDs) to this newly booted router(BDR) in our case. Any explanation towards it could prove really helpful.

[Giuseppe Larosa]

Hello @network_geek ,

first of all you should describe your test method:

is the newly booted device a device that was already the BDR before rebooting it ?

You can use debug ip ospf adjacency on multiple devices to see also if BDR election takes place.

to see when the newly booted device becomes BDR  ( eventually it resumes BDR role)

Second, we should see the whole packet capture taken from the point of view of the DRother that is sending the DBDs to newly booted device.

DBDs packets should be sent as unicast.

As soon as the rebooted node comes back on line and it takes the BDR role, each DRother has to create and adjacency with it.

So you may be seeing the loading phase of the steps to adjacency to the new BDR from the point of view of a DRother.

The things are a little more complex if the device is really a new one and it has never been a BDR before.

This specific aspect has been discussed many times in the forum.

In simple words can the BDR role be pre-empted by a new router ?

All of us agree on the fact that the DR role cannot be pre-empted by a new device. About the BDR there are two different opinions: some think that also the BDR is protected by pre-emption so a new device cannot become BDR some other people like the writing guy thinks that a new device with better parameters ( an higher priority ) can pre-empt the BDR, because the BDR is a Backup Designated Router.

Hope to help

Giuseppe

[network_geek]

Hi @Giuseppe Larosa,

The device under discussion was BDR before it was rebooted. You may refer to the figure which in this case is R4(Loopback IP: 4.4.4.4). I could see unicast messages in which DBDs were exchanged between R3 and R4(after it had become stable and OSPF process was initiated). To further my point, I expected only R5 to send DBD packets but in this case it wasn't.

After the initial exchange of DBDs the router polled DR for any reliable updates, which is completely normal under these conditions, but for R3(DROther) to send DBDs to R4 warranted some more attention.

[Giuseppe Larosa]

Hello @network_geek ,

I don't see any topology attached if this is a packet trace project to be able to attach it you need to zip it.

But I do not have packet tracer.

Hope to help

Giuseppe

[network_geek]

Hi @Giuseppe Larosa,

I might have forgotten to attach the topology information. Please see now if you could refer to one with this message.

[Giuseppe Larosa]

Hello @network_geek ,

I see your network diagram but you should add the roles of each of the depicted routers

R2

R3

R4

R5

who is the DR ? who is the BDR ?

what router have you rebooted / restarted ?

From what router are you making packet capture to see the DBD packet sent to the just re..joined BDR ?

Hope to help

Giuseppe

[network_geek]

Hi @Giuseppe Larosa: My sincere apologies for not understanding my own topology and how it would react around a failure. My router-IDs are same as their router number(R1 being 1.1.1.1 for example). In this case when R4 goes down, R3 will be elected as BDR. Now just to put this discussion to bed, would a BDR share its DBDs with a newly rebooted/configured router or is it just out of the blue?

In normal conditions, I would expect R5 to be the DR, R4 to be the BDR and all others to be DROthers. I am using equal cost links and using default priorities. I had rebooted R4(BDR) in this case. And I took captures on R4's outgoing interface to the Switch.

[Giuseppe Larosa]

Hello @network_geek ,

thanks for your clarification.

>> My router-IDs are same as their router number(R1 being 1.1.1.1 for example). In this case when R4 goes down, R3 will be elected as BDR. Now just to put this discussion to bed, would a BDR share its DBDs with a newly rebooted/configured router or is it just out of the blue?

What you see is correct 100% and it confirms that also BDR role is protected from pre-emption.

Initial state:

being all OSPF priority equal to default values the highest OSPF RID is elected DR so it is R5 5.5.5.5/32, the second best is elected BDR so it is R4 4.4.4.4.

Failure scenario:

R4 current BDR is rebooted or its port is shutdown for more then 40 seconds

the BDR is missing after 40 seconds R4 is declared dead and this triggers a new election DR remains the same and R3 is elected as new BDR.

Recovery Scenario:

R4 comes back on line even if it has an highest OSPF RID it cannot trigger a new election ( this is the part I'm most interested in)

When R4 comes up in received OSPF hellos it finds the OSPF DR and OSPF BDR fields filled with 5.5.5.5 and 3.3.3.3.

As a DRother R4 must progess from two way state to full state with both R5 and R3.

>> I had rebooted R4(BDR) in this case. And I took captures on R4's outgoing interface to the Switch.

OK the synchronization process involves only two devices at the same time.

In other words R4 will reach FULL state with R5 and R3 but not concurrently.

So it is absolutely correct to see DBD packets exchanged between R4 and R3 the new BDR.

This is not an issue and it is part of normal operations.

doing a

show ip opf neighbor

on R4 you will see at end :

R5 5.5.5.5  state FULL  role DR

R3 3.3.3.3 state FULL role BDR

R2 2.2.2.2 state TwoWay role DRother

Again this is normal

Hope to help

Giuseppe