I know static routing doesn’t have the reputation of something like BGP or OSPF — no elections, no adjacencies, no databases to sync. But I’ve come to genuinely respect it. On small networks, stub sites, and anywhere predictability matters more than dynamic flexibility, a well-placed static route is often the right engineering choice, not just the beginner’s choice. Let me walk through it properly, because there’s more nuance here than “just type the command” once you get into administrative distance, floating statics, and route redistribution.
What Static Routing Is
A static route is a manually configured path to a destination network, entered directly into a router’s configuration rather than learned dynamically through a routing protocol. The router simply forwards traffic for that destination out the specified interface or next-hop, with no negotiation, no convergence delay, and no protocol overhead.
Fundamentals
- Routing table: every router builds a table of destination networks and the path to reach them, whether learned statically, dynamically, or via directly connected interfaces.
- Administrative distance (AD): when multiple sources offer a route to the same destination, AD decides which one wins. Static routes have a default AD of 1 — more trusted than any dynamic routing protocol (OSPF is 110, EIGRP is 90, BGP is 20/200), but less trusted than a directly connected route (AD 0).
- Next-hop vs exit-interface routes: you can point a static route at a next-hop IP address, an exit interface, or both — and the choice affects both behavior and troubleshooting.
Basic Static Route Configuration
The core syntax:
R1(config)# ip route <destination-network> <subnet-mask> <next-hop-or-interface>
Example — routing to a remote subnet via a next-hop IP:
R1(config)# ip route 192.168.2.0 255.255.255.0 10.0.0.2
Example — routing via exit interface instead (common on point-to-point links):
R1(config)# ip route 192.168.2.0 255.255.255.0 Serial0/0/0
Example — both next-hop and interface specified (recommended on multi-access segments to avoid ARP issues):
R1(config)# ip route 192.168.2.0 255.255.255.0 GigabitEthernet0/0 10.0.0.2
I’ll flag this clearly: on Ethernet/multi-access interfaces, using only an exit interface (no next-hop) can cause proxy-ARP-related issues and unnecessary ARP traffic. On point-to-point serial or tunnel interfaces, interface-only static routes work cleanly since there’s only one possible destination anyway.
Verifying Static Routes
R1# show ip route static
S 192.168.2.0/24 [1/0] via 10.0.0.2
R1# show ip route 192.168.2.0
Routing entry for 192.168.2.0/24
Known via "static", distance 1, metric 0
Routing Descriptor Blocks:
* 10.0.0.2
Route metric is 0, traffic share count is 1
The [1/0] shows administrative distance (1) and metric (0, since static routes don’t calculate a metric the way dynamic protocols do).
The Default Route
A default route (0.0.0.0/0) matches any destination not covered by a more specific route — this is what you’ll configure on virtually every internet-edge router:
R1(config)# ip route 0.0.0.0 0.0.0.0 203.0.113.1
This is often called the “gateway of last resort,” and show ip route will explicitly label it as such:
R1# show ip route
Gateway of last resort is 203.0.113.1 to network 0.0.0.0
S* 0.0.0.0/0 [1/0] via 203.0.113.1
Floating Static Routes for Backup Paths
One of the most practically useful static routing techniques is the floating static route — a backup path that only becomes active if the primary (usually dynamic) route disappears from the table. You achieve this by configuring a static route with a higher administrative distance than your primary routing source:
R1(config)# ip route 192.168.2.0 255.255.255.0 10.0.0.2
R1(config)# ip route 192.168.2.0 255.255.255.0 172.16.0.2 200
Here, if OSPF (AD 110) is normally providing the route to 192.168.2.0/24, the static route at AD 200 sits unused in the background. Only if both the primary path and any OSPF-learned route disappear does this floating static become the best (lowest AD) available option and get installed.
Enterprise Scenario: Branch Office with a Backup 4G Failover Router
A design I’ve deployed more than once: a small branch site with a primary MPLS or VPN connection and a cellular/4G backup router for internet failover. Rather than running a full dynamic routing protocol for a two-router branch, I typically use:
! Primary route via MPLS
R1(config)# ip route 0.0.0.0 0.0.0.0 10.1.1.1
! Backup route via cellular router, higher AD, only used if primary fails
R1(config)# ip route 0.0.0.0 0.0.0.0 10.1.2.1 250
Combined with IP SLA tracking (below), this gives near-instant, low-overhead failover without the operational complexity of running OSPF or EIGRP on a two-router branch.
Static Routes with IP SLA Tracking
By default, a static route stays in the routing table as long as the next-hop is technically reachable at Layer 3 through the local interface — even if the actual path beyond that next-hop is broken. IP SLA tracking solves this by actively probing reachability and pulling the route if the probe fails:
R1(config)# ip sla 1
R1(config-ip-sla)# icmp-echo 8.8.8.8 source-interface GigabitEthernet0/0
R1(config-ip-sla-echo)# frequency 5
R1(config)# ip sla schedule 1 life forever start-time now
R1(config)# track 1 ip sla 1 reachability
R1(config)# ip route 0.0.0.0 0.0.0.0 10.1.1.1 track 1
This is, in my experience, the single most underused static routing feature — without it, a “backup” static route with a merely-reachable next-hop can sit there uselessly while the actual upstream path is dead.
Recursive vs Directly Connected Static Routes
A static route pointing to a next-hop that itself requires a routing table lookup to resolve (rather than a directly connected interface) is called a recursive static route. These work fine but add a lookup step and, in some edge cases involving default routes, can create unexpected recursive loops. I generally prefer specifying the exit interface alongside the next-hop where possible to avoid this ambiguity.
Common Configuration Mistakes
- Wrong subnet mask in the
ip routecommand — this is the single most common static routing error I see, and it silently creates a route to the wrong network scope. - Using an Ethernet exit-interface-only static route, causing excessive ARP requests and, on some platforms, incorrect behavior with proxy ARP.
- Forgetting a floating static’s AD must be higher than the dynamic protocol’s AD, or it will incorrectly compete with (or override) the dynamic route.
- No reachability tracking on backup routes, leaving a “backup” path that never actually activates during a real outage because the immediate next-hop stayed technically reachable.
- Asymmetric static routing without matching return paths, especially problematic behind stateful firewalls that expect to see both directions of a flow.
Troubleshooting Static Routes
show ip route static
show ip route <destination>
show ip route 0.0.0.0
traceroute <destination>
ping <next-hop>
If a static route isn’t appearing in the table, first check that the next-hop or exit interface is actually up (show ip interface brief), then double-check the mask, then check whether a lower-AD route to the same destination is winning instead.
Performance Considerations
Static routing has effectively zero control-plane CPU or bandwidth overhead compared to dynamic protocols — no hellos, no LSDB, no periodic updates. That’s part of why it’s still the right call for small, stable topologies. The tradeoff is entirely operational: someone has to manually update static routes when the topology changes, and there’s no automatic failover unless you build it yourself with floating statics and tracking.
FAQs
When should I use static routing instead of a dynamic protocol? Small or stub networks, single-homed sites, default routes to an ISP, and any scenario where the topology rarely changes and predictability matters more than automatic adaptation.
What administrative distance do static routes have? 1 by default, which you can override per-route (as with floating statics) to control preference relative to dynamic protocols.
Can static routes and dynamic routing protocols coexist? Yes, and it’s extremely common — static default routes alongside OSPF or EIGRP internally is a standard enterprise pattern.
Do static routes automatically fail over if a link goes down? Only if the next-hop itself becomes unreachable at Layer 3, or if you’ve configured IP SLA tracking to actively monitor end-to-end reachability rather than just local interface state.
Summary
Static routing doesn’t get the attention dynamic protocols do, but I still reach for it constantly — branch offices, default routes, backup paths, anywhere the topology is simple and stable enough that automatic recalculation just adds complexity without adding value. The features that turn it from “beginner tool” into “legitimate design choice” are floating static routes and IP SLA tracking — get comfortable with both, and static routing becomes a genuinely reliable part of your toolkit rather than something you outgrow.
References
- Cisco: IP Routing: Static Configuration Guide
- Cisco: Configuring IP SLAs
