Unequal-Cost OSPF Paths and ECMP Expectations
R1 has two OSPF paths to 10.20.0.0/24. Path A is via R2 with total cost 20 and consists of two parallel 10 Gb/s links between R1 and R2. Path B is via R3 with total cost 30 over a single 10 Gb/s link. R1 is an SR OS router. The engineer configured configure router ecmp 4 and expects traffic to be shared across all three next hops, roughly 2:1 between R2 and R3. show router ospf routes 10.20.0.0/24 shows only the R2 next hops, and interface counters show R3's link idle. The design requires using the R3 path as a backup only, but the engineer also wants the two R2 links to load-balance. The OSPF cost on R1's interface to R2 is 10, and on R1's interface to R3 is 10; R2's and R3's costs to the prefix are 10 and 20 respectively.
1. Why is R3 not used, and why do the two R2 links appear in the route table?
Read the worked answer
OSPF installs only equal-cost paths for ECMP. R1's cost via R2 is 10 + 10 = 20. R1's cost via R3 is 10 + 20 = 30. The two paths are not equal, so the R3 path is not eligible for ECMP and is not installed while the R2 path is available. configure router ecmp 4 raises the maximum number of equal-cost next hops; it does not make unequal-cost paths equal and it does not create weighted load sharing.
The two R2 links appear because they are equal cost to each other, assuming they are separate OSPF interfaces with the same cost. If they are members of a LAG, OSPF sees one logical interface and one next hop, so the route table would show only one R2 next hop even though the LAG balances internally. The output of show router ospf routes 10.20.0.0/24 and show router interface will distinguish those cases.
2. The engineer wants a 2:1 split across R2 and R3. What can OSPF on SR OS actually deliver, and what would you recommend?
Read the worked answer
OSPF does not support weighted or unequal-cost multipath. It can deliver equal-cost multipath across up to the configured ECMP limit, and it can deliver a single best path. A 2:1 split is therefore not an OSPF ECMP behavior.
If the requirement is really 2:1, the design needs a different tool: a LAG with member-link hashing, policy-based forwarding, or a higher-layer overlay that can weight paths. OSPF alone will not do it.
If the requirement is really backup-only for R3, leave the cost at 30. R3 will not be installed while R2 is up, and OSPF will reconverge to R3 if R2 fails. That matches the stated design. If the requirement is to use R3 as an active equal-cost path, lower R3's path cost to 20 so R1 sees three equal-cost next hops (two via R2 and one via R3), which gives an approximate 2:1 sharing only if the two R2 links are separate next hops. If they are a LAG, R1 sees two equal-cost next hops and the split is approximately 1:1, not 2:1. Verify the next-hop count before promising a ratio.
3. What would you check to confirm that the two R2 links are being used and that the R3 path is a viable standby?
Read the worked answer
Check show router ospf routes 10.20.0.0/24 to see the installed next hops and their interface names. If two R2 interfaces appear, OSPF is treating them as separate equal-cost links. If only one R2 next hop appears, check whether the links are in a LAG and whether OSPF is configured on the LAG interface rather than on the members.
Check show router interface and the LAG configuration to confirm member state and hashing. Use interface counters or show router route-table to confirm that traffic is actually distributed across the R2 next hops; OSPF installing a next hop does not prove that the data plane is using it.
For the standby, verify that the R3 path is in the OSPF route table as a backup or that it becomes active after a controlled R2 failure. If R3 is not installed at all, that is expected with cost 30. Test by disabling the R2 adjacency or shutting one R2 link, then confirm that traffic moves to R3 within the OSPF dead interval and that the return path also avoids the failed component.