A Flapping Default Route and Equal-Cost Paths Across Mismatched Links
Four routers (R1 to R4) share one broadcast segment, 10.0.0.0/24, in OSPF area 0. R1 is the only router with a full Internet table and injects a default route with default-information originate. R2 is configured with priority 0. R3 currently holds the DR role and R4 is BDR. R1's adjacency with R2 sits permanently in 2-Way. Every time R3 is rebooted for maintenance, Internet traffic from all four routers drops for roughly 40 seconds while the segment re-converges. Separately, R1 reaches 172.16.0.0/16 over two links: a 1 Gbps path and a 100 Mbps path. Both paths are installed at cost 1, so R1 balances the /16 across them, and the 100 Mbps link is consistently at about 95 percent utilization every afternoon.
1. Is the 2-Way adjacency between R1 and R2 a fault? Explain when it would matter.
Read the worked answer
No. On a broadcast segment, DROthers only form a full adjacency with the DR and the BDR; the relationship between two DROthers stays in 2-Way by design. R1 and R2 are both DROthers (R2 because priority 0 makes it ineligible, R1 because it lost the election), so 2-Way is the correct state.
It matters in three situations:
- If R1 must be DR, for example because it is the only router injecting external LSAs and you want that LSA sourced from a stable, powerful router. Then a priority 0 on R2 and a low value on R1 are needed.
- If the link should have been point-to-point. A /30 or a point-to-point link type on both ends removes the DR/BDR concept entirely and gives a full adjacency.
- If you are troubleshooting and misreading 2-Way as a failure, which leads to pointless
clear ospf neighborcommands and real outages.
Priority 0 also means R2 can never become DR, so it can never be the source of an LSA that only the DR generates - that is a design choice, not a defect.
2. Why does rebooting R3 take down Internet access for everyone, and how would you make the segment resilient to it?
Read the worked answer
R3 is the DR, so it originates the network LSA for 10.0.0.0/24 and owns the adjacency state for the segment. When it restarts, the DR/BDR election reruns, every adjacency on the segment resets, SPF is re-run, and the router that was relying on the DR's LSAs has to relearn them - hence the roughly 40 second hole.
The structural problem is that the DR role landed on a router chosen for maintenance, not on the most stable device.
Fix:
- Make R1 the DR: set a high priority on R1 (e.g.
set protocols ospf area 0 interface ... priority 200) and leave R2/R4 at 0. - Remember DR election is not preemptive. A newly configured higher priority does not take the role until the segment re-elects, so you must clear the OSPF adjacency on the segment (or restart the routing process on the segment) in a maintenance window. That is the same 40 second event, scheduled instead of accidental.
- Keep at least one BDR that is also stable, so a DR failure has a ready successor rather than a fresh election.
- Verify with
show ospf interface detail- DR/BDR fields should now name the intended routers.
3. Both paths to 172.16.0.0/16 are cost 1. What is the cause and what are the two ways to fix it?
Read the worked answer
OSPF cost is reference-bandwidth divided by interface bandwidth, with a floor of 1. Junos defaults the reference bandwidth to 100 Mbps, so a 100 Mbps link is cost 1 and a 1 Gbps link is also cost 1. The formula cannot express a difference above 100 Mbps, so the two paths look equal to SPF and get installed as equal-cost next hops, sending half the /16 into a link that cannot carry it.
Two fixes:
- Raise the reference bandwidth, e.g.
set protocols ospf reference-bandwidth 10g. Now 1 Gbps is cost 10 and 100 Mbps is cost 100. Correct and self-maintaining as links are upgraded - but it must be applied consistently across the whole area. Change only R1 and you get asymmetric costs, which produces one-way path selection and hard-to-diagnose asymmetric routing. - Set an explicit metric on the 100 Mbps interface (or on both), leaving the default reference bandwidth alone. Local, surgical, but it does not scale and drifts out of date as links change.
Preferred: fix the reference bandwidth area-wide in a change window and verify the resulting cost on both paths with show ospf interface detail before removing any explicit metrics.