2 How Packets Find a Next Hop

routing

networking

iot

2.1 Start With One Packet at a Fork

Follow One Packet Through a Route Change

Picture a field sensor whose usual parent disappears. The next packet must choose another hop without looping or silently vanishing.

A gateway means the boundary system that connects local devices to another network or service. A protocol means shared rules for exchanging messages. Routing Protocol for Low-Power and Lossy Networks, or RPL, organizes routes for constrained device networks.

Send one marked packet, remove its preferred next hop, and send it again. Keep node identities, destination, table state, chosen hop, loop limit, time, delivery, and loss.

This runway does not prove that the whole network is healthy. The deeper sections explain forwarding, tables, metrics, route discovery, loops, convergence, RPL structure, and delivery evidence.

Imagine a sensor packet arriving at a node with more than one possible way forward. The node does not understand the whole application story; it has a destination, a table, a next hop, and a loop limit that keeps a bad path from lasting forever.

Routing basics are the rules behind that small fork in the road. Once you can explain why the node picks one next hop, why the table entry exists, and what evidence proves the packet moved, the larger RPL and IoT routing choices become easier to audit.

2.2 Overview: Routing Chooses the Next Hop

Routing is the network-layer decision that tells a packet where to go next. A router receives an IP packet, reads the destination address, searches a routing table, and sends the packet toward one selected next hop or directly connected destination.

The key idea is hop-by-hop decision making. A sensor does not need to know the entire path to a cloud service. It may know only a gateway. The gateway may know only the next router toward an uplink. Each hop repeats the lookup until the packet reaches the destination network or a router drops it because no usable route exists.

For example, a battery sensor may send every cloud-bound packet to the gateway because the gateway is its only default route. The gateway then chooses an ISP router as its next hop, while the ISP router chooses a cloud-side path from its own table. The packet keeps the same IP destination, but each router makes a local forwarding decision.

The evidence boundary for Overview: Routing Chooses the Next Hop is visible in Figure 2.1. Study how routing is local at each hop: every router keeps the destination IP and chooses only the next step from its own table before carrying the claim into the next design or validation step. This diagram tests Overview: Routing Chooses the Next Hop.

Hop-by-hop routing path from sensor through gateway router and ISP router to cloud service, showing that each router uses its own table to choose the next hop. — Figure 2.1: Routing is local at each hop: every router keeps the destination IP and chooses only the next step from its own table.

Follow the evidence in Figure 2.1 from “Hop-by-hop routing path from sensor through gateway router and ISP router to cloud service” to “showing that each router uses its own table to choose the next hop..” When “the named input” is included, the diagram shows how routing is local at each hop: every router keeps the destination IP and chooses only the next step from its own table; this is the specific relationship that Overview: Routing Chooses the Next Hop carries onward.

If you only need the intuition, this layer is enough: routing builds or maintains the path information, while forwarding uses that information for each packet. The router normally chooses the most specific matching route, protects against loops with TTL or Hop Limit, and falls back to a default route only when no better match exists.

Routing

Control-plane work that learns networks, chooses paths, reacts to change, and installs table entries.

Forwarding

Data-plane work that handles an individual packet by looking up the destination and transmitting toward the next hop.

Next Hop

The neighboring router or local destination selected for the packet's next step.

Default Route

The least-specific fallback entry, used when no more specific destination prefix matches.

Routing matters in IoT because many deployments combine gateway paths, local prefixes, mesh relays, constrained radios, sleeping nodes, and upstream services. A path can work for one packet and still be fragile if the next hop, return path, loop limit, and failure behavior are not reviewable.

2.3 Practitioner: Build the Routing Evidence Record

A routing evidence record should name the traffic scope, route source, selected next hop, packet proof, and changed condition that would reopen the decision. Keep it small enough to maintain and specific enough to diagnose a changed link, parent, route, or gateway rule.

Record field

Question

Evidence to keep

Failure it prevents

Traffic scope

Which source and destination matter?

Endpoint, prefix, application path, local-vs-uplink boundary, and expected return path.

Testing a happy path that is not the path the system actually depends on.

Route entry

Which table row wins?

Destination prefix, next hop, outgoing interface, metric or preference, and default-route fallback.

Assuming the visible route order is the selection rule.

Loop guard

What limits circulation?

TTL or Hop Limit behavior, unreachable response where relevant, and observed failure when the limit is exhausted.

Hidden loops that look like intermittent packet loss.

Failure behavior

What happens when the next hop changes?

Neighbor loss, gateway failover, mesh parent change, stale-route handling, and retest trigger.

Trusting a route that only works while one preferred neighbor is healthy.

Constrained fit

Can the protocol fit the devices?

Memory, sleep behavior, link quality, control-message budget, and convergence expectations.

Choosing a routing approach designed for better-powered and more stable networks.

Operations evidence

Can the team debug the path?

Route snapshot, neighbor or parent state, packet trace, diagnostic response, and change owner.

Being unable to distinguish route failure from application failure.

Use longest-prefix match as the first lookup rule. A route for `10.42.18.0/24` is more specific than `10.42.0.0/16`, so it wins for a destination such as `10.42.18.33`. A default route such as `0.0.0.0/0` or `::/0` is useful for unknown destinations, but it is intentionally the least specific match.

Accept

The chosen route, next hop, return path, loop guard, and failure behavior match the traffic scope.

Constrain

Keep local prefixes local, route only cloud-bound traffic upstream, or limit a route to a named interface or gateway.

Retest

Reopen review when a prefix, default gateway, route metric, parent choice, border router, or sleep pattern changes.

