LFCE 14 🐧 Static Routing — Concepts
Static routing is the manual configuration of a path through a network. An administrator tells the kernel: “To reach this destination network, send packets to this gateway, or out this interface.” The kernel stores that instruction in its routing table, and every packet destined for that network follows it until the route is removed or replaced. Unlike dynamic routing, where protocols like OSPF or BGP discover paths automatically and adapt to topology changes, static routing is fixed. It does not react to a link failure. It does not learn a better path. It does exactly what it was told, which is both its limitation and its value.
For the LFCE candidate, static routing is a core objective. The exam requires the ability to route IP traffic statically and dynamically . Static routes are the foundation: they appear in lab networks, VPN overlays, and special paths that must not follow the default route. They are also the fallback when dynamic protocols are unavailable or unnecessary. Understanding how the kernel selects a route, how to add and verify one, and how to make it persistent separates a configuration that works until reboot from one that survives production.
Key point: The Linux routing table is ordered by specificity. A more specific route (longer prefix) always wins over a less specific one, regardless of the order in which they were added. The default route is the least specific route of all and serves as the catch-all. Static routes are added with ip route add, verified with ip route get, and lost on reboot unless persisted through a network manager or configuration file.
Why static routing exists
The deterministic path problem.
Dynamic routing protocols optimize for reachability and resilience. They reroute around failures, balance across multiple paths, and converge to the best available topology. But some traffic must not be rerouted. A management network that must always traverse a specific firewall. A lab environment where the path is the experiment. A VPN overlay where the tunnel endpoint is the only valid next hop. Static routes give the administrator absolute control over the path, independent of what any routing protocol might prefer. The route is fixed because the requirement is fixed.
The default route limitation problem.
The default route is a single instruction: “If no other route matches, send the packet here.” It works for the general case, but it cannot express exceptions. A host with a default route to the internet cannot reach a private network behind a second router unless a static route tells it to. The default route points one way; the static route points another. Without static routes, every destination must either be directly connected or reachable through the default gateway. Static routes remove that constraint.
The onlink problem.
A gateway must be reachable before a route through it can be used. If the gateway’s address is not on a directly connected subnet, the kernel rejects the route with “Network is unreachable.” The onlink flag tells the kernel to accept the gateway as reachable through the specified interface even when no matching connected route exists . This is essential for lab environments using dummy interfaces, for VPN tunnels where the gateway is only reachable through the tunnel itself, and for point-to-point links where the neighbor’s address does not fall within a configured subnet.
a. The routing table and route selection
The kernel maintains a routing table that maps destination prefixes to next hops. When a packet arrives, the kernel searches the table for the most specific match: the route with the longest prefix that contains the destination address.
# Display the main routing table
ip route show
# Example output:
# default via 192.168.1.1 dev eth0 proto static
# 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.100
# 10.0.0.0/8 via 10.0.0.1 dev eth1 proto staticThe first line is the default route. The second is a directly connected network, added automatically when the interface was configured. The third is a static route for a remote network. The proto field indicates how the route was created: kernel for connected routes, static for administrator-added routes, and ra for routes learned from Router Advertisements.
# Ask the kernel which route it will use for a specific destination
ip route get 10.20.30.40
# Example output:
# 10.20.30.40 via 10.0.0.1 dev eth1 src 192.168.1.100 uid 0
# cacheThe ip route get command is the definitive verification. It does not show the entire table; it shows the single route the kernel would select for that destination, including the source address it would use. This is how you confirm that a static route is being used rather than the default route .
b. Adding, replacing, and deleting static routes
The ip route command modifies the running kernel state. Changes are immediate and temporary.
# Add a route to a destination network through a gateway
ip route add 192.168.2.0/24 via 10.0.0.1
# Add a route through a specific interface (no gateway)
ip route add 192.168.2.0/24 dev eth0
# Add a route with both gateway and interface specified
ip route add 192.168.2.0/24 via 10.0.0.1 dev eth0
# Add a host route (/32) for a single destination
ip route add 10.10.10.1/32 via 192.168.1.1The via keyword specifies the gateway. The dev keyword specifies the outgoing interface. When both are present, the kernel uses the interface and sends the packet to the gateway’s MAC address. When only the interface is specified, the kernel treats the destination as directly reachable on that link, which is appropriate for point-to-point links or when the gateway is not needed.
# Replace an existing route without deleting it first
ip route replace 192.168.2.0/24 via 10.0.0.2
# Delete a static route
ip route del 192.168.2.0/24
# Delete a route with a specific gateway (when multiple routes exist for the same prefix)
ip route del 192.168.2.0/24 via 10.0.0.1The replace command is useful when a route might or might not already exist. It creates the route if absent and overwrites it if present, without the error that add produces when the route already exists. The del command removes the route; the gateway specification is optional but required when multiple routes share the same prefix.
c. The onlink flag and persistence
The onlink flag is necessary when the gateway is not reachable through a connected route. The kernel normally validates that a gateway is on a directly connected subnet before accepting a route through it. If the gateway is not on a connected subnet, the route is rejected.
# Add a route where the gateway is only reachable through the specified interface
# The onlink flag bypasses the gateway reachability check
ip route add 203.0.113.0/24 via 198.51.100.254 dev lfcsroute0 onlink
# This is common in lab environments with dummy interfaces
# and in VPN scenarios where the gateway is inside the tunnelWithout onlink, the kernel returns “Error: Nexthop has invalid gateway” or “Network is unreachable.” The flag tells the kernel to trust the administrator’s assertion that the gateway is reachable through the interface, even though the routing table does not contain a connected route that proves it .
Static routes added with ip route add are not persistent. They disappear on reboot. Persistence depends on the distribution’s network management system.
# Debian/Ubuntu with ifupdown: add to /etc/network/interfaces
# up ip route add 192.168.2.0/24 via 10.0.0.1 dev eth0
# Ubuntu with Netplan: add to the YAML configuration
# routes:
# - to: 192.168.2.0/24
# via: 10.0.0.1
# RHEL/CentOS with NetworkManager:
nmcli connection modify "eth0" +ipv4.routes "192.168.2.0/24 10.0.0.1"
# systemd-networkd: add a [Route] section to the .network file
# [Route]
# Destination=192.168.2.0/24
# Gateway=10.0.0.1The choice of persistence mechanism depends on the distribution and the network manager in use. The running configuration is verified with ip route show; the persistent configuration is verified by rebooting or restarting the network service.
Complete Example Session
# ============================================
# PART 1: INSPECT THE CURRENT ROUTING TABLE
# ============================================
# Before adding a static route, understand the existing paths
ip route show
# Output shows the default route and any connected networks
# The default route is the catch-all for unmatched destinations
# ============================================
# PART 2: CHECK THE CURRENT PATH FOR A DESTINATION
# ============================================
# Ask the kernel how it would reach a destination in the target network
ip route get 203.0.113.10
# Before the static route, this follows the default route
# Output: 203.0.113.10 via <default-gateway> dev eth0
# ============================================
# PART 3: CREATE A DUMMY INTERFACE FOR TESTING
# ============================================
# A dummy interface provides a safe local interface for routing practice
# without altering the real network path
ip link add lfcsroute0 type dummy
ip addr add 198.51.100.1/24 dev lfcsroute0
ip link set lfcsroute0 up
ip -brief address show lfcsroute0
# Output: lfcsroute0 UP 198.51.100.1/24
# ============================================
# PART 4: ADD THE STATIC ROUTE WITH ONLINK
# ============================================
# The gateway 198.51.100.254 is in the dummy interface's subnet
# but no real neighbor exists
# The onlink flag tells the kernel to accept the gateway anyway
ip route add 203.0.113.0/24 via 198.51.100.254 dev lfcsroute0 onlink
# ============================================
# PART 5: VERIFY THE ROUTE EXISTS
# ============================================
ip route show 203.0.113.0/24
# Output: 203.0.113.0/24 via 198.51.100.254 dev lfcsroute0
# ============================================
# PART 6: VERIFY THE KERNEL SELECTS THE ROUTE
# ============================================
ip route get 203.0.113.10
# Output: 203.0.113.10 via 198.51.100.254 dev lfcsroute0
# The static route is now selected instead of the default route
# ============================================
# PART 7: TEST A DESTINATION OUTSIDE THE ROUTE
# ============================================
ip route get 8.8.8.8
# Output: 8.8.8.8 via <default-gateway> dev eth0
# The default route is still used for destinations not covered by the static route
# ============================================
# PART 8: DELETE THE STATIC ROUTE
# ============================================
ip route del 203.0.113.0/24
# The route is removed from the running configuration
# ============================================
# PART 9: VERIFY THE ROUTE IS GONE
# ============================================
ip route get 203.0.113.10
# Output reverts to the default route
# The specific path no longer exists
# ============================================
# PART 10: PERSISTENCE CHECK
# ============================================
# Routes added with ip route are lost on reboot
# For persistence, the route must be added to:
# - /etc/network/interfaces (Debian with ifupdown)
# - Netplan YAML (Ubuntu)
# - nmcli connection modify (RHEL/CentOS)
# - systemd-networkd .network file
# The running configuration is temporary; the persistent configuration is permanentThe ten parts demonstrate the complete lifecycle: inspect, test, add, verify, and remove. The critical verification step is Part 6, where ip route get confirms that the kernel actually selects the new route. A route that exists in the table but is not selected is a route that does not work.
Quick Reference
Static Route Commands
| Task | Command |
|---|---|
| Add route via gateway | ip route add <net>/<prefix> via <gw> |
| Add route via interface | ip route add <net>/<prefix> dev <if> |
| Add route with both | ip route add <net>/<prefix> via <gw> dev <if> |
| Add with onlink | ip route add <net>/<prefix> via <gw> dev <if> onlink |
| Replace existing route | ip route replace <net>/<prefix> via <gw> |
| Delete route | ip route del <net>/<prefix> |
| Show main table | ip route show |
| Show specific prefix | ip route show <net>/<prefix> |
| Verify selection | ip route get <destination> |
| Add host route | ip route add <ip>/32 via <gw> |
Route Selection Rules
| Rule | Meaning |
|---|---|
| Longest prefix wins | /24 beats /16 beats /8 |
| Specificity beats order | Addition order does not matter |
| Default is last resort | default or 0.0.0.0/0 matches everything |
| Gateway must be reachable | Unless onlink is specified |
| Connected routes are automatic | Added when interface address is configured |
Persistence Methods
| System | Method |
|---|---|
| Debian/ifupdown | up ip route add ... in /etc/network/interfaces |
| Ubuntu/Netplan | routes: section in YAML |
| RHEL/NetworkManager | nmcli connection modify +ipv4.routes |
| systemd-networkd | [Route] section in .network file |
Best Practices
✅ Do This:
# Verify the current path before adding a route
ip route get <destination> # ✅
# Use ip route get to confirm the route is selected
ip route get <destination> # ✅
# Use onlink when the gateway is not on a connected subnet
ip route add <net> via <gw> dev <if> onlink # ✅
# Use replace when the route may already exist
ip route replace <net> via <gw> # ✅
# Persist routes through the distribution's network manager
nmcli connection modify ... +ipv4.routes "..." # ✅
# Check the routing table for conflicts before adding
ip route show | grep <prefix> # ✅❌ Don’t Do This:
# Assume a route is working because it appears in ip route show
# Always verify with ip route get # ❌
# Use ip route add when the route might exist
# add fails with "File exists"; use replace # ❌
# Omit onlink when the gateway is unreachable
# The kernel rejects the route # ❌
# Expect ip route add to survive reboot
# It modifies running state only # ❌
# Add a static route to a directly connected network
# The connected route already exists; the static route is redundant # ❌
# Use the legacy route command for new configurations
# iproute2 is the standard; route is deprecated # ❌Common Pitfalls
| Pitfall | Why It Happens | Fix |
|---|---|---|
| Route exists but traffic does not flow | Route not selected due to more specific route | ip route get to verify |
| “Nexthop has invalid gateway” | Gateway not on connected subnet | Add onlink flag |
| Route lost after reboot | ip route add is not persistent | Configure through network manager |
| “File exists” error | Route already present | Use ip route replace |
| Route not matching expected traffic | Longer prefix elsewhere | Check ip route show for conflicts |
| Static route redundant with connected route | Destination is directly connected | Remove static route; connected route suffices |
| Gateway unreachable | No route to gateway itself | Add a route to the gateway first, or use onlink |
Real-World Examples
1. Basic route via gateway
ip route add 192.168.2.0/24 via 10.0.0.12. Route via interface only
ip route add 192.168.2.0/24 dev eth03. Route with gateway and interface
ip route add 192.168.2.0/24 via 10.0.0.1 dev eth04. Host route
ip route add 10.10.10.1/32 via 192.168.1.15. Onlink route for dummy interface
ip route add 203.0.113.0/24 via 198.51.100.254 dev lfcsroute0 onlink6. Replace an existing route
ip route replace 192.168.2.0/24 via 10.0.0.27. Delete a route
ip route del 192.168.2.0/248. Verify route selection
ip route get 192.168.2.1009. Show routes for a specific prefix
ip route show 192.168.2.0/2410. Persist with nmcli
nmcli connection modify "eth0" +ipv4.routes "192.168.2.0/24 10.0.0.1"Visual
Route Selection by Longest Prefix
┌──────────────────────────────────────────────────────────────┐
│ THE KERNEL SELECTS THE MOST SPECIFIC MATCHING ROUTE │
│ │
│ Routing table: │
│ ┌──────────────────────┬──────────────────┬───────────────┐ │
│ │ Destination │ Gateway │ Prefix Length │ │
│ ├──────────────────────┼──────────────────┼───────────────┤ │
│ │ 0.0.0.0/0 (default) │ 192.168.1.1 │ 0 │ │
│ │ 10.0.0.0/8 │ 10.0.0.1 │ 8 │ │
│ │ 10.20.0.0/16 │ 10.0.0.2 │ 16 │ │
│ │ 10.20.30.0/24 │ 10.0.0.3 │ 24 │ │
│ └──────────────────────┴──────────────────┴───────────────┘ │
│ │
│ Packet to 10.20.30.40: │
│ Matches /0, /8, /16, /24 → /24 wins → via 10.0.0.3 │
│ │
│ Packet to 10.20.40.50: │
│ Matches /0, /8, /16 → /16 wins → via 10.0.0.2 │
│ │
│ Packet to 10.30.40.50: │
│ Matches /0, /8 → /8 wins → via 10.0.0.1 │
│ │
│ Packet to 8.8.8.8: │
│ Matches /0 only → default → via 192.168.1.1 │
└──────────────────────────────────────────────────────────────┘The onlink Flag
┌──────────────────────────────────────────────────────────────┐
│ WHEN THE GATEWAY IS NOT ON A CONNECTED SUBNET │
│ │
│ Without onlink: │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ ip route add 203.0.113.0/24 via 198.51.100.254 │ │
│ │ dev lfcsroute0 │ │
│ │ │ │
│ │ Kernel: "Is 198.51.100.254 on a connected subnet?" │ │
│ │ "No connected route matches." │ │
│ │ Result: "Nexthop has invalid gateway" │ │
│ └────────────────────────────────────────────────────────┘ │
│ │
│ With onlink: │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ ip route add 203.0.113.0/24 via 198.51.100.254 │ │
│ │ dev lfcsroute0 onlink │ │
│ │ │ │
│ │ Kernel: "Administrator says the gateway is reachable │ │
│ │ through this interface. Accept the route." │ │
│ │ Result: Route added successfully. │ │
│ └────────────────────────────────────────────────────────┘ │
│ │
│ Use case: dummy interfaces, VPN tunnels, point-to-point │
│ links where the neighbor address is outside the subnet. │
└──────────────────────────────────────────────────────────────┘Static Route Lifecycle
┌──────────────────────────────────────────────────────────────┐
│ FROM ADD TO REBOOT │
│ │
│ ip route add 192.168.2.0/24 via 10.0.0.1 │
│ │ │
│ ▼ │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ Running kernel state: route exists │ │
│ │ ip route show → 192.168.2.0/24 via 10.0.0.1 │ │
│ │ ip route get 192.168.2.5 → uses 10.0.0.1 │ │
│ └────────────────────────────────────────────────────────┘ │
│ │ │
│ │ Reboot │
│ ▼ │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ Running kernel state: route is GONE │ │
│ │ ip route show → no entry for 192.168.2.0/24 │ │
│ │ ip route get 192.168.2.5 → uses default route │ │
│ └────────────────────────────────────────────────────────┘ │
│ │
│ For persistence: add to network manager configuration │
│ (Netplan, nmcli, systemd-networkd, /etc/network/interfaces) │
└──────────────────────────────────────────────────────────────┘Summary
| Item | Value |
|---|---|
| Primary command | ip route (iproute2) |
| Add route via gateway | ip route add <net>/<prefix> via <gw> |
| Add route via interface | ip route add <net>/<prefix> dev <if> |
| Add with onlink | ... dev <if> onlink |
| Replace route | ip route replace |
| Delete route | ip route del |
| Verify selection | ip route get <dest> |
| Show table | ip route show |
| Route selection rule | Longest prefix match |
| Persistence | Network manager configuration |
| Onlink use case | Gateway not on connected subnet |
Key takeaways:
- The routing table selects by longest prefix. A
/24route always wins over a/16route for a destination in both. The default route is the least specific and the last resort . ip route getis the verification tool. A route that appears inip route showis not necessarily the route the kernel selects.ip route getshows the actual decision for a specific destination .onlinkbypasses the gateway reachability check. When the gateway is not on a directly connected subnet, the kernel rejects the route unlessonlinkis specified .ip route addis not persistent. The route exists in the running kernel only. Reboot removes it. Persistence requires configuration through the distribution’s network manager.replaceis safer thanadd. If the route might already exist,replacesucceeds whereaddfails with “File exists” .- Static routes are deterministic, not adaptive. They do not fail over, they do not converge, and they do not learn. They do exactly what the administrator specified, which is why they are used for paths that must not change.
- Verify with a test, not with the table. After adding a route, use
pingortracerouteto confirm traffic actually flows. The table entry is necessary but not sufficient.
Remember: Static routing is the administrator’s direct instruction to the kernel. The kernel stores the instruction, selects it by longest prefix match, and follows it until it is removed. The three commands that matter are ip route add to create, ip route get to verify, and ip route del to remove. The two flags that cause the most confusion are onlink (for gateways outside connected subnets) and persistence (which ip route does not provide). Configure the route, verify the selection, test the path, and persist it. A static route that works in the running configuration but disappears on reboot is not a configuration; it is a test.
Stop using slow, ad-bloated tool sites! 🤮
🔎 Search “KandZ Tools” on Google to use many professional utilities for free.
KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)
⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free
🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!