Configure IPv4 static routes three ways — next-hop, exit-interface, and fully specified — explain recursive lookup, and verify each installs and forwards.
Week 4 · Lesson 3 · Active ~44 min · Optional video ~8 min · Lab ~37 min · Domain: IP Connectivity
You should know that connected (C) routes cover attached subnets automatically, and that a router forwards only to prefixes it has an entry for.
Prerequisites: connected-and-local-routes
Baseline check
R1 can reach its own LANs but not the subnet 10.1.4.0/24, which lives behind R2. Before reading on: write the one command you think adds a route to 10.1.4.0/24 via R2 at 10.1.2.2 — and predict whether a single command on R1 is enough for a two-way ping to a host there.
Keep both answers. The command is the easy half; the two-way-ping question is where static routing bites people.
A static route is you telling the router, by hand, "to reach this prefix, go this way." Connected routes cover subnets on the router's own interfaces. Everything one or more hops away needs either a static route or a dynamic protocol. Static routes are precise, predictable, and generate no protocol traffic — ideal for stub sites, default routes to an ISP, and small topologies — but every one is hand-maintained, so they do not scale to large, changing networks.
The command has one shape with three ways to state the "go this way" part:
ip route <destination-prefix> <mask> { <next-hop-ip> | <exit-interface> | <exit-interface> <next-hop-ip> }
- Next-hop form —
ip route 10.1.4.0 255.255.255.0 10.1.2.2. You name the IP address of the next router. This is the most common and generally safest form on Ethernet. The router still has to work out which interface leads to 10.1.2.2, which it does by a second lookup (recursion, next section). - Exit-interface form —
ip route 10.1.4.0 255.255.255.0 GigabitEthernet0/1. You name the interface to send out, with no next-hop IP. On a true point-to-point link (like a serial line) this is clean — there is only one device on the other end, so "send it out this interface" is unambiguous. On multi-access Ethernet it causes trouble: with no next-hop IP, the router treats the destination as if it were directly connected and tries to ARP for the final destination on that segment, which only works if proxy ARP happens to answer. Avoid exit-interface-only on Ethernet. - Fully specified form —
ip route 10.1.4.0 255.255.255.0 GigabitEthernet0/1 10.1.2.2. You name both the exit interface and the next-hop IP. This is the most robust: no recursion is needed to find the interface, and the router still ARPs for the correct next hop rather than the final destination. It is the recommended form on Ethernet when you want to pin the exit interface.
Why does the exit-interface-only form misbehave on Ethernet but not on serial?
On a point-to-point serial link there is exactly one possible receiver, so a frame sent "out the interface" can only reach that one neighbor — no address resolution is needed. Ethernet is multi-access: many devices can share the segment, and frames are delivered by destination MAC. If the route names only the exit interface and no next-hop IP, the router has no next-hop IP to ARP for, so it falls back to ARPing for the packet's final destination on the local segment. That address is not on the segment, so resolution fails unless a neighbor runs proxy ARP. Naming a next-hop IP (next-hop or fully specified form) gives the router a real address on the wire to resolve.
Static routing syntax and the next-hop-on-Ethernet guidance (topic guide)
Recursive lookup is the second search a next-hop route quietly triggers. When you write ip route 10.1.4.0 255.255.255.0 10.1.2.2, the router installs the route, but 10.1.2.2 is not an interface — it is another router's IP. To actually forward, the router must answer a second question: how do I reach 10.1.2.2? It searches the table again and finds 10.1.2.2 inside the connected route C 10.1.2.0/30 ... Gi0/1. Now it knows: send the frame out Gi0/1, ARP for 10.1.2.2, done. That two-step "match the destination, then resolve the next hop against another route" is recursive lookup.
The consequence is a dependency: a next-hop static route is only usable while the route that resolves its next hop still exists. Lose the connected route to 10.1.2.0/30 — shut Gi0/1, pull the cable — and the static route to 10.1.4.0/24 can no longer be resolved; it stops forwarding even though you never touched it. Fully specified routes reduce this fragility by naming the exit interface directly, but they still ARP for the next hop.
Every forward route needs a return route. Routing decisions are per-router and per-direction. Suppose R1 has a perfect route to 10.1.4.0/24 via R2. A ping from a host on R1's LAN (10.1.1.0/24) reaches 10.1.4.7 — but the reply from 10.1.4.7 has to find its way back to 10.1.1.0/24. If R3 (behind 10.1.4.0/24) has no route to 10.1.1.0/24, the echo reply is dropped and the ping fails. The forward path was flawless; the missing return route killed it. This is why a single ip route command on R1 is not enough for a two-way ping — the answer to the baseline's second question is "no."
Pause and predict
R1 has S 10.1.4.0/24 via 10.1.2.2 and C 10.1.2.0/30 ... Gi0/1. An operator shuts Gi0/1. Predict what happens to R1's ability to forward toward 10.1.4.0/24, and what show ip route 10.1.4.7 will report.
Reveal answer
Shutting Gi0/1 withdraws the connected route C 10.1.2.0/30. The next hop 10.1.2.2 can no longer be resolved, so IOS removes the dependent static route from the RIB — recursion has nothing to resolve against. show ip route 10.1.4.7 returns % Network not in table (or % Subnet not in table). The static route configuration is still in running-config, and it will reinstall automatically when Gi0/1 comes back up/up and the connected route returns. The lesson: a next-hop static route is only as alive as the route that resolves its next hop.
Free CCNA | Static Routing | Day 11 (part 2) | CCNA 200-301 Complete Course
~8 min
Confirm the ip route syntax choices and how each static route is verified in show ip route; watch when next-hop is chosen over exit-interface.
Optional. Skip if the written configuration walkthrough and the lab checkpoints already made the three forms and recursive lookup clear.
Watch on YouTubeEnrichment only — the configuration walkthrough and lab below are the primary path.
Topology: R1 — R2 — R3 in a line. R1's LAN is 10.1.1.0/24 (Gi0/0). R1↔R2 is 10.1.2.0/30 (R1 Gi0/1 = .1, R2 = .2). R2↔R3 is 10.1.3.0/30 (R2 = .1, R3 = .2). R3's LAN is 10.1.4.0/24 (Gi0/0). R1 needs to reach 10.1.4.0/24.
Three ways to write the same reachability, then verify
! Form 1 — next-hop (preferred on Ethernet)
R1(config)# ip route 10.1.4.0 255.255.255.0 10.1.2.2
! Form 2 — exit-interface only (fine on point-to-point serial, risky on Ethernet)
! R1(config)# ip route 10.1.4.0 255.255.255.0 GigabitEthernet0/1
! Form 3 — fully specified (most robust on Ethernet)
! R1(config)# ip route 10.1.4.0 255.255.255.0 GigabitEthernet0/1 10.1.2.2
R1# show ip route static
10.0.0.0/8 is variably subnetted, 6 subnets, 3 masks
S 10.1.4.0/24 [1/0] via 10.1.2.2
R1# show ip route 10.1.4.7
Routing entry for 10.1.4.0/24
Known via "static", distance 1, metric 0
Routing Descriptor Blocks:
* 10.1.2.2
Route metric is 0, traffic share count is 1
Interpretation:
S 10.1.4.0/24 [1/0] via 10.1.2.2— the route installed.S= static;[1/0]= administrative distance 1, metric 0 (static routes carry AD 1 by default and no meaningful metric).via 10.1.2.2names the next hop.show ip route staticfilters to only the routes you configured — the fastest way to audit your own work.show ip route 10.1.4.7proves the forwarding decision for a specific host: the router would use10.1.4.0/24 via 10.1.2.2. That is the data-plane decision, confirmed from the control plane.
But R1 still cannot get a reply from 10.1.4.7 until R3 knows how to return traffic to 10.1.1.0/24. On R3:
R3(config)# ip route 10.1.1.0 255.255.255.0 10.1.3.1
Now both directions have a path. (R2, sitting in the middle, already has all four subnets as connected routes, so it needs no static routes in this three-router line.)
Build and check these interactively in the Static Routing Labs tool — its command builder flags a malformed ip route before you commit it.
Use the command builder to assemble next-hop, exit-interface, and fully specified routes and compare how each appears in the table.
Open static-routingSame R1—R2—R3 line. Predict each result before revealing.
| # | Action | Predict |
|---|---|---|
| 1 | R1 has only ip route 10.1.4.0 255.255.255.0 10.1.2.2; ping from R1's LAN to 10.1.4.7 | ? |
| 2 | R3 adds ip route 10.1.1.0 255.255.255.0 10.1.3.1; repeat the ping | ? |
| 3 | R1's route is ip route 10.1.4.0 255.255.255.0 GigabitEthernet0/1 on the Ethernet R1↔R2 link | ? |
Pause and predict
For each row state the outcome and the reason: does the route install, does traffic flow forward, and does the reply make it back?
Reveal answer
- Ping fails. R1's forward route is correct and the echo request reaches 10.1.4.7, but R3 has no route to 10.1.1.0/24, so the echo reply is dropped. Classic one-way routing — a silent failure caused by the missing return route.
- Ping succeeds. With R3's return route in place, replies have a path back to 10.1.1.0/24. Both directions resolve, so the ping completes.
- Route installs but forwarding is unreliable. An exit-interface-only route on multi-access Ethernet leaves R1 with no next-hop IP to ARP for, so it tries to ARP for the final destination 10.1.4.x on the R1↔R2 segment. Unless proxy ARP answers, resolution fails. Rewrite it as next-hop (
... 10.1.2.2) or fully specified (... Gi0/1 10.1.2.2).
This is the static-routing stage of the lab-week4-static-routing lab (skeleton — checkpoints defined here; the interactive lab is being built). Work the checkpoints in order on the R1—R2—R3 topology.
Lab checkpoint · lab-week4-static-routing · ~5 min · packet_tracer
Skill: Configure a next-hop static route to a remote subnet
Starting: R1, R2, R3 in a line; all interfaces up/up; only connected/local routes present; R1 cannot reach 10.1.4.0/24.
Action: On R1 add ip route 10.1.4.0 255.255.255.0 10.1.2.2.
Verify: show ip route shows S 10.1.4.0/24 [1/0] via 10.1.2.2; show ip route 10.1.4.7 resolves to that entry.
Variant: Point the route at an unreachable next hop (10.1.2.9) and see the route configured but forwarding fail because the next hop cannot be resolved.
Lab checkpoint · lab-week4-static-routing · ~4 min · troubleshooting
Skill: Add the return route so a ping succeeds both directions
Starting: R1 has a forward route to 10.1.4.0/24 but a ping from R1's LAN to 10.1.4.7 still fails; R3 has only connected routes.
Action: On R3 add ip route 10.1.1.0 255.255.255.0 10.1.3.1 so replies have a path home.
Verify: Ping from a 10.1.1.0/24 host to 10.1.4.7 now succeeds; each router shows the peer LAN as a static route.
Variant: Leave the return route off and confirm the forward ping fails, proving one-way routing is a silent failure.
Lab checkpoint · lab-week4-static-routing · ~3 min · packet_tracer
Skill: Replace an exit-interface-only route with a fully specified route on Ethernet
Starting: R1 has ip route 10.1.4.0 255.255.255.0 GigabitEthernet0/1 (exit-interface only) on the multi-access Ethernet link, causing ARP oddities.
Action: Remove that route and configure ip route 10.1.4.0 255.255.255.0 GigabitEthernet0/1 10.1.2.2 (fully specified).
Verify: show ip route shows the route via 10.1.2.2 out Gi0/1; forwarding is deterministic and ARP resolves the correct next hop.
Variant: Keep the exit-interface-only route and watch the router attempt to ARP for the final destination on the Ethernet segment.
The static route is configured but the packet never leaves
Symptom. You configured ip route 10.1.4.0 255.255.255.0 10.1.2.2 on R1, but show ip route 10.1.4.7 returns % Network not in table, and show ip route static shows nothing.
Isolate. A static route only installs into the RIB if its next hop is resolvable. Check whether R1 has a route to 10.1.2.2:
R1# show ip route 10.1.2.2
% Subnet not in table
R1# show ip interface brief | include 0/1
GigabitEthernet0/1 10.1.2.1 YES manual administratively down down
Gi0/1 is administratively down, so the connected route C 10.1.2.0/30 is gone — and without it, 10.1.2.2 cannot be resolved. IOS refuses to install a static route whose next hop it cannot reach, so the route silently stays out of the table (recursion has nothing to land on).
Fix. Bring the transit interface back up:
R1(config)# interface GigabitEthernet0/1
R1(config-if)# no shutdown
The connected route to 10.1.2.0/30 returns, 10.1.2.2 becomes resolvable, and IOS reinstalls the dependent static route automatically. Re-verify with show ip route static. Root cause: a next-hop static route is only as alive as the (usually connected) route that resolves its next hop — always confirm the next hop is reachable before suspecting the static route itself.
Quick check (3 items) · retrieve
Answer from memory:
- Write a next-hop static route to 10.1.4.0/24 via 10.1.2.2, and say what second lookup the router must perform to use it.
- Why is an exit-interface-only static route risky on Ethernet but fine on a point-to-point serial link?
- A forward ping fails even though the forward route is perfect. What is the most likely missing piece, and on which router?
Review sheet
ip route <prefix> <mask> <next-hop | interface | interface next-hop>— three forms of one command.- Next-hop is the safe default on Ethernet; exit-interface-only suits point-to-point serial; fully specified is the most robust when you want to pin the interface.
- Recursive lookup: a next-hop route triggers a second search to resolve the next hop, usually against a connected route — lose that and the static route stops forwarding.
- Return route required: every forward route needs a matching route back, or the ping fails one direction only (silent failure).
- Static routes carry AD 1 and appear as
S <prefix> [1/0] via <next-hop>. - Verify:
show ip route static, andshow ip route <destination>to confirm the exact winning entry.
show ip route, suspect an unresolvable next hop — check the route to the next-hop IP (often a downed connected interface) before re-examining the static route itself.You can reach specific remote subnets; now use one default route to catch everything else and a floating static as a backup path.
Next: Default Routes and Floating Static Routes