Networking / Basic: packet paths and addressing / Lesson 4

Select routes and follow next hops

Use longest-prefix matching, local-delivery decisions, return paths, and hop limits to explain packet forwarding.

About 4 min readContent reviewed 2026-10-25

On this page

Lesson goals

Apply longest-prefix matching to a declared route table.
Distinguish destination routes from next-hop reachability.
Explain asymmetric paths and loop-limiting fields.

A route is a scoped forwarding decision

A route associates a destination prefix with an action such as local delivery, an outgoing interface, or a next hop. Forwarding normally chooses the most specific matching prefix before applying other implementation and policy details. A default route is the least-specific catch-all, not a guarantee that every destination can be reached. Policy routing and separate routing domains can add selection inputs beyond the destination. For a clear first model, use one declared table and state that simplification. Do not call a route correct without checking the application’s actual routing context and return requirements.

Specificity beats the default

When several prefixes contain a destination, the one with more matching fixed bits is more specific. An offline implementation can enumerate containing networks and choose the largest prefix length. This illustrates one lookup rule, not a full routing daemon with metrics, equal-cost paths, or policy. Keep next-hop labels distinct from destination addresses. A route toward a network does not mean the next hop is itself inside that remote prefix. The next hop must be reachable through the applicable local link or recursive resolution rules of the platform.

python Choose the longest matching documentation prefix

from ipaddress import ip_network, ip_address
routes = [('0.0.0.0/0', 'default'), ('198.51.100.0/24', 'site'), ('198.51.100.128/25', 'specific')]
destination = ip_address('198.51.100.200')
matching = [(ip_network(prefix), label) for prefix, label in routes if destination in ip_network(prefix)]
network, label = max(matching, key=lambda item: item[0].prefixlen)
print(network, label)

Expected output

198.51.100.128/25 specific

The /25 wins over the containing /24 and default. This arithmetic touches no operating-system routing table and sends no traffic.

Forward and return paths are independent decisions

Each endpoint and router selects forwarding using its own state. A request reaching the server does not prove that a reply returns through a permitted path. Asymmetry can be intentional, but stateful policies, NAT state, and source validation may constrain it. Identify the source address selected for the request, because the return destination follows that choice. A multihomed host or proxy can therefore create symptoms that disappear from another client. Draw both directions and preserve the observation point before concluding that one missing reply proves a particular router or firewall is broken.

Hop limits bound forwarding loops

IPv4 TTL and IPv6 Hop Limit are reduced during forwarding according to their protocol rules. Exhaustion prevents indefinite circulation and can lead to an ICMP diagnostic, subject to policy and implementation. A missing diagnostic does not prove that no router processed the packet. A loop may arise from inconsistent forwarding state even when every individual route looks plausible in isolation. Review topology and selected next hops together. Do not equate a hop count with physical cable distance or assume all paths remain unchanged between observations; load sharing and routing convergence can alter the path.

python Model a hop-limit expiry offline

path = ['router-a', 'router-b', 'router-c']
hop_limit = 2
for router in path:
    hop_limit -= 1
    if hop_limit == 0:
        print('synthetic_expiry=' + router)
        break

Expected output

synthetic_expiry=router-b

The fixture demonstrates decrementing and stopping after two modeled forwards. It is not traceroute, ICMP generation, or evidence about a real topology.

Keep route intent and evidence reviewable

Document connected prefixes, defaults, specific routes, routing-domain boundaries, and the intended return path. Use offline containment checks to expose accidental overlap and unintended specificity. A new more-specific route can redirect a small subset of traffic without changing the default, so review affected destinations rather than only the route count. Route installation and packet forwarding are separate milestones; neighbor resolution, interface state, and policy still matter. This lesson never installs or removes a route. Its output is a model that can be compared with authorized operational evidence later.

Common errors and fixes

Default route is treated as universal reachability

Why it happens: A lookup fallback was confused with a complete path.
How to fix it: Check next-hop and return-path requirements separately.
Prevent it next time: Use end-to-end milestones in route reviews.

A /24 is selected despite a matching /25

Why it happens: Specificity was ignored.
How to fix it: Compare matching prefix lengths before the default.
Prevent it next time: Test destinations on each route boundary.

A missing reply proves a forward-route failure

Why it happens: The return direction and policy were omitted.
How to fix it: Draw source selection and both forwarding directions.
Prevent it next time: Retain observation-point metadata.

Check your understanding

1. Which route wins for 198.51.100.140: default, /24, or 198.51.100.128/25?

Show worked solution

The /25 wins in the declared destination-based table because it is the most specific containing prefix. This answers lookup only; it does not establish that its next hop, policy, or return path works.

2. A request arrives but replies use another gateway. Is asymmetry always an error?