LFCE 16 🐧 Default Gateway and Route Priority
The default gateway is the route of last resort. When the kernel examines a packet’s destination and finds no matching entry in the routing table, it forwards the packet to the default gateway. This single route is what connects a host or a local network to everything beyond its directly attached subnets. Without it, the host can reach its neighbors but nothing else. With it, the host has a path to the entire internet—or at least to whatever the gateway can reach.
Route priority determines what happens when multiple routes could apply. The kernel does not use a single global priority list. It uses two mechanisms in sequence: longest prefix match selects the most specific route, and when multiple routes share the same prefix, the metric selects the preferred one. The default gateway is the least specific route of all, so it only wins when no other route matches. Understanding both mechanisms—specificity and metric—is essential for configuring a Linux host that has more than one path to the outside world.
Key point: You cannot have two default gateways that both function simultaneously. The kernel selects one default route based on the lowest metric, regardless of the order in which the routes were added . A second default route with a higher metric is a standby, not an active alternative—the kernel has no built-in dead gateway detection to fail over automatically .
Why default gateway and priority are separate concerns
The last-resort problem.
Every packet needs a route. If the destination is on a directly connected subnet, the kernel sends the packet directly to the destination’s MAC address. If the destination is elsewhere, the kernel needs a next hop. The default route provides that next hop for every destination that has no specific route. Without it, ip route get 8.8.8.8 returns “Network is unreachable” even if the interface is up and configured . The default gateway is not optional for any host that needs to communicate beyond its local segment.
The multiple-path problem.
A host with two interfaces—one wired, one wireless—may have two possible paths to the internet. Both paths can be expressed as default routes. The kernel cannot use both simultaneously for a single packet. It must choose one. The metric field provides the choice: the route with the lower metric is preferred . NetworkManager assigns default metrics by connection type: Ethernet is preferred over Wi-Fi, which is preferred over WWAN . This ensures that when both are connected, the wired connection carries the traffic unless the administrator overrides the metric.
The failover illusion problem.
A second default route with a higher metric does not provide automatic failover. If the primary gateway goes down, the kernel continues to send packets to it because the route is still present and still has the lower metric. The kernel has no mechanism to detect that the gateway is unreachable and switch to the standby . Failover requires either a dynamic routing protocol, a link-monitoring daemon, or manual intervention to delete the failed route or raise its metric. The standby default route is a configuration convenience—it is present in the table if the primary is manually removed—but it is not an automatic redundancy mechanism.
a. Configuring the default gateway
The default gateway is added as a route with the destination default or 0.0.0.0/0. The via keyword specifies the gateway address, and the dev keyword optionally specifies the outgoing interface.
# Add a default gateway through a specific interface
ip route add default via 192.168.1.1 dev eth0
# Verify the default route exists
ip route show default
# Output: default via 192.168.1.1 dev eth0 proto static
# Ask the kernel how it reaches an external address
ip route get 8.8.8.8
# Output: 8.8.8.8 via 192.168.1.1 dev eth0 src 192.168.1.100The default route can also be added without specifying the interface, provided the gateway is reachable through a connected route. The kernel determines the interface from the gateway address.
# Add a default gateway; interface is inferred from the gateway's subnet
ip route add default via 10.0.0.1
# This fails if 10.0.0.1 is not on a connected subnet
# In that case, specify the interface and use onlinkWhen the gateway is not on a directly connected subnet—common in VPN tunnels and lab environments—the onlink flag is required, as covered in the previous chapter. The default route follows the same rule: the kernel must believe the gateway is reachable before accepting the route.
b. Understanding route priority and metrics
The kernel evaluates routes in two stages. First, it selects the route with the longest matching prefix. A /24 route wins over a /16 route, which wins over the default route. This is the primary priority mechanism and it cannot be overridden by metrics.
# Two routes to the same destination with different specificity
ip route add 10.20.0.0/16 via 10.0.0.1
ip route add 10.20.30.0/24 via 10.0.0.2
# A packet to 10.20.30.5 matches both
# The /24 is longer, so it wins regardless of metric
ip route get 10.20.30.5
# Output: 10.20.30.5 via 10.0.0.2Second, when multiple routes have the same prefix length, the metric determines which one is preferred. Lower metric values are preferred over higher ones .
# Two default routes with different metrics
ip route add default via 192.168.1.1 dev eth0 metric 100
ip route add default via 10.0.0.1 dev eth1 metric 200
# The kernel selects the lower metric
ip route get 8.8.8.8
# Output: 8.8.8.8 via 192.168.1.1 dev eth0
# The second default route exists in the table but is not selected
ip route show default
# default via 192.168.1.1 dev eth0 metric 100
# default via 10.0.0.1 dev eth1 metric 200The order in which the routes are added does not matter. The kernel sorts by metric, not by insertion order . A route added later with a lower metric becomes the active route. A route added later with a higher metric remains standby.
NetworkManager assigns default metrics based on connection type. Ethernet connections receive a lower metric than Wi-Fi connections, ensuring that wired traffic is preferred when both are available . The metric can be overridden per connection.
# Check the metric assigned to a connection
nmcli connection show "eth0" | grep route-metric
# Override the metric
nmcli connection modify "eth0" ipv4.route-metric 50
nmcli connection up "eth0"c. Verifying the active gateway and troubleshooting
The ip route get command is the definitive verification. It shows the route the kernel will actually use for a specific destination, including the gateway, interface, and source address.
# Verify the path to an external destination
ip route get 1.1.1.1
# Output: 1.1.1.1 via 192.168.1.1 dev eth0 src 192.168.1.100
# If the output shows "via" with an unexpected gateway, check the metrics
ip route show default
# If the output shows "Network is unreachable", no default route existsWhen a default route is present but traffic does not flow, the problem is downstream of the host. The gateway may be unreachable at layer 2, the gateway may not have a route to the destination, or a firewall may be blocking the traffic. The host’s routing table cannot diagnose these issues; only a test from the gateway or a packet capture on the path can.
# Test gateway reachability directly
ping -c 2 192.168.1.1
# Test an external address
ping -c 2 8.8.8.8
# If the gateway responds but the external address does not, the problem is at or beyond the gatewayComplete Example Session
# ============================================
# PART 1: INSPECT THE CURRENT DEFAULT ROUTE
# ============================================
ip route show default
# Output shows the active default gateway and its metric
# ============================================
# PART 2: VERIFY THE PATH TO AN EXTERNAL DESTINATION
# ============================================
ip route get 8.8.8.8
# Output confirms the gateway, interface, and source address
# ============================================
# PART 3: ADD A DEFAULT GATEWAY
# ============================================
ip route add default via 192.168.1.1 dev eth0
# ============================================
# PART 4: ADD A SECOND DEFAULT GATEWAY WITH HIGHER METRIC
# ============================================
# This route is a standby; it will not be selected while the first exists
ip route add default via 10.0.0.1 dev eth1 metric 200
# ============================================
# PART 5: VERIFY THE ACTIVE ROUTE
# ============================================
ip route get 8.8.8.8
# Output shows the lower-metric gateway (192.168.1.1)
# ============================================
# PART 6: ADD A SPECIFIC ROUTE THAT OVERRIDES THE DEFAULT
# ============================================
# Traffic to 203.0.113.0/24 uses a different gateway
ip route add 203.0.113.0/24 via 192.168.1.2 dev eth0
# ============================================
# PART 7: VERIFY LONGEST PREFIX MATCH
# ============================================
ip route get 203.0.113.10
# Output: 203.0.113.10 via 192.168.1.2 (the specific route wins)
ip route get 8.8.8.8
# Output: 8.8.8.8 via 192.168.1.1 (the default route still applies)
# ============================================
# PART 8: CHANGE THE ACTIVE GATEWAY BY METRIC
# ============================================
# Lower the metric of the second gateway to make it active
ip route replace default via 10.0.0.1 dev eth1 metric 50
ip route get 8.8.8.8
# Output now shows 10.0.0.1 as the gateway
# ============================================
# PART 9: REMOVE THE SECONDARY GATEWAY
# ============================================
ip route del default via 10.0.0.1 dev eth1
ip route get 8.8.8.8
# Output reverts to the remaining default gateway
# ============================================
# PART 10: PERSIST THE GATEWAY WITH NETWORKMANAGER
# ============================================
nmcli connection modify "eth0" ipv4.gateway 192.168.1.1
nmcli connection up "eth0"
# The gateway survives reboot through the connection profileThe ten parts demonstrate the complete lifecycle: inspect, add, verify, add a standby, verify selection, add a specific override, change priority by metric, remove, and persist. The critical verification is always ip route get, which shows the kernel’s actual decision rather than the table’s contents.
Quick Reference
Default Gateway Commands
| Task | Command |
|---|---|
| Add default gateway | ip route add default via <gw> |
| Add with metric | ip route add default via <gw> metric <n> |
| Replace default | ip route replace default via <gw> |
| Delete default | ip route del default |
| Show default routes | ip route show default |
| Verify selection | ip route get <dest> |
| Persist via nmcli | nmcli connection modify <name> ipv4.gateway <gw> |
Priority Rules
| Rule | Mechanism | Overridable by Metric? |
|---|---|---|
| Longest prefix match | Most specific route wins | No |
| Same prefix, different metrics | Lower metric wins | Yes |
| Default route | Least specific; last resort | N/A |
| Addition order | Does not affect selection | N/A |
NetworkManager Default Metrics
| Connection Type | Relative Metric | Preference |
|---|---|---|
| Ethernet | Lowest | Preferred |
| Wi-Fi | Medium | Fallback |
| WWAN | Highest | Last resort |
Best Practices
✅ Do This:
# Verify the active gateway with ip route get
ip route get 8.8.8.8 # ✅
# Use metrics to control which default route is selected
ip route add default via <gw> metric 100 # ✅
# Understand that a second default route is standby, not failover
# The kernel does not detect dead gateways # ✅
# Persist the gateway through NetworkManager
nmcli connection modify <name> ipv4.gateway <gw> # ✅
# Test gateway reachability before blaming the route
ping -c 2 <gateway> # ✅
# Use specific routes for destinations that must bypass the default
ip route add <net> via <other-gw> # ✅❌ Don’t Do This:
# Expect two default gateways to load-balance
# The kernel selects one based on metric # ❌
# Expect automatic failover to a standby gateway
# The kernel has no dead gateway detection # ❌
# Assume addition order determines priority
# Metric determines priority; order does not # ❌
# Add a default route without verifying it is selected
# ip route get confirms the decision # ❌
# Use a gateway that is not reachable
# The kernel rejects the route or traffic is dropped # ❌
# Forget that NetworkManager may overwrite manual changes
# Use nmcli for persistent configuration # ❌Common Pitfalls
| Pitfall | Why It Happens | Fix |
|---|---|---|
| Two default routes, neither works | Both have the same metric; kernel selects unpredictably | Assign distinct metrics |
| Traffic goes to the wrong gateway | Metric of the intended gateway is higher | Lower the metric or replace the route |
| Standby gateway never used after primary failure | Kernel lacks dead gateway detection | Use a routing protocol or manual failover |
| Default route lost after reboot | ip route add is not persistent | Configure through NetworkManager |
| “Network is unreachable” for external IP | No default route exists | Add default via <gw> |
| Gateway responds to ping but internet fails | Gateway has no route to the destination | Check the gateway’s routing table |
Real-World Examples
1. Add a default gateway
ip route add default via 192.168.1.1 dev eth02. Add a default gateway with metric
ip route add default via 10.0.0.1 dev eth1 metric 2003. Verify the active gateway
ip route get 8.8.8.84. Change priority by metric
ip route replace default via 10.0.0.1 dev eth1 metric 505. Add a specific route that bypasses default
ip route add 203.0.113.0/24 via 192.168.1.26. Show all default routes
ip route show default7. Delete a specific default route
ip route del default via 10.0.0.1 dev eth18. Persist gateway with nmcli
nmcli connection modify "eth0" ipv4.gateway 192.168.1.19. Check NetworkManager metric
nmcli connection show "eth0" | grep route-metric10. Test gateway reachability
ping -c 2 192.168.1.1Visual
Route Selection: Prefix Length First, Metric Second
┌──────────────────────────────────────────────────────────────┐
│ THE KERNEL'S SELECTION PROCESS │
│ │
│ Packet arrives with destination 10.20.30.40 │
│ │
│ Step 1: Find all routes whose prefix matches │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ 10.20.30.0/24 via 10.0.0.2 metric 100 │ │
│ │ 10.20.0.0/16 via 10.0.0.1 metric 50 │ │
│ │ 0.0.0.0/0 via 192.168.1.1 metric 100 │ │
│ └────────────────────────────────────────────────────────┘ │
│ │
│ Step 2: Select the longest prefix │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ /24 (24 bits) beats /16 (16 bits) beats /0 (0 bits) │ │
│ │ Selected: 10.20.30.0/24 via 10.0.0.2 │ │
│ └────────────────────────────────────────────────────────┘ │
│ │
│ Step 3: If multiple routes share the same prefix, │
│ select the lowest metric │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ 10.20.30.0/24 via 10.0.0.2 metric 100 │ │
│ │ 10.20.30.0/24 via 10.0.0.3 metric 200 │ │
│ │ Selected: metric 100 (10.0.0.2) │ │
│ └────────────────────────────────────────────────────────┘ │
│ │
│ Metric cannot override prefix length. │
│ A /16 with metric 1 loses to a /24 with metric 999. │
└──────────────────────────────────────────────────────────────┘Two Default Gateways: Active and Standby
┌──────────────────────────────────────────────────────────────┐
│ TWO DEFAULT ROUTES, ONE ACTIVE │
│ │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ default via 192.168.1.1 metric 100 ← ACTIVE │ │
│ │ default via 10.0.0.1 metric 200 ← STANDBY │ │
│ └────────────────────────────────────────────────────────┘ │
│ │
│ Traffic to 8.8.8.8: │
│ ip route get 8.8.8.8 │
│ → 8.8.8.8 via 192.168.1.1 dev eth0 │
│ │
│ If 192.168.1.1 fails: │
│ - The route remains in the table │
│ - The kernel continues to send packets to it │
│ - No automatic failover to 10.0.0.1 │
│ - The kernel has no dead gateway detection │
│ │
│ To fail over manually: │
│ ip route del default via 192.168.1.1 │
│ → The standby route becomes active │
└──────────────────────────────────────────────────────────────┘NetworkManager Metric Priority
┌──────────────────────────────────────────────────────────────┐
│ DEFAULT METRICS BY CONNECTION TYPE │
│ │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ Ethernet (eth0) │ │
│ │ metric: 100 │ │
│ │ ██████████████████████████████████████████████████████ │ │
│ │ PREFERRED │ │
│ └────────────────────────────────────────────────────────┘ │
│ │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ Wi-Fi (wlan0) │ │
│ │ metric: 600 │ │
│ │ ██████████████████████████████████████████████████████ │ │
│ │ FALLBACK │ │
│ └────────────────────────────────────────────────────────┘ │
│ │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ WWAN (wwan0) │ │
│ │ metric: 700 │ │
│ │ ██████████████████████████████████████████████████████ │ │
│ │ LAST RESORT │ │
│ └────────────────────────────────────────────────────────┘ │
│ │
│ Lower metric = higher priority. │
│ Override with: nmcli connection modify <name> │
│ ipv4.route-metric <value> │
└──────────────────────────────────────────────────────────────┘Summary
| Item | Value |
|---|---|
| Default route syntax | default or 0.0.0.0/0 |
| Add command | ip route add default via <gw> |
| Verification | ip route get <dest> |
| Primary priority rule | Longest prefix match |
| Secondary priority rule | Lower metric wins for same prefix |
| Addition order | Does not affect selection |
| Two default routes | One active (lower metric), one standby |
| Automatic failover | Not provided by the kernel |
| NetworkManager metrics | Ethernet < Wi-Fi < WWAN |
| Persistence | nmcli connection modify ipv4.gateway |
Key takeaways:
- The default gateway is the route of last resort. It matches only when no more specific route applies. Without it, the host cannot reach destinations outside its directly connected subnets .
- Longest prefix match is the primary priority mechanism. A
/24route always wins over a/16route, regardless of metric. Metrics only break ties between routes with the same prefix length. - Lower metric wins. When two routes share a prefix, the kernel selects the one with the lower metric. The order of addition is irrelevant .
- Two default gateways do not provide failover. The second route is a standby that becomes active only if the first is removed. The kernel does not detect dead gateways .
- NetworkManager assigns metrics by connection type. Ethernet is preferred over Wi-Fi, which is preferred over WWAN. The metric can be overridden per connection .
ip route getis the definitive verification. The routing table may contain multiple routes;ip route getshows which one the kernel actually selects for a specific destination.
Remember: The default gateway is a single route with a single job: catch everything that no other route matches. When multiple default routes exist, the kernel selects one by metric and ignores the rest until the active route is removed. This is not a limitation to work around; it is the design. Route priority is deterministic: specificity first, metric second, and the default route last. Configure the gateway, verify it with ip route get, and understand that a standby route is a manual failover tool, not an automatic one.
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!