Default route — 0.0.0.0/0, dual default, floating default, ICMP unreachable

The default route is the catch-all of the routed estate. It matches every destination that no more-specific route covers. In a typical site, the default route points to the upstream provider and is the only path the site has to the rest of the Internet. A misconfigured default can take a site offline in seconds; a well-designed default can carry a site through a provider outage without operator intervention. This lesson covers the default route model in VyOS 1.5 LTS, the canonical configurations, and the failure modes the operator must recognise.

What the default route is

flowchart TD
  A[Packet to 8.8.8.8] --> B[Longest-prefix match]
  B --> C{Any specific match?}
  C -->|yes| D[Use specific route]
  C -->|no| E[Use 0.0.0.0/0 default]
  E --> F[Next-hop: ISP-A]
  E --> G[Next-hop: ISP-B]
  F --> H[Out the egress interface]
  G --> H

The default route is the prefix 0.0.0.0/0. It is the least-specific prefix possible — its prefix length is zero, so it matches every IPv4 destination. The kernel uses longest- prefix-match; the default is the route that wins when no more- specific route exists for a destination.

For a host, the default is the gateway. For a site router, the default is the upstream provider. For a transit router, the default may not exist at all — transit routers have full visibility into the routed Internet and prefer specific routes to a default.

Single-provider default

The canonical configuration is a single static route to 0.0.0.0/0 pointing to the upstream provider’s next-hop:

[edit]
vyos@vyos# set protocols static route 0.0.0.0/0 next-hop 203.0.113.1
[edit]
vyos@vyos# commit
[edit]
vyos@vyos# save

The egress interface is omitted; the kernel performs the recursive lookup against the connected route to the provider and finds the egress. This is the indirect form, the same pattern as for any other static route.

The direct form includes the egress interface explicitly:

[edit]
vyos@vyos# set protocols static route 0.0.0.0/0 next-hop 203.0.113.1 interface eth0
[edit]
vyos@vyos# commit
[edit]
vyos@vyos# save

The direct form is appropriate when the next-hop is on a shared Ethernet segment and the operator wants to pin the egress to a specific interface. It removes a recursive-lookup step from the hot path.

Dual-default redundancy

A site with two upstream providers can install two default routes. Two static routes to 0.0.0.0/0 with the same distance are ECMP candidates; the router load-shares between them.

[edit]
vyos@vyos# set protocols static route 0.0.0.0/0 next-hop 203.0.113.1
[edit]
vyos@vyos# set protocols static route 0.0.0.0/0 next-hop 198.51.100.1
[edit]
vyos@vyos# commit
[edit]
vyos@vyos# save

show ip route shows both:

vyos@vyos:~$ show ip route 0.0.0.0/0
S>* 0.0.0.0/0 [1/0] via 203.0.113.1, eth0
                    via 198.51.100.1, eth1

The two routes are equally preferred. The kernel uses a hash of the source and destination to pick one of the two for each flow. The aggregate capacity is the sum of the two uplinks; the resilience is the property that one uplink can fail and the other continues to carry traffic.

ECMP load-sharing has limitations. The hash is computed on the 5-tuple (source, destination, protocol, source port, destination port). For a small number of long-lived flows, the hash may put all the traffic on one uplink and leave the other idle. For HTTP, the hash is usually balanced enough. For a single TCP flow, the hash is deterministic and one uplink carries the flow end-to-end.

The dual-default pattern with ECMP is not the same as a failover pattern. ECMP load-shares simultaneously; failover moves all traffic from one to the other on failure. The operator must choose the right pattern for the requirement.

Floating default

A floating default activates only when the primary default is withdrawn. The pattern is two static routes to 0.0.0.0/0, one with distance 1 and one with distance 210:

[edit]
vyos@vyos# set protocols static route 0.0.0.0/0 next-hop 203.0.113.1 distance 1
[edit]
vyos@vyos# set protocols static route 0.0.0.0/0 next-hop 198.51.100.1 distance 210
[edit]
vyos@vyos# commit
[edit]
vyos@vyos# save

The primary (203.0.113.1) is preferred. The backup (198.51.100.1) is inactive. When the primary is withdrawn — because the operator deletes the route, because the upstream link goes down, or because a routing protocol withdraws the default — the floating backup becomes active.

show ip route shows the floating state:

vyos@vyos:~$ show ip route 0.0.0.0/0
S>* 0.0.0.0/0 [1/0] via 203.0.113.1, eth0
S   0.0.0.0/0 [210/0] via 198.51.100.1, eth1 inactive

