OSPF DR and BDR: The Election Belongs to the Interface

OSPF roles attach to interfaces, not to chassis. The same device can be the designated router on its LAN segment and nothing special on a tunnel, and those two facts do not contradict each other. Reading the role from the wrong interface is the most common reason a hub looks misconfigured when it is behaving exactly as designed.

The comparison that matters is between roles on one segment and roles across a router, and between what a backup does and what it does not do.

One election per segment

RFC 2328 elects a designated router and a backup designated router for each broadcast or NBMA network, not for a router and not for an area. Every interface participating in such a network runs its own election with its own priority and its own neighbour set. A chassis with three such interfaces can hold three different roles at once, which is why saying the hub is the DR is incomplete until the segment is named. Read the role from that interface's own neighbour output.

Two interfaces in the same area are still two elections. Area membership does not merge them.

What the backup is doing while it waits

A backup designated router is fully adjacent to the routers on its segment and keeps its database synchronised so it can take over without a new adjacency forming. What it does not do while acting as backup is originate that network's network-LSA, because the designated router owns that. Its flooding role is narrower than the designated router's at some steps, which is not the same as being silent or idle. Treating the backup as a router that does nothing until promotion produces some very confident and very wrong explanations.

The useful question is not what the backup refrains from doing, but whether the segment can deliver the OSPF packets the model requires. If a participant cannot exchange them with the others, the election result is a symptom of reachability rather than a cause.

Which model the tunnel actually uses

Broadcast and NBMA networks elect; point-to-point and point-to-multipoint networks do not, because there is no shared segment to elect on. On a hub-and-spoke overlay the effective model depends on how the tunnel interface is configured, so read it before interpreting any role. A tunnel that behaves like a broadcast segment and a tunnel that behaves like a set of point-to-point links produce completely different neighbour behaviour.

If the design wants the hub to hold the designated role, the model and the reachability have to support it together. A hub that cannot exchange the required packets with every participant will not become a useful designated router just because its priority is high. Check neighbour states and the underlying delivery first, then decide whether the role is wrong or merely unexpected.

Eligibility is per interface, and preemption is not automatic

Priority is set per interface, and a priority of zero removes that interface from both elections. Among eligible participants the winner is decided by priority and then by router ID, but a newly arrived router with a higher priority does not displace an existing designated router. That non-preemption is deliberate, and it surprises people who expect the highest priority to win immediately. If a particular router must hold the role, plan the order of events rather than assuming a configuration change takes effect on its own.

Excluding every spoke without providing another eligible participant also means there may be no backup at all.

Compare the two explanations honestly: a role read from the wrong segment, or a segment whose members cannot reach each other. The first is a design question and the second is a delivery question, and only one of them is repaired by editing a priority.