Routes Decide the Next Step

An IP address tells a host the destination. A routing table helps the host decide where to send the packet next.

Routing is a decision process, not a list of places on the internet.

Read a simplified routing table

Consider this supplied fictional state:

192.0.2.0/24 dev eth0 src 192.0.2.10
203.0.113.0/24 via 192.0.2.254 dev eth0
default via 192.0.2.1 dev eth0

Three routes are visible.

Connected route

192.0.2.0/24 dev eth0

Traffic for this prefix can be delivered through the local interface according to the local-link mechanisms.

Specific routed prefix

203.0.113.0/24 via 192.0.2.254 dev eth0

Traffic for that prefix should go to next hop 192.0.2.254.

Default route

default via 192.0.2.1 dev eth0

This is the fallback when no more-specific route matches.

Longest-prefix matching chooses the most specific route

Suppose the destination is:

203.0.113.50

Both the specific 203.0.113.0/24 route and the default route could conceptually match, but the /24 route is more specific.

So the next hop is:

192.0.2.254

For destination:

198.51.100.20

there is no specific matching prefix in the supplied table, so the default route points to:

192.0.2.1

This mechanism is more useful than memorizing “default gateway means internet.” A default route is simply the least-specific fallback route.

A gateway must itself be reachable

A route can look syntactically correct and still fail operationally.

If the host says:

default via 192.0.2.1 dev eth0

but eth0 is down, the route cannot deliver through that interface.

If the next hop is not reachable on the expected local link, that creates another failure.

If the router itself lacks a route beyond that point, the client configuration alone cannot fix the entire path.

Reachability is a chain.

Diagnose route choices from evidence

Use this table:

Now add:

198.51.100.99/32 via 192.0.2.253 dev eth0

What route is selected for 198.51.100.99?

The /32 host route is more specific than default, so the next hop becomes 192.0.2.253.

Optional local observation

On an authorized Linux VM, this command reads the local routing table:

ip route

A safer focused query is:

ip route get 127.0.0.1

That stays local.

If your classroom environment provides a disposable isolated network, your teacher may provide a documentation-only or isolated destination for route observation. Do not substitute a random public system.

Failure case: the wrong next hop

Supplied baseline:

default via 192.0.2.1 dev eth0

Changed state:

default via 192.0.2.99 dev eth0

Supplied evidence:

route selected: default via 192.0.2.99
next-hop resolution: failed
application result: connection timeout

What is the bounded hypothesis?

The changed default route directs off-prefix traffic toward a next hop that the supplied lab cannot resolve on the local link, which is consistent with the observed timeout.

Do not claim “the network is hacked.” The evidence shows a route change and a resulting path failure.

Correct one variable

In the paper/simulated model, restore:

default via 192.0.2.1 dev eth0

Supplied retest:

route selected: default via 192.0.2.1
next-hop resolution: success
TCP handshake to fictional server: success

This supports a stronger causal claim because one relevant variable changed and the path recovered in the same model.

Route evidence has limits

A correct route does not prove:

• DNS works;
• the remote host is online;
• a firewall permits the traffic;
• a service is listening;
• TLS succeeds; or
• the application accepts the request.

Each layer has its own evidence.

Extend your Network Path Evidence Record

Add:

Destination:
Matching route:
Why it is most specific:
Next hop/interface:
Changed route:
Observed failure:
Corrective change:
Retest evidence:
One layer still not proven:

Lesson 3 will combine host, route, and packet evidence into a complete bounded path explanation.