OSPF Deep Dive Part 1: Neighbor States, DR/BDR Election, and Network Types

Open Shortest Path First gets treated as a solved problem. Configure a process, add some networks, watch neighbors come up, done. That treatment is fine until the day a neighbor sticks in EXSTART on a Friday afternoon, or an ABR quietly stops advertising a route it advertised yesterday, and the “solved problem” turns out to have a dozen moving parts you never had to look at directly.

This series looks at all of them. It covers OSPF from the hello packet up through the SPF algorithm, area design, authentication, and IPv6, then does the same material again from the other direction: how Cisco IOS/IOS-XE, FortiOS, and Junos each implement it, where their defaults disagree, and how to read a stuck adjacency on each platform without guessing. Twelve parts, one lab topology carried through all of them.

The lab

Three routers, three vendors, two areas plus a third that only exists to force a virtual link:

• CORE-CSR — Cisco IOS-XE, router ID 10.0.0.1, sits in Area 0.
• BRANCH-FGT — FortiGate, router ID 10.0.0.2, sits in Area 0 and originates Area 1.
• EDGE-MX — Juniper Junos, router ID 10.0.0.3, sits in Area 0 and originates Area 2.

Area 0 is a triangle: CORE-CSR, BRANCH-FGT, and EDGE-MX all reach each other directly. Area 1 hangs off BRANCH-FGT and carries a small server subnet, 10.10.10.0/24, plus a static route redistributed at BRANCH-FGT for the NSSA discussion in Part 4. Area 2 hangs off EDGE-MX only, with no link of its own into Area 0, which means it has no way into the backbone without a virtual link stitched through Area 1. That gap is deliberate. It gives Part 4 something real to fix instead of a diagram-only example.

Every part references this same topology. By Part 12 all three routers are fully configured and something in that configuration is broken.

The hello protocol

OSPF neighbors don’t exchange routes first. They exchange hellos. A hello packet carries the originating router’s ID, the area ID of the interface it went out of, the subnet mask, the hello interval, the dead interval, the router’s configured priority, its view of the current DR and BDR, and a list of the neighbors it has already heard from.

Two routers only become neighbors if enough of that matches. Area ID has to match exactly. The subnet mask has to match (except on point-to-point and virtual links, which don’t carry a mask at all). Hello and dead intervals have to match. Authentication type and credentials have to match if configured. Get any one of those wrong and the two routers never progress past seeing each other’s hellos, because a hello mismatch doesn’t produce a neighbor in a broken state. It produces no neighbor at all.

The neighbor state machine

Once hellos agree, a neighbor relationship moves through a fixed sequence of states. Skipping a state, or getting stuck between two of them, is the single most common OSPF troubleshooting scenario, so it’s worth knowing exactly what each one means rather than treating “stuck” as one undifferentiated problem.

State	What just happened
Down	No hello received yet from this neighbor.
Attempt	NBMA-only. A hello was sent to a statically configured neighbor but nothing has come back.
Init	A hello arrived, but it didn’t list this router’s own router ID as a neighbor yet, so the relationship isn’t confirmed as two-way.
2-Way	The neighbor’s hello listed this router’s ID. Communication is now bidirectional. On broadcast and NBMA segments, DR/BDR election happens at this point. Routers that are neither DR nor BDR (DROTHERs) stop here with each other and never proceed to full adjacency — they only go further with the DR and BDR.
ExStart	The two routers negotiate who is master and who is slave for the database exchange, and agree on an initial DD sequence number. This is where MTU mismatches usually surface, because the first real problem in the exchange is disagreeing about how large a Database Description packet either side is willing to accept.
Exchange	Database Description (DBD) packets go back and forth, each one a summary of the sending router’s LSDB — headers only, not full LSAs. Each side compares the summaries against what it already has.
Loading	Link-State Request packets ask for the full LSAs that Exchange revealed were missing, and Link-State Update packets deliver them.
Full	Both routers have identical LSDBs for every area they share. The adjacency is complete and this neighbor now contributes to the SPF calculation.

A neighbor stuck at 2-Way with everyone is often correct behavior, not a fault, if this router isn’t the DR or BDR on a broadcast segment. A neighbor stuck at ExStart almost always means an MTU mismatch or, less often, a duplicate router ID. A neighbor that flaps between Full and Down repeatedly is a dead-timer or physical-layer problem, not a database problem, and chasing it in the LSDB wastes time that should go to the hello/dead interval and interface counters instead.

Why DR and BDR exist

On a point-to-point link, two routers only ever have one adjacency to worry about, so full mesh flooding is free. On a broadcast segment with ten routers, full mesh flooding means forty-five adjacencies, each one independently doing database exchange and independently re-flooding every LSA update to everyone else. That doesn’t scale, and it was never necessary in the first place, because all ten routers see the same LSAs regardless of which neighbor relayed them.

The Designated Router solves this by becoming the single point that every other router on the segment forms a full adjacency with. A Backup Designated Router forms a full adjacency with everyone too, purely so it can take over instantly if the DR dies, without a re-election delay. Every other router on the segment (DROTHER) forms only a 2-Way relationship with every other DROTHER, and a Full adjacency with just the DR and BDR. Ten routers now maintain roughly eighteen full adjacencies through the DR and BDR instead of forty-five, and every LSA update only has to be flooded to the DR, which floods it back out to everyone else once.

Election uses the priority field carried in every hello. Highest priority wins; a priority of 0 removes a router from the election entirely, marking it permanently DROTHER. Router ID breaks ties. Critically, the election is non-preemptive: once a DR is elected, a new router joining the segment with a higher priority does not trigger a re-election. It has to wait for the current DR to fail. This trips people up in the lab constantly, because bringing up a “better” router last and expecting it to take over immediately is exactly backwards from how the protocol behaves.

Network types decide whether any of this happens at all

DR/BDR election isn’t universal. It’s a property of the network type configured (or defaulted) on the interface, and getting this wrong is a distinct failure mode from getting the hello parameters wrong, because a network type mismatch can produce two neighbors that both reach Full state and still calculate routes incorrectly, since one side is silently assuming point-to-point cost rules while the other assumes broadcast rules.

Network type	Election?	Typical media	Notes
Broadcast	Yes	Ethernet	The default on multi-access LAN interfaces across all three vendors in this series.
Non-broadcast (NBMA)	Yes	Frame Relay, some hub-and-spoke ATM	Neighbors must be statically configured since there’s no native Layer 2 broadcast to discover them.
Point-to-point	No	Serial links, point-to-point GRE/IPsec tunnels	No election, no DR, no BDR. Both sides just go straight to Full.
Point-to-multipoint	No	Hub-and-spoke where the hub sees the spokes as individual /32 point-to-point links	Treats the segment as a collection of point-to-point links layered on shared media.
Point-to-multipoint non-broadcast	No	Same as above without native multicast/broadcast capability	Requires statically configured neighbors like NBMA does, but without the election.

The next post covers what actually gets exchanged once two routers reach Full: the LSA types, and how the area hierarchy uses them to decide what a router is and isn’t allowed to know about the rest of the network.