The OSPF neighbors won't come up
Two routers share a link but never become OSPF neighbors, so neither learns the other's routes. Find why the adjacency is stuck and fix it.
Scenario
R1 and R2 are cabled together and both run OSPF, but they never become neighbors. Neither router learns the other's loopback, so the two sites can't reach each other.
The link is up and the routers can ping across it. The OSPF config looks almost right, but the two ends don't agree on something the adjacency requires.
Topology
- R1:
eth010.0.12.1/24, loopback1.1.1.1/32 - R2:
eth010.0.12.2/24, loopback2.2.2.2/32 - Both run a single OSPF process
Your job
Find why the adjacency is stuck and fix it, so R1 and R2 become full OSPF neighbors and each learns the other's loopback.
What "done" looks like
The adjacency is full on the shared link; R1 has 2.2.2.2/32 and R2 has 1.1.1.1/32 in its OSPF
routes.
Teaches: OSPF neighbors only form when both ends agree on the area for the link: a mismatch leaves the adjacency stuck and silently blocks every route.
What gets checked
Your solution is verified against each of these:
- The OSPF adjacency between R1 and R2 forms on the shared link
- R1 learns R2's loopback (2.2.2.2/32) via OSPF
- R2 learns R1's loopback (1.1.1.1/32) via OSPF
Solve it in your browser
No setup, no install. Write your solution in the editor and hit Check. The in-house engine renders and grades it instantly, then issues your proof the moment every check passes.
Solve in browser →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.