Two Equal-Cost Paths, One Forwarding Next Hop
R1 sits in area 0 with two parallel paths to 10.20.0.0/16: via R2 at a cost of 20 and via R3 at a cost of 20. show router ospf routes 10.20.0.0/16 lists both next hops, but show router route-table 10.20.0.0/16 shows only the R2 next hop. A separate problem is running in the same network: the 1 Gb link between R2 and R4 has been flapping roughly every two seconds for the last three hours after a bad optic was reseated, R1's OSPF process is consuming noticeable CPU, and SPF has been recomputing around 40 times a minute. A second link between R1 and R3 that carries one of the two paths has a configured cost of 30 rather than 20, and the capacity planner wants both R1 uplinks used for the 10.20.0.0/16 traffic.
1. Why does the OSPF route table show two next hops while the forwarding table shows one?
Read the worked answer
Two next hops in the OSPF route table but one in the forwarding table is a path-count limit, not an SPF problem. OSPF computed both equal-cost branches and both are present in the OSPF route; installing them is a routing-table function, and SR OS caps the number of next hops installed for a prefix with the router-level ECMP setting. Unless that value has been raised, a single path is installed and the second branch is retained only in the OSPF route table. Verify with show router route-table 10.20.0.0/16 for one next hop and show router ospf routes 10.20.0.0/16 for two, then raise the ECMP count with the router ecmp command. Two prerequisites must hold for the change to take effect: the paths must be truly equal cost and of the same route type and area - OSPF never load-shares across intra-area and inter-area, or across external type 1 and type 2 - and the next hops must resolve to distinct addresses. Also confirm the line card supports the requested ECMP width, since hardware limits can silently clamp it.
2. How do you address the SPF churn, and what is the trade-off in your timer choice?
Read the worked answer
spf-wait uses three values: initial wait, second wait, and max wait. On the first trigger the router waits the initial value; each further trigger within the window increases the wait up to the maximum, which damps repeated recomputation. The defaults are too responsive for a link flapping every two seconds, which is why SPF runs almost continuously. Raising the initial and max values damps the churn but delays convergence for every genuine topology change in the area, so it is a trade-off, not a cure. Recommended order: fix the optic or damp the interface first, because the root cause is layer 1; second, throttle LSA generation on the router that owns the flapping link so the flood does not reach every router in the area; third, tune spf-wait to a moderate profile. A max wait of 60 seconds would hide the flap but make a real failure take a minute to converge, which is usually worse than the CPU cost being solved.
3. The planner wants both R1 uplinks carrying 10.20.0.0/16 traffic, but the second link costs 30. What are the options and the risks?
Read the worked answer
OSPF does not support unequal-cost multipath. With costs 20 and 30 the router installs only the cost-20 path and the second link carries nothing for that prefix, regardless of its capacity. The options are: equalize the costs so ECMP applies, either by setting explicit interface metrics or by deriving them from a reference bandwidth so both links produce the same value; accept single-path forwarding and use the second link for other areas or prefixes, or as a fast-converging backup; or change the design so traffic is split by area or by prefix rather than by cost. Two cautions when changing metrics: the interface metric applies to every prefix reachable through that interface, so downstream path selection can shift in ways nobody planned for, and metrics are directional, so changing R1's interface metric alters only R1's outbound choice while return traffic may still prefer the cost-30 link. Verify both directions with show router ospf routes on each side before and after the change.