The * is on the primary. The backup has no *; it is in the RIB but not in the FIB. When the primary withdraws, the backup is installed and the * moves.

ICMP unreachable when no route matches

When a packet arrives and no route matches — not even the default — the kernel sends an ICMP Destination Unreachable back to the source:

vyos@vyos:~$ ping -c 3 192.0.2.99
PING 192.0.2.99 (192.0.2.99) 56(84) bytes of data.
From 192.0.2.1 icmp_seq=1 Destination Host Unreachable
From 192.0.2.1 icmp_seq=2 Destination Host Unreachable
From 192.0.2.1 icmp_seq=3 Destination Host Unreachable

--- 192.0.2.99 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss

The From 192.0.2.1 is the local router — the router is generating the unreachable, not the destination. This is the signature of a missing default route or a missing more- specific route.

traceroute exposes the same behaviour:

vyos@vyos:~$ traceroute 192.0.2.99
traceroute to 192.0.2.99 (192.0.2.99), 30 hops max
 1  192.0.2.1  0.123 ms  0.098 ms  0.087 ms
 2  192.0.2.1  0.123 ms  0.098 ms  0.087 ms
 3  192.0.2.1  0.123 ms  0.098 ms  0.087 ms
...

The first hop is the local router, and the router sends unreachable on every hop. This is the signature of a router with no matching route for the destination.

The exception is a blackhole route. A route to 0.0.0.0/0 with blackhole is a valid match for every destination; the kernel drops the packet silently and does not send ICMP unreachable. The host sees the packet disappear. This is the pattern for traffic shaping and DDoS mitigation, covered in a later lesson.

How the result is validated

The validation command set confirms the default is present and active:

vyos@vyos:~$ show ip route 0.0.0.0/0
S>* 0.0.0.0/0 [1/0] via 203.0.113.1, eth0

The * confirms the route is in the FIB. The > confirms it is selected. The distance and metric are the configured values.

The reachability test confirms the default actually works:

vyos@vyos:~$ ping -c 3 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=58 time=12.3 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=58 time=11.8 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=58 time=12.1 ms

--- 1.1.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss

If the ping fails, the default is misconfigured, the next-hop is unreachable, or the upstream provider is down. The operator must distinguish between the three: show ip route 0.0.0.0/0 (configuration), ping <next-hop> (next-hop reachability), and traceroute 1.1.1.1 (upstream reachability).

How it fails

The production failure modes the engineer must recognise:

• Missing default. The router has no 0.0.0.0/0 route. Traffic to Internet destinations is blackholed at the router. Hosts see ICMP unreachable.
• Default with unreachable next-hop. The default is configured but the next-hop is not reachable (no connected route, no ARP). The route is inactive. Traffic is blackholed.
• Default to wrong ISP. A change that re-pointed the default to the wrong ISP. The router is sending all Internet traffic to the wrong network. The provider receives the traffic but has no route back to the source; it sends ICMP unreachable.
• Default and provider route conflict. A site has a default to ISP-A and a more-specific /16 to ISP-B. The /16 wins for the more-specific destination; the default wins for everything else. The operator expected the default to also cover the /16.
• ECMP hash imbalance. Two defaults with the same distance. The hash puts all traffic on one ISP. The other ISP sees no traffic. The aggregate capacity is half of what was provisioned.
• Floating default never activates. The backup default has the same distance as the primary, so it never becomes preferred. The primary fails, the backup is right there, but it does not activate. The site goes offline.

Rollback

The recovery from a bad default configuration:

• Wrong next-hop: set protocols static route 0.0.0.0/0 next-hop <correct>; commit; save.
• Wrong distance: delete protocols static route 0.0.0.0/0 distance; commit; save (back to the default 1).
• Remove the floating backup: delete protocols static route 0.0.0.0/0 next-hop <backup-ip>; commit; save.
• Whole-tree rollback: rollback N; commit; save.

For emergency rollback, replace the candidate with load <file>; commit; save.

Production discipline

Cross-course references

The Linux course’s V-Linux-NetConfig covers the host-side ip route add default via equivalent. The OPNsense course’s XII-OPNsense-StaticRoutes covers the equivalent default- route patterns. The Multi-WAN course’s XXXIX-Multi-WAN covers the dual-default and floating-default patterns in depth. The BGP course’s XXXI-BGP-Troubleshooting covers default-originate from a provider and how a site should consume it.

Quiz