Static and default routes — explicit paths

Static and default routes are the routes the operator writes by hand. They are the simplest routing primitive, the easiest to diagnose, and the most common cause of “the route I configured is not being used” incidents. The operator who understands static and default routes can quickly diagnose the failure modes that arise from AD conflicts, recursive next-hop resolution, and prefix overlap.

This lesson is the operator’s foundation in static and default routes: how to configure them, how they interact with connected and dynamic routes, and the production failure modes.

What a static route is

A static route is a manual entry in the routing table that instructs the kernel to forward traffic matching the prefix to a specific next-hop or interface. The kernel installs the route when the configuration is committed; the route persists until the configuration is removed.

flowchart LR
  H["Host"] -->|"packet to 10.0.0.50"| R["VyOS router"]
  R -->|"static route: 10.0.0.0/24 via 192.0.2.1"| NH["Next-hop 192.0.2.1"]
  NH --> E["Egress interface eth0"]
  E --> D["Destination"]

The VyOS configuration:

configure
set protocols static route 10.0.0.0/24 next-hop 192.0.2.1
commit
save

The kernel installs the entry. The administrative distance is 1 (default for static routes). The next-hop is 192.0.2.1. The egress interface is inferred by the kernel through a route lookup on 192.0.2.1 itself.

What a default route is

A default route is a static route for the prefix 0.0.0.0/0 — the route that matches every destination the kernel does not have a more specific route for.

configure
set protocols static route 0.0.0.0/0 next-hop 192.0.2.1
commit
save

The kernel installs the entry with administrative distance 1. When the kernel looks up a destination that has no more specific route, the default route wins.

A default route is appropriate when:

• The router is at an edge of a network and the upstream is the only path out.
• The router is on a stub network and all outbound traffic takes the same path.
• The operator wants a fallback for traffic the dynamic protocol has not learned.

A default route is inappropriate when:

• The router has multiple upstreams and the operator wants different traffic to take different paths (use policy routing instead).
• The router is in the middle of a network and the upstream is not always the right path (use specific static routes or a dynamic protocol).

Recursive vs direct next-hops

A static route has two ways to specify the next-hop:

• Direct next-hop — the next-hop is directly connected on a known interface. The kernel knows the egress interface immediately.
• Recursive next-hop — the next-hop is reachable only through another route in the table. The kernel performs a recursive lookup on the next-hop itself.

# Direct next-hop
set protocols static route 10.0.0.0/24 next-hop 192.0.2.1

# Interface-only next-hop (treated as directly connected)
set protocols static route 10.0.0.0/24 interface eth0

# Recursive next-hop (will be resolved through the main table)
set protocols static route 10.0.0.0/24 next-hop 198.51.100.1

For the recursive case, the kernel looks up 198.51.100.1 in the main table, gets the egress interface (eth1), and uses that. The route to 10.0.0.0/24 is now bound to eth1 through 198.51.100.1.

Distance, metric, and route preference

The static route’s distance (administrative distance) is configurable. The default is 1. Higher values make the static route less preferred than other routes with lower AD.

# Higher AD = less preferred; only used as floating backup
set protocols static route 10.0.0.0/24 next-hop 198.51.100.1 distance 200

When two static routes cover the same prefix with different distances, the lower-distance wins.

The static route’s metric is also configurable. The metric breaks ties when two routes have the same AD.

# Lower metric = more preferred when AD is the same
set protocols static route 10.0.0.0/24 next-hop 192.0.2.1 metric 10
set protocols static route 10.0.0.0/24 next-hop 198.51.100.1 metric 20

Both have AD 1; the metric 10 wins.

Blackhole and reject routes

A blackhole route is a static route that discards packets. A reject route is a static route that sends ICMP unreachable back to the source.

# Blackhole: silently discard
set protocols static route 10.10.0.0/16 blackhole

# Reject: ICMP unreachable to the source
set protocols static route 10.10.0.0/16 reject

The kernel installs the entry. Packets matching the prefix are discarded (blackhole) or rejected with ICMP unreachable (reject). No ARP / ND lookup, no firewall, no NAT.

Blackhole routes are useful for:

• Route-leak protection — a summary route with a blackhole supporting route ensures traffic to the summary is discarded (not forwarded into a routing loop) when no more-specific route exists.
• DDoS mitigation — blackhole the destination prefix; upstream DDoS-scrubbing services can direct traffic to the blackhole.
• Test conditions —** a blackhole route simulates “the destination is unreachable” without actually breaking a real network.

Reject routes are useful when the operator wants the source to know the destination is unreachable (so the source can route around it) but does not want the destination to be reachable.

flowchart LR
  P["Packet to 10.10.0.50"] --> R["VyOS router"]
  R -->|"blackhole route match"| D["Silently discarded"]
  P2["Packet to 10.20.0.50"] --> R2["VyOS router"]
  R2 -->|"reject route match"| I["ICMP unreachable\nsent back to source"]

Interface-only static routes attach the route to an interface:

set protocols static route 10.0.0.0/24 interface eth0

This is the PPPoE-style configuration where the next-hop is implicitly the upstream endpoint of the interface. The kernel treats the egress interface as the next-hop, and the egress queue handles the encapsulation.

For most production routes, the explicit next-hop is preferred. Interface-only routes are useful for PPPoE, tunnels, and other interfaces where the upstream is implicit.

Static routes for VPN and tunnel traffic

A common production pattern: static routes that direct VPN traffic over a tunnel.

configure
# Branch traffic to corporate
set protocols static route 10.100.0.0/16 next-hop 192.168.255.1
# Where 192.168.255.1 is the WireGuard peer's tunnel IP

# More-specific routes for high-priority subnets
set protocols static route 10.100.1.0/24 next-hop 192.168.255.1 distance 50
commit
save

The distance 50 makes the more-specific route the preferred path even when a dynamic protocol (e.g. BGP) advertises a less specific summary. The operator who has both static and dynamic routes must understand which wins — the static with the lower distance, and the more-specific prefix wins via LPM.

Operational commands

The operator verifies static routes with:

show ip route
show ip route static
ip route show type static
ip route show table all type static
ip route get <dst>

ip route show type static filters the routing table to static entries. ip route show table all type static does the same but across all tables (including the local table).

Failure modes

Static route not installed

The static route is configured but not in the kernel FIB.

Causes:

• A more-specific connected route covers the prefix.
• The next-hop is unreachable (recursive-failed).
• The interface referenced by the static route is down.

Diagnostic:

• ip route show <prefix> shows the route, but ip route get <dst> returns a different route.
• ip route show <prefix> verify shows the route with a marker indicating it is installed or not.

Static route points to the wrong next-hop

The static route is installed but the next-hop is wrong.

Causes:

• Typo in the configuration.
• The intended next-hop has changed (e.g. a router renumbering).
• The operator confused a primary and a backup path.

Diagnostic:

• ip route get <dst> returns the configured next-hop.
• ping <next-hop> from the router fails (next-hop is unreachable).
• traceroute <dst> shows the unexpected path.

Two static routes to the same prefix

Two static routes with different next-hops.

Causes:

• Configuration drift between an old and a new path.
• A floating static was added but never removed.

Diagnostic:

• ip route show <prefix> shows both routes.
• Only one is selected (> marker); the other is in the table but unused.

Static route survives an interface failure

The static route points to an interface (or via a next-hop that is reachable through an interface). When the interface goes down, the static route is marked as failed and packets to the destination are dropped. The static route does not automatically switch to a backup path; that requires a floating static with a higher AD.

Diagnostic:

• ip link show dev <interface> shows the interface is down.
• ip route show <prefix> shows the static route with a “dead” or “linkdown” marker (depending on kernel version).

Validation

The validation sequence for “the static route is wrong”:

1. The route is configured: show configuration | match "static route" shows the entry.
2. The route is installed: ip route show <prefix> shows the entry.
3. The next-hop is reachable: ip neigh show <next-hop> returns REACHABLE or STALE.
4. The egress interface is up: ip link show dev <egress-if> returns state UP.
5. The path is correct: traceroute <dst> shows the expected hops.
6. Traffic flows: ping <dst> from a host on the relevant subnet succeeds.
7. The AD is correct: show ip route <prefix> shows the AD value; compare to the dynamic protocol’s AD to ensure the static wins when intended.

Cross-course references

• The Linux course’s V-Linux-NetConfig covers static routes from the host perspective.
• The lesson on routing tables in Part II covers the field semantics in depth.
• The lesson on longest-prefix match in Part II covers the LPM-first / AD-second ordering.
• The lessons on policy routing and multi-WAN later in the course cover the routing patterns that build on static routes.

Quiz

Production discipline

Static and default routes are the simplest routing primitive. Plan the static routes once. Document the AD ordering. Validate the recursive resolution. Test the failure modes. Then routing either works or fails predictably.