Linux Routing

Linux routing determines how the kernel forwards packets between network interfaces. Whether a server reaches a local subnet, an internal service, or the public Internet, the decision begins with the routing table. Learning to inspect and manage that table is essential for system administration, network troubleshooting, and designing multi-homed hosts.
A routing table contains entries that map destination networks to an outgoing path. Common route attributes include:

  • Destination: The network or host covered by the route, such as 192.168.1.0/24.
  • Gateway: The address of the next router.
  • Interface: The network device used to send the packet.
  • Metric: A preference value used when several routes cover the same destination.
  • Source address: An address the kernel may select as the packet’s source.
  • Scope and protocol: Information about route reachability and how the route was installed.

Linux uses longest-prefix matching to choose a route. A /32 host route is more specific than a /24 subnet route, while the default route, written as 0.0.0.0/0, matches any address not covered by a more specific entry. Among routes with equivalent prefixes, the kernel generally prefers the one with the lower metric.

If no route matches, the packet cannot be forwarded. Applications may then receive an error such as Network is unreachable.

Inspecting the routing table

The ip command from the iproute2 package is the standard tool for modern Linux systems:

ip route show

A typical result might look like this:

default via 192.168.1.1 dev eth0 proto dhcp metric 100
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.10
10.0.0.0/8 via 192.168.1.254 dev eth0

The first line is the default route. The second is a directly connected subnet, and the third sends traffic for 10.0.0.0/8 through another gateway.

Useful variations include:

ip route show table all
ip address show
ip rule show

The first command displays routes in all routing tables, while ip rule show reveals how the kernel decides which table to consult.

Older commands such as route -n and netstat -rn may still be available, but ip route provides clearer output and supports modern features such as policy routing.

Adding and removing routes

A temporary static route can be created with ip route add:

ip route add 10.0.0.0/8 via 192.168.1.254 dev eth0
ip route add 172.16.5.100/32 via 192.168.1.254

The first command routes an entire private network through a gateway. The second installs a host-specific route.

To install or replace a default route:

ip route add default via 192.168.1.1 dev eth0
ip route replace default via 192.168.2.1 dev eth0

Routes can be removed with:

ip route del 10.0.0.0/8

These changes affect the running kernel immediately, but they are normally lost after a reboot. That makes them ideal for testing a proposed route before committing it to the system’s persistent network configuration.

The gateway must normally be reachable through a directly connected interface. If it is not, the route may require an onlink designation, although that should be used only when the network topology genuinely permits it.

Persisting configuration with Netplan

Ubuntu commonly uses Netplan to generate the configuration consumed by systemd-networkd or NetworkManager. A static route can be defined under an interface:

network:
  version: 2
  ethernets:
    eth0:
      addresses:
        - 192.168.1.10/24
      routes:
        - to: 10.0.0.0/8
          via: 192.168.1.254
        - to: default
          via: 192.168.1.1

After editing the relevant file, validate and apply the configuration:

sudo netplan generate
sudo netplan apply

On a remote machine, netplan try is safer because it reverts the configuration if the connection is not confirmed before the timeout expires. If DHCP already supplies a default route, adding another explicit default gateway may create unexpected behavior, so the existing configuration should be reviewed first.

Persisting routes with NetworkManager

On RHEL, CentOS, and many other NetworkManager-based distributions, routes can be attached directly to a connection profile:

nmcli connection modify eth0 +ipv4.routes "10.0.0.0/8 192.168.1.254"
nmcli connection up eth0

Use nmcli connection show to identify the exact profile name if it differs from the interface name.

Debian systems using ifupdown can execute route commands when an interface starts:

auto eth0
iface eth0 inet static
    address 192.168.1.10
    netmask 255.255.255.0
    gateway 192.168.1.1
    post-up ip route add 10.0.0.0/8 via 192.168.1.254

Because persistent configuration methods differ significantly between distributions, administrators should identify which tool owns the interface before editing files. Mixing Netplan, NetworkManager, and manually maintained routes can lead to duplicate or conflicting entries.

Policy routing

A basic Linux host normally consults the main routing table. Policy routing makes it possible to maintain separate tables and select one according to source address, destination, incoming interface, or other matching criteria.

For example, traffic originating from 10.0.0.5 can use a dedicated Internet connection:

ip route add 10.0.0.0/24 dev eth1 table 100
ip route add default via 10.0.0.1 dev eth1 table 100
ip rule add from 10.0.0.5/32 lookup 100 priority 100

Rules are evaluated by priority, with lower numbers checked first. The route lookup then proceeds within the selected table. This mechanism is useful for multihoming, separating internal and external traffic, and applying different paths to particular services.

Policy changes should also be made persistent through the relevant network configuration system. Otherwise, they may disappear after a reboot even though the main routes remain intact.

Essential troubleshooting techniques

One of the most useful diagnostic commands is:

ip route get 8.8.8.8

It simulates the kernel’s routing decision and shows which gateway, interface, and source address would be used. A source address can be specified for more precise tests:

ip route get 8.8.8.8 from 10.0.0.5

Other useful checks include:

  • traceroute or mtr to identify where a path stops or becomes unstable.
  • ip address show to confirm that interfaces have the expected addresses.
  • ip neigh to inspect neighbor resolution for directly connected gateways.
  • ip route show table all and ip rule show to detect missing or incorrectly ordered policy routes.
  • Interface and system logs to find DHCP updates or network services overwriting manual settings.

Reverse path filtering can also affect hosts with multiple interfaces. If rp_filter is set too strictly, asymmetric routing may be rejected even though the forward path is valid. Its settings can be reviewed under /proc/sys/net/ipv4/conf/ and controlled through sysctl, but changes should be tested carefully because they affect packet validation globally or per interface.

Building reliable routing practices

Effective Linux routing management combines three habits: understand the intended traffic path, verify it with ip route get, and store the final configuration in the tool used by the distribution. Temporary ip route commands are valuable for diagnosis, while persistent configuration should be handled through Netplan, NetworkManager, systemd-networkd, or the platform’s established configuration-management system.

For complex environments, policy routing provides precise control, but it also increases the need for documentation. Recording route tables, rule priorities, gateway dependencies, and expected return paths makes future maintenance safer and reduces the time required to diagnose connectivity issues.