Linux Routing Tables: How to Read and Edit Them

Every packet that enters or leaves a Linux server passes through the routing table. The kernel consults it to decide which interface to send a packet out of, which gateway to forward it to, and whether to drop it entirely. Understanding routing tables is essential for multi-homed servers, VPN setups, and debugging connectivity issues that go beyond simple up-or-down problems.

Reading the Routing Table

The command to inspect the routing table is ip route show. On a typical single-NIC VPS the output looks simple, but every line tells you something important.

ip route show

A sample output might look like this: default via 10.0.0.1 dev eth0 proto dhcp metric 100, followed by 10.0.0.0/24 dev eth0 proto kernel scope link src 10.0.0.5 metric 100. The first line is the default route. Any packet whose destination does not match a more specific route goes through the gateway at 10.0.0.1 out of eth0. The second line is the connected route. The kernel automatically creates this when you assign an IP address. It says that the entire 10.0.0.0/24 subnet is directly reachable through eth0.

The metric value determines priority when multiple routes exist. Lower metric means higher priority. If you have two default routes, the one with the lower metric wins.

How the Kernel Chooses a Route

The Linux kernel uses longest prefix matching. When a packet arrives, it looks through the routing table and finds the most specific match. A /32 route always beats a /24, which beats a /16, which beats a /0 (the default). If two routes have the same prefix length, the lower metric wins. If they also have the same metric, the kernel uses the most recently added route.

This is why a specific route to 10.0.0.50/32 via a different gateway will override the connected route for that single host. The rest of the subnet still uses the normal path. This technique is called policy routing and is the foundation for split-tunnel VPNs and multi-path networking.

Adding and Deleting Static Routes

Adding a route is straightforward with ip route add. Here are the most common patterns.

ip route add 192.168.20.0/24 via 10.0.0.2 dev eth0
ip route add 172.16.0.0/16 via 10.0.0.254 metric 200
ip route del 192.168.20.0/24
ip route replace 10.10.0.0/16 via 10.0.0.2

The replace subcommand is particularly useful. It adds a route if it does not exist, or updates it if it does. This makes configuration scripts idempotent. The via keyword specifies the next-hop gateway. The dev keyword specifies the outgoing interface. In most cases the kernel can figure out the interface from the gateway address, but being explicit avoids ambiguity on multi-NIC servers.

The Routing Table on a Multi-Homed Server

A multi-homed server has multiple network interfaces, each on a different subnet. This is common for servers that serve public traffic on one NIC and use a private management network on another. Each interface adds its own connected route, and you need to configure which interface handles which traffic.

ip route show table all
ip route add 10.100.0.0/16 via 10.0.1.1 dev eth1 table 100
ip rule show
ip rule add from 10.0.1.0/24 table 100 priority 100

The table keyword creates a named routing table separate from the main table. The ip rule command creates policy rules that direct the kernel to use specific tables based on source address, incoming interface, or other packet attributes. This is how production servers separate public and private traffic cleanly.

Persistent Routes

Routes added with ip route add disappear on reboot. To make them permanent, the method depends on your network stack. With Netplan, add a routes block to your YAML configuration. With systemd-networkd, add [Route] sections to your .network file. With NetworkManager, use the connection profile with nmcli.

nmcli connection modify eth0 +ipv4.routes "192.168.20.0/24 10.0.0.2"
nmcli connection up eth0

Always prefer the native configuration method of your network daemon over adding ip route commands to rc.local or cron. Those hacks work until they do not, and they leave no documentation of intent.

Debugging Routing Issues

When connectivity is broken and the interface is up, the routing table is the first place to look. Check whether the default route exists, whether the gateway is reachable, and whether there are conflicting routes. Use ip route get to ask the kernel where it would send a specific destination address.

ip route get 8.8.8.8
ip route get 192.168.20.50
ip route get 10.0.0.5 from 10.0.1.5

The output shows the exact route the kernel would use, including the table, the outgoing device, and the source address. This is invaluable for debugging policy routing where packets might be taking unexpected paths.

Managing routes correctly is a core skill for any Linux sysadmin. You can practice routing configurations on a multi-interface VPS from Netbay at netbayhosts.in.