← All challenges
mediumospf~30 min

OSPF is talking to the office LAN

Both routers blast OSPF hellos onto their host LANs, a waste and an attack surface. Make the LAN interfaces passive without breaking the adjacency or losing the routes.

Scenario

A two-site OSPF network works fine, too fine. A security review flagged that both routers send OSPF hellos onto their office LANs, where only hosts live. Anything on those LANs could speak OSPF back and try to form an adjacency. The fix is standard practice: host-facing interfaces become passive: still advertised into OSPF, but no hellos, no adjacencies.

Topology

  • R1: eth1 = office LAN 10.0.1.1/24, eth2 = core link 10.0.12.1/30
  • R2: eth1 = office LAN 10.0.2.1/24, eth2 = core link 10.0.12.2/30
  • OSPF area 0 everywhere; the adjacency runs over the core link.

Your job

Make each router's LAN interface (eth1) passive, on both routers, without breaking anything:

  • the R1↔R2 adjacency must stay Full,
  • each router must still learn the other's LAN via OSPF.

What "done" looks like

show ip ospf neighbor still shows the core-link adjacency; show ip ospf interface eth1 shows passive; each router's table still has the remote LAN as an OSPF route.

Teaches: passive-interface, the difference between advertising a network and running the protocol on it, and why host-facing interfaces should never do the latter.

What gets checked

Your solution is verified against each of these:

  • The R1-R2 adjacency over the core link is still Full and routes flow
  • Each router still learns the other's LAN subnet via OSPF
  • The host-facing LAN interface (eth1) is passive on both routers

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?

  1. Build the fix locally. New to the tooling? See setting up your lab.
  2. Push your topology file, device configs, and any playbooks to a public repo (GitHub or GitLab).
  3. Submit the repo link. We review it by hand, confirm it works, and issue your proof page.
Submit your solution →