Traffic is taking the slow path
Two paths to the same destination, and OSPF is using the wrong one, the low-bandwidth backup link. Make it prefer the right path without breaking the backup.
Scenario
R1 can reach R3's loopback 3.3.3.3 two ways: the path via R2 (the high-bandwidth core) and the
direct R1-R3 link (a low-bandwidth backup that should only be used if the core fails). Right now
OSPF is sending traffic over the direct backup link, because by hop count it looks shorter.
Topology
- R1 Lo0
1.1.1.1, R2 Lo02.2.2.2, R3 Lo03.3.3.3 - R1 ↔ R2
10.0.12.0/30, R2 ↔ R310.0.23.0/30, R1 ↔ R310.0.13.0/30(the backup) - All OSPF area 0
Your job
Make R1 prefer the path via R2 to reach 3.3.3.3, while keeping the direct link as a working
backup (it should take over if the R2 path fails). Don't change the topology or addressing.
What "done" looks like
R1's route to 3.3.3.3/32 points at R2 (10.0.12.2), and R1 can still reach it.
Teaches: OSPF picks the lowest-cost path, and cost is yours to set. Raising the cost on the backup link (or lowering it on the primary) steers traffic without removing the backup.
What gets checked
Your solution is verified against each of these:
- R1's route to 3.3.3.3/32 goes via R2, not the direct R1-R3 link
- R1 can reach 3.3.3.3
Solve it in the browser lab
No setup, no install. Open a live lab: configure each device in the editor or its Cisco IOS terminal, run show/ping/traceroute (or test from the hosts), and watch the network react. The in-house engine grades your fix instantly and issues your proof the moment every check passes.
Open the lab →Prefer your own lab?
- Build the fix locally. New to the tooling? See setting up your lab.
- Push your topology file, device configs, and any playbooks to a public repo (GitHub or GitLab).
- Submit the repo link. We review it by hand, confirm it works, and issue your proof page.