Routing Table

Linux routing state determines which next hop, interface, and source are eligible for an IP destination. The legacy route -n view is still encountered, but ip route exposes modern kernel routing concepts more directly.

Reading IPv4 Routes

Example output can look like:

$ ip -4 route show
default via 192.168.224.2 dev eth0 proto dhcp src 192.168.224.10 metric 100
192.168.224.0/24 dev eth0 proto kernel scope link src 192.168.224.10 metric 100

The connected /24 route sends matching destinations directly through eth0. The default uses next-hop gateway 192.168.224.2. proto describes how the route was installed, src is a preferred source for matching traffic, and a metric helps rank otherwise comparable routes.

Connected and Default Routes

A route with scope link and no via next hop treats the prefix as directly reachable on the interface. A default route matches every address but loses to any eligible more-specific route.

Prefix Length and Metric

Route selection considers policy rules and chooses the longest eligible prefix. Metrics rank routes within appropriate comparable sets; a low-metric default does not override a matching /24 merely because its number is lower.

Policy Rules and Multiple Tables

Linux can consult several routing tables according to ip rule policy based on source, mark, interface, or other selectors. Viewing only the main table can therefore miss the actual path:

$ ip rule show
$ ip route show table all

Network namespaces and VRFs can hold separate state as well. Run inspection in the same context as the affected process.

Querying an Effective Route

Ask the kernel to evaluate a destination and optional source:

$ ip route get 203.0.113.10
$ ip route get 203.0.113.10 from 192.168.224.10

The result predicts the local lookup at that moment. It does not send a probe or prove neighbor, downstream, firewall, or application reachability.

Summary

You can now read Linux routing entries and query the effective local decision.

1. Distinguish connected routes from routes through a gateway.
2. Read prefix, interface, protocol, source, and metric fields.
3. Apply longest-prefix matching before comparing relevant metrics.
4. Account for policy tables, namespaces, and VRFs.
5. Treat ip route get as a lookup, not a reachability test.