The server LAN never reaches OSPF
A directly-connected server LAN isn't advertised into OSPF, so the neighbor can't reach it. Redistribute connected routes into OSPF.
Scenario
r1 has a directly-connected server LAN on eth2 (192.168.50.0/24) and an OSPF adjacency to r2
over eth1. The OSPF process advertises the transit link but not the server LAN. There's no
network statement for it, and the team would rather not add one per LAN. So r2 has no route to
the servers.
Your job
In r1/frr.conf, advertise r1's directly-connected routes into OSPF so the server LAN reaches
r2, without adding a network statement for it.
What "done" looks like
The adjacency stays full, and r2 has an OSPF route to 192.168.50.0/24.
Teaches: redistribution. Pulling connected (or static) routes into OSPF advertises networks the protocol isn't directly running on, which is how you announce stub LANs without enabling OSPF on every interface.
What gets checked
Your solution is verified against each of these:
- The OSPF adjacency between r1 and r2 is full
- r2 learns the server LAN (192.168.50.0/24) 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.