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.

CheckWhat does via 192.168.224.2 indicate?

The only application allowed to use the route. The next-hop gateway for the route. The route's filesystem mount point.

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.

CheckHow is a connected scope link destination normally reached?

Through the default gateway even when a connected route matches. By converting the destination into a DNS server. Directly through the named interface after neighbor resolution.

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.

CheckWhich route normally matches 192.168.224.50 more specifically?

192.168.224.0/24 dev eth0 default via 192.168.224.2 192.168.0.0/16 via 192.168.224.3

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.

CheckWhy might ip route show alone not explain an application's path?

Policy rules or another network namespace can select different routing state. Linux routing tables contain no destination prefixes. Applications never send IP packets.

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.

CheckWhat does ip route get not do?

Display the chosen local interface and next hop. Evaluate current local route policy for a destination. Prove successful delivery through every downstream hop.

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.