Loading learning content...
Consider an Ethernet switch with 20 OSPF routers connected. In a naive OSPF implementation, every router would need to establish an adjacency with every other router—190 unique adjacencies. Each router would receive and acknowledge the same LSA 19 times. The network would be flooded with redundant traffic, CPU usage would spike during convergence, and the protocol would scale poorly.
OSPF solves this with the Designated Router (DR) concept—an elegant optimization that reduces the complexity of multi-access networks from O(n²) to O(n). Understanding the DR mechanism is essential for both OSPF troubleshooting and network design, as improper DR placement can lead to suboptimal routing behavior and convergence delays.
By the end of this page, you will understand why DRs are necessary, how DR and BDR elections work, the roles DRs play in adjacency formation and LSA flooding, how to influence DR election through priority configuration, and best practices for DR placement in production networks. You'll be able to diagnose DR-related issues and design networks with predictable DR behavior.
To appreciate the DR solution, we must first understand the problem it solves. On multi-access networks (Ethernet being the most common), multiple OSPF routers share the same network segment and can communicate directly with each other.
The Full Mesh Problem:
Without optimization, OSPF would require every router to form a full adjacency with every other router on the segment. For n routers:
Each adjacency requires:
| Routers on Segment | Full Mesh Adjacencies | With DR (Adjacencies) | Reduction Factor |
|---|---|---|---|
| 5 | 10 | 8 | 20% |
| 10 | 45 | 18 | 60% |
| 20 | 190 | 38 | 80% |
| 50 | 1,225 | 98 | 92% |
| 100 | 4,950 | 198 | 96% |
The Flooding Problem:
Beyond adjacencies, consider LSA flooding. When any router generates an LSA update:
The Solution: Designated Router
OSPF introduces a hub-and-spoke model for multi-access networks:
On point-to-point networks (serial links, GRE tunnels, point-to-point subinterfaces), there are only two routers. No DR election occurs because even a full mesh (one adjacency) is optimal. The DR mechanism only applies to multi-access networks where the optimization provides benefit.
The DR and BDR have specific, well-defined responsibilities that optimize OSPF operation on broadcast networks.
Designated Router (DR) Responsibilities:
Backup Designated Router (BDR) Responsibilities:
The BDR exists for redundancy. Its responsibilities mirror the DR's, but it only takes action when the DR fails:
DROther Behavior:
Routers that are neither DR nor BDR are called DROthers. Their behavior differs significantly:
The 2-Way state between DROthers is completely normal—not a problem to solve. They're neighbors (exchanging Hellos) but don't exchange full LSDBs directly; the DR coordinates that.
| Address | Name | Purpose |
|---|---|---|
| 224.0.0.5 | AllSPFRouters | All OSPF routers listen; DR uses to flood LSAs |
| 224.0.0.6 | AllDRouters | Only DR and BDR listen; DROthers use to send updates |
The Type 2 Network LSA has Link State ID = DR's interface IP address. This is why the DR's IP appears in Type 1 Router LSAs as the 'Transit' link destination—routers point to the Network LSA via the DR's interface address. If the DR changes, a new Network LSA is generated with the new DR's interface IP, and the old one ages out.
OSPF elects the DR and BDR through a deterministic process during neighbor formation. Understanding this process is crucial for designing networks with predictable DR placement.
Election Criteria (in order of precedence):
Special Rules:
The Election Algorithm:
When a router first joins a broadcast segment or detects DR/BDR changes, it executes the election algorithm:
OSPF's DR election is non-preemptive. If Router A (priority 100) becomes DR, and Router B (priority 200) later joins the network, Router A remains DR. B becomes BDR (if better than current BDR) but won't preempt A. The only way B becomes DR is if A fails or has its OSPF process restarted. This stability is intentional—it prevents unnecessary DR changes and the associated Network LSA regeneration.
Wait Timer Purpose:
The Wait Timer gives a newly started router time to hear from existing neighbors before initiating an election. Without it:
By waiting one Dead Interval, the router collects Hello packets from all existing neighbors and can make an informed decision about whether an election is needed or if a DR already exists.
The DR/BDR mechanism fundamentally changes adjacency formation on broadcast networks. Understanding which routers form FULL adjacencies is critical for interpreting neighbor states.
Adjacency Rules on Broadcast Networks:
| Router Type | Forms FULL Adjacency With | State With Other DROthers |
|---|---|---|
| DR | All routers on segment | N/A |
| BDR | All routers on segment | N/A |
| DROther | DR and BDR only | 2-Way |
The 2-Way State:
When two DROthers see each other's Hellos on a broadcast segment, they recognize each other as neighbors but stop at 2-Way state. They don't proceed to ExStart and beyond because neither is DR or BDR.
This is by design:
Recognizing Normal vs. Problem States:
When viewing neighbor output, note both the state AND the role. '2-Way with DROTHER' is normal. '2-Way with DR' or '2-Way with BDR' indicates a problem—there should be a FULL adjacency with DR and BDR. Common causes include authentication mismatch, area mismatch, or network type mismatch.
The DR fundamentally optimizes LSA flooding on broadcast networks, acting as a central relay point for updates.
Flooding Without DR (hypothetical):
Flooding With DR:
BDR's Role in Flooding:
The BDR monitors all LSAs sent to 224.0.0.6. If the DR fails to reflood an LSA within a timeout, the BDR takes over and refloods the LSA itself. This backup mechanism ensures reliable flooding even during DR failure.
DR Failure Scenario:
Since all LSA flooding goes through the DR, DROthers don't need direct database exchange with each other. They receive the same LSAs via the DR's reflood. Maintaining only 2-Way state (neighbor recognition without full LSDB synchronization) is sufficient for correct operation and saves significant resources.
In production networks, leaving DR election to chance (Router ID) is poor practice. The DR should be a stable, well-provisioned router—not whichever router happened to have the highest IP address on a loopback.
OSPF Priority:
The priority is an 8-bit value (0-255) configured per interface. Higher priority wins during DR election.
Configuration Example:
interface Ethernet0/0
ip ospf priority 200
| Router Role | Suggested Priority | Rationale |
|---|---|---|
| Intended DR | 200-255 | Highest to guarantee DR election |
| Intended BDR | 100-150 | Second highest for BDR role |
| DROthers | 1 (default) | Can become DR/BDR if needed but won't preempt |
| Never DR | 0 | Explicitly excludes router from election |
When to Use Priority 0:
Setting priority to 0 ensures a router never becomes DR/BDR on that interface. Use this for:
Important: Non-preemption still applies. If you configure priority after a DR is already elected:
To force an immediate DR change after modifying priorities, you must restart OSPF on the current DR ('clear ip ospf process' or interface shutdown/no shutdown). This causes brief routing disruption. Plan such changes during maintenance windows. Never restart OSPF in production without coordination.
Thoughtful DR placement improves OSPF performance, reliability, and manageability. These practices emerge from real-world deployment experience.
Choosing the Right DR:
Common DR Design Patterns:
Distribution/Core Layer DR: In campus networks, make distribution or core switches the DR—they're stable, well-provisioned, and centrally located. Access layer switches should have priority 0.
Router vs. Switch DR: When Layer 3 switches and routers share a segment, consider which has better OSPF performance. Modern L3 switches often handle DR duties well, but dedicated routers may have OSPF optimizations.
Virtual Chassis/Stacking: In stacked switch environments, the DR should be the stack primary. Ensure stack failover doesn't cause OSPF disruption.
Data Center Leaf-Spine: Modern leaf-spine designs often use point-to-point links exclusively, eliminating DR considerations. If broadcast networks exist, make spine switches the DR.
| Environment | Recommended DR | Priority 0 Candidates |
|---|---|---|
| Campus Core | Core switches | Access layer switches |
| Branch/Hub | Hub router | Branch routers |
| Data Center | Spine switches (if broadcast used) | Leaf switches |
| Service Provider | Aggregation routers | Customer-facing routers |
Maintain documentation specifying intended DR and BDR for each broadcast segment, including configured priorities. During troubleshooting, you can quickly identify whether the current DR matches the intended design. Priority changes without documentation lead to configuration drift and unpredictable behavior.
DR-related problems manifest in specific ways. Recognizing these patterns speeds diagnosis and resolution.
Common DR Issues and Solutions:
| Symptom | Likely Cause | Resolution |
|---|---|---|
| Wrong router is DR | Priority not configured or non-preemption | Set correct priorities; restart OSPF on current DR |
| No DR elected | All routers have priority 0, or network issue | Ensure at least one router has priority > 0 |
| DR keeps changing | DR instability (flapping interface, reboots) | Investigate DR health; consider different DR |
| 2-Way with DR (should be FULL) | Parameter mismatch or filtering | Check area ID, auth, network type, MTU |
| Stuck in EXSTART with DR | MTU mismatch (most common) | Match MTUs or disable MTU check |
| Missing routes after DR change | New DR hasn't distributed Network LSA | Wait for convergence or clear OSPF process |
Diagnostic Commands:
! Show DR/BDR on an interface
show ip ospf interface [interface]
! Show neighbor states (look for DR/BDR role)
show ip ospf neighbor
show ip ospf neighbor detail
! Check priorities
show ip ospf interface | include Priority
! Verify Network LSA (Type 2)
show ip ospf database network
Interpreting Output:
Look for:
DR changes regenerate Network LSAs and potentially cause temporary routing disruption. Never 'clear ip ospf process' on a DR in production without understanding the impact. If DR change is truly needed, perform during a maintenance window with proper change management.
We've completed a comprehensive exploration of OSPF's Designated Router mechanism—the elegant optimization that makes OSPF practical on broadcast networks. Let's consolidate the essential knowledge:
Module Complete:
With this page, you've completed the OSPF module. You now have comprehensive knowledge of:
This knowledge prepares you for designing, configuring, troubleshooting, and optimizing OSPF deployments in enterprise networks of any scale.
Congratulations! You've mastered OSPF, the industry-standard interior gateway protocol. From link-state fundamentals to LSA types to DR election, you now possess the deep understanding needed to work with OSPF in production environments. This foundation enables you to explore advanced topics like OSPF stub areas, virtual links, route manipulation, and integration with other protocols.