The rest of the network can't see the external route
R1 has a static route to an external block, but no other router knows about it. OSPF is up. The route just isn't getting into it.
Scenario
R1 and R2 run OSPF in area 0 and their adjacency is up. R1 has a static route to an external block,
203.0.113.0/24 (think: a downstream customer or a partner reachable only through R1). The problem:
R2 has no idea that block exists. OSPF is carrying the internal routes fine, but the static route
isn't part of OSPF, so it stops at R1.
Topology
- R1 Lo0
1.1.1.1/32, R2 Lo02.2.2.2/32 - R1 ↔ R2
10.0.12.0/30, both in OSPF area 0 - R1 has a static route to
203.0.113.0/24
Your job
Get 203.0.113.0/24 into OSPF so R2 learns it, without static-routing it by hand on R2, and without
leaking anything you don't intend to.
What "done" looks like
R2's table shows 203.0.113.0/24 as an OSPF external route (O E2), learned from R1.
Teaches: OSPF only advertises what's in OSPF. A static route has to be redistributed in before the rest of the domain can see it, and redistribution is something you control, not a free-for-all.
What gets checked
Your solution is verified against each of these:
- The OSPF adjacency between R1 and R2 is FULL
- R2 learns 203.0.113.0/24 via OSPF as an external route (O E2)
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.