What are DR, BDR, DR other and election rules

27

DR means designated router. BDR means backup designated router. DR Other indicates a device that is neither a DR or a BDR. The DR advertises link-state advertisements (LSAs) to all the devices in the network.

The DR election rules are as follows:

When going Up, an interface sends Hello messages and enters the waiting state. In the waiting state, a waiting timer is triggered. The waiting timer duration is the same as the dead timer duration. By default, the waiting timer duration is 40 seconds, which cannot be changed.
Before the waiting timer is triggered, sent Hello messages carry no DR or BDR field. In the waiting state, if a received Hello message carries the DR and BDR fields, the DR and BDR are accepted directly without any election triggered, and neighbor state synchronization starts, directly exiting the waiting state.
Assume that a DR and a BDR exist on the network. Any device newly connected to the network will accept the DR and BDR that exist on the network regardless of the router ID of the device.
If the DR fails and goes down, the BDR takes over the role of the DR and the remaining devices whose priority is greater than 0 compete to become the new BDR.
DR election rules are used to elect a DR only when devices with different router IDs or configured with different DR priorities are started at the same time. The election rules are that the device with the highest DR priority is elected as DR and the device with the second highest DR priority as BDR. A device with a DR priority of 0 can be a DR Other only. In the case of the same priority, the device with the greatest router ID is elected as DR, the device the second greatest router ID becomes the BDR, and other devices are DR Others.

Other related questions:
OSPF DR and BDR election rules
On broadcast and NBMA networks, the DR and BDR selected by OSPF are electoral, lifelong, and hereditary. Electoral DR and BDR are not designated manually. Instead, they are elected by all the routers on a network segment. When the DR and BDR are elected on a network segment and are lifelong, each router newly added to the network segment does not replace the existing the DR or BDR even if the router has a higher priority. If the DR and BDR are hereditary, the BDR replaces the DR when the DR is faulty and other routers compete to be the BDR. The process of DR/BDR election on a broadcast or an NMBA link is as follows: 1. After interfaces on a device are Up, the device sends Hello packets and enters the Waiting state. The waiting timer value is the same as that of the dead timer. The default value is 40s and cannot be modified. 2. Before the waiting timer is triggered, the Hello packets sent by the device do not contain the DR and BDR fields. After the device enters the Waiting state, if it sends Hello packets containing the DR and BDR fields, it acknowledges the DR and BDR existing on the network and does not trigger an election. The device changes its state from Waiting and starts synchronization with a neighbor. 3. If the DR and BDR already exist on the network, an added device acknowledges the DR and BDR. In such a case, DR/BDR election is not performed even if this device has a largest router ID or top DR priority. 4. When the DR is Down due to faults, the BDR replaces the DR and another device of a priority higher than 0 becomes the new BDR. 5. DR election is performed only when devices with different router IDs or DR priorities start simultaneously. The election rules are as follows: The device with the highest priority functions as the DR, and the device with the second highest priority functions as the BDR. A device with the priority of 0 can only function as the DR Other. If all devices have the same priority, the device with the largest router ID functions as the DR, the device with the second largest router ID functions as the BDR, and the others as DR Others. For more information about OSPF DR election and BDR election, click 问鼎OSPF(2) .

ServiceCenter at the DR Site Is Faulty
If one ServiceCenter VM at the DR site is faulty or both the active and standby ServiceCenter VMs at the DR site are faulty, and services cannot be recovered after ServiceCenter is restarted, you can troubleshoot the faults by following the instructions provided in this section to recover the services. For details,seeServiceCenter at the DR Site Is Faulty,The applicable version is 3.0.9.

ServiceCenter at the DR Site Is Abnormal
If ServiceCenter at the DR site is abnormal, you need to perform the operations in this section to troubleshoot the fault and quickly restore services. For details,seeServiceCenter at the DR Site Is Abnormal,The applicable version is 3.0.9.

OceanStor 9000 disaster recovery (DR) method
OceanStor 9000 provides the InfoReplicator feature to recover data and services upon disasters.

DR Fails to Be Started After Disks Are Bound
1.Log in to the portal of FusionCompute at the production site. 2.Check whether there is a message stating that the DR fails after disks are bound. If yes, go to 3. If no, contact technical support. 3.Unbind disks and then bond them again or shut down the virtual machine and then restart it, ensuring that no failure message is displayed. 4.Perform the protected group to start DR.

If you have more questions, you can seek help from following ways:
To iKnow To Live Chat
Scroll to top