Hold

Do not trust the design when next-hop choice, return path, loop behavior, or constrained-device fit is undocumented.

For a simple gateway, the record may be a short route table plus a packet trace to the local service and upstream service. For a mesh, the record also needs parent or neighbor state, because a packet may depend on intermediate constrained devices that sleep, move, or lose link quality.

2.4 Under the Hood: Forwarding, Loop Limits, and Why RPL Appears

At each hop, a router receives a link-layer frame, extracts the IP packet, decrements IPv4 TTL or IPv6 Hop Limit, applies a routing-table lookup, resolves the next-hop link-layer address when needed, and transmits a new frame on the outgoing interface. The IP destination normally stays the same across the path even though the link-layer envelope changes at every hop.

The under-the-hood rule is practical: forwarding is local, loop prevention is mandatory, and route freshness matters. If the packet cannot be matched to a usable route, or if the loop limit reaches zero, the packet is dropped rather than forwarded blindly.

At this point, Under the Hood: Forwarding, Loop Limits, and Why RPL Appears needs a concrete reference model. Look at Figure 2.2, where a forwarding check should expose the loop guard, prefix match, next-hop resolution, default-route fallback, and no-route drop behavior; the pictured labels keep the later conclusion anchored to observable behavior.

Router forwarding decision process checking TTL or Hop Limit, longest-prefix match, next-hop resolution, default route fallback, and drop when no route is available. — Figure 2.2: A forwarding check should expose the loop guard, prefix match, next-hop resolution, default-route fallback, and no-route drop behavior.

Within Figure 2.2, “Router forwarding decision process checking TTL or Hop Limit” identifies one side of the record and “longest-prefix match” identifies the other. “next-hop resolution” exposes their operational link, illustrating how a forwarding check should expose the loop guard, prefix match, next-hop resolution, default-route fallback, and no-route drop behavior and grounding Under the Hood: Forwarding, Loop Limits, and Why RPL Appears.

Lookup

The router uses destination prefix, preference, and metric rules to identify the outgoing interface and next hop.

Loop Limit

TTL or Hop Limit is reduced at each router so packets cannot circulate indefinitely.

Neighbor Resolution

Local delivery may need ARP for IPv4 Ethernet or Neighbor Discovery for IPv6 links before the next frame can be sent.

No Route

If no matching route and no default route exist, the router drops the packet and may report the destination as unreachable.

Constrained IoT meshes add another layer of difficulty. Devices may run on batteries, sleep to save energy, have small routing tables, and communicate over lossy wireless links. A stable enterprise routing design may assume more memory, bandwidth, and neighbor stability than those devices can offer.

RPL, the IPv6 Routing Protocol for Low-Power and Lossy Networks, addresses that environment by organizing nodes around a destination-oriented directed acyclic graph rooted near a border router. Nodes choose parents according to an objective function and maintain enough state to forward traffic without requiring every constrained node to know a full network map.

The takeaway is not that every IoT network needs RPL. Star topologies, Ethernet gateways, and industrial networks may use other routing arrangements. The point is that low-power mesh routing needs evidence about parent choice, link quality, control-message budget, repair behavior, and return paths, not just a generic statement that routing exists.

2.5 IGP And BGP: The Gateway Boundary

Routing inside one administrative domain and routing between domains solve different problems. An interior gateway protocol (IGP) such as OSPF distributes reachability and path-cost information within an autonomous system. BGP exchanges reachability between autonomous systems and applies policy through attributes such as AS path and local preference. Neither acronym is a synonym for “the Internet,” and neither belongs on every constrained endpoint.

Boundary	IGP inside an autonomous system	BGP between autonomous systems
Primary evidence	Topology, link cost, area or level, convergence	Prefix advertisements, path attributes, import/export policy
Typical decision	Which internal next hop reaches a destination at acceptable cost?	Which external route is acceptable under organizational policy?
Failure review	Adjacency loss, metric change, reconvergence, loop containment	Withdrawals, policy error, route leak, path selection, filtering
IoT endpoint role	Usually none; the endpoint uses a parent or default route	None; BGP belongs at a controlled network edge, not a sensor

Trace the handoff for a low-power deployment: a sensor forwards upward through its RPL DODAG; the RPL border router terminates that constrained topology and sends non-mesh traffic to a default or redistributed route; the campus or site IGP carries the packet to the enterprise edge; and an edge router may use BGP with a provider before the packet reaches a cloud service. The return path must cross the same boundaries in reverse with a route to the IoT prefix or an explicitly documented translation and proxy design.

Do not redistribute RPL, IGP, and BGP routes indiscriminately. Record which prefixes may cross each boundary, who owns filtering and aggregation, how a withdrawal propagates, and how the return path is tested. A working outbound ping does not prove that inbound replies, failover, or policy changes are safe.

2.6 Summary

Routing chooses where packets go next; forwarding applies that choice to each packet. A router reads the destination address, applies longest-prefix match, handles TTL or Hop Limit, and transmits toward a next hop, directly connected destination, or default route. If there is no usable route, the safe outcome is a drop rather than a guess.

In IoT systems, routing evidence has to include the traffic scope, next hop, route source, return path, loop guard, and failure behavior. Low-power meshes add constraints such as sleeping nodes, lossy links, limited memory, parent changes, and repair behavior, which is why RPL becomes a core concept later in this module.

2.7 Key Takeaway

Trust a routing design only when the next-hop decision, fallback route, loop limit, constrained-device fit, and retest trigger are visible for the traffic that matters.