Routing & RPL · Study deck
How Packets Find a Next Hop
Picture a field sensor whose usual parent disappears.
Packet Pete is your guide for this deck.
After studying this chapter
Learning objectives
A route is useful only when its next hop and failure behavior can be explained.
- Each router uses its own destination lookup to choose the next step.The sensor can know only its gateway while later routers independently choose their own next hops toward the cloud service.
- Routing maintains path information, while forwarding applies it to individual packets.A changed parent matters because the next arriving packet depends on the forwarding state installed after that change.
- A specific matching prefix takes priority over a default route.For 10.42.18.33, the chapter’s 10.42.18.0/24 route wins over 10.42.0.0/16 and the default fallback.
- Mesh evidence needs parent changes, return paths, and loop limits.Sleeping neighbors and lossy links can change which next hop remains usable after an earlier successful sensor message.
Major section
Start With One Packet at a Fork
A disappearing parent tests whether the next packet still has a usable path.
- A marked packet connects its journey with a route snapshot.Node identities, destination, table state, and chosen hop let the reviewer link a forwarding decision to the observed transmission.
- A missing preferred hop creates a concrete recovery test.The next packet must find a usable alternative without looping or disappearing silently after the sensor’s usual parent is removed.
- Timing, delivery, and loss belong beside the selected neighbor.The before-and-after record needs both the intended next hop and evidence of what happened to the marked packet.
- A successful delivery leaves failure behavior unexplained.One normal application message can miss stale routes, parent changes, loop behavior, or repair delay in the constrained mesh.
Major section
The gateway and a changed parent
Packet evidence connects a local choice with an observable result.
- A gateway connects local devices with another network or service.The sensor’s gateway can provide the next step toward an upstream service without giving the sensor a complete global path.
- Each forwarding node needs a destination, usable state, and a loop limit.Those local ingredients govern the packet at a fork even when the node does not understand the application’s full purpose.
- A changed parent can expose stale forwarding state.The old route may remain visible while its selected neighbor is unavailable, so a normal delivery test misses the changed condition.
- The hop choices show how forwarding responded to the disruption.Packet timing, delivery, and loss must accompany the route snapshots to distinguish intended recovery from observed forwarding.
Major section
Local decisions along the cloud path
Follow the sensor-to-cloud arrows to see each router make a separate next-hop choice.
- The sensor sends cloud-bound traffic toward its gateway.At the path’s first arrow, a default route can be enough for the sensor to choose its only upstream neighbor.
- The gateway selects its own next hop from its table.The next arrow shows a new lookup toward the ISP router rather than a complete path supplied by the sensor.
- The ISP router uses another lookup toward the cloud service.Its forwarding choice uses its own table, so the diagram’s successive arrows represent separate local decisions along the journey.
- The destination IP stays constant across these local forwarding choices.The same cloud-bound packet advances through different neighbors without requiring every router to know the complete end-to-end route.
Major section
Specific routes and the default fallback
Destination specificity determines whether a router uses a local route or its fallback.
- The destination is compared with the prefixes in the table.The chapter’s 10.42.18.33 destination matches both 10.42.18.0/24 and the broader 10.42.0.0/16 route.
- A longer matching prefix takes priority over a broader matching prefix.The /24 entry is more specific than the /16 entry, so visible row order is not the route-selection rule.
- The default route is the least-specific fallback.Entries such as 0.0.0.0/0 or ::/0 are useful only when no more specific destination prefix matches.
- A packet without a usable route is dropped.If neither a matching route nor a default route exists, the router cannot choose a valid next hop by guessing.
Major section
Routing state and packet forwarding
Control-plane changes matter because the data plane depends on installed state.
- Routing learns reachability and installs entries as conditions change.The control plane chooses paths and reacts to changes before forwarding uses the resulting table for an arriving packet.
- Forwarding uses the installed entries for each packet.The data plane reads the destination and transmits toward the selected next hop rather than rebuilding the whole route for every message.
- The chosen neighbor must remain usable for the packet to advance.A sleeping mesh parent or degraded wireless link can undermine a table entry that previously supported successful delivery.
- Outbound delivery leaves return-path and failure behavior to be tested.The gateway’s working default route does not establish that the remote side can reach the sensor’s IoT prefix.
Major section
The winning route and its packet evidence
A useful record explains which route wins and how its result was checked.
- The evidence record needs a source, destination prefix, and application path.The local-versus-uplink boundary and expected return path prevent a successful test from covering the wrong traffic scope.
- The route entry needs its next hop, interface, and preference.Those fields explain the intended forwarding choice rather than assuming that the table’s displayed row order determines the winner.
- For 10.42.18.33, the matching 10.42.18.0/24 route beats 10.42.0.0/16.Removing the /24 leaves the /16 as the next winner, still ahead of the less-specific default route.
- Route snapshots need packet traces and parent state alongside them.The mesh can depend on intermediate devices that sleep or lose link quality, so a table alone cannot establish observed delivery.
Activity 1 · Work it out
✎ Choose the winning route
I want you to explain the winning prefix before trusting the gateway.
On paper, compare 10.42.18.0/24, 10.42.0.0/16, and 0.0.0.0/0 for destination 10.42.18.33. Mark the winner. Remove that route and mark the next winner. Explain both choices.
3 minutes · Pen and paper · Answer: Activity 1
Major section
Accepting, constraining, and reopening a route
Accept, constrain, retest, and hold turn the routing record into a decision.
- Acceptance needs the route and failure behavior to match the traffic.The selected next hop, return path, and loop guard must have evidence for the application path the deployment actually needs.
- Forwarding can be constrained to named prefixes, interfaces, or gateways.Keeping local prefixes local and sending only cloud-bound traffic upstream makes the intended boundary explicit.
- A prefix, metric, parent, or sleep-pattern change requires another review.The earlier packet trace belongs to its tested conditions and cannot automatically establish the changed route’s behavior.
- Undocumented next-hop or device behavior leaves approval unsupported.Missing return-path, loop-limit, memory, or control-message evidence means the design’s fit for constrained devices remains unresolved.
Major section
From loop guard to delivery or drop
Trace the forwarding checks from the loop guard through route lookup to delivery or drop.
- The first guard uses TTL or Hop Limit to bound packet circulation.A packet whose limit is exhausted is dropped before it can keep circulating through the same forwarding loop.
- The destination lookup selects the most specific usable route.The diagram includes the default-route fallback, which matters only when no more specific matching entry can supply the next step.
- Neighbor resolution supplies the next local delivery address when needed.ARP for IPv4 Ethernet or Neighbor Discovery for IPv6 links can precede transmission of the outgoing link-layer frame.
- The no-route branch ends with a drop.A missing usable match and missing fallback leave no justified next hop, so the packet is not forwarded blindly.
Major section
Loop limits and local delivery addresses
Loop limits and neighbor resolution protect different parts of the forwarding step.
- Each router reduces IPv4 TTL or IPv6 Hop Limit.The decreasing value limits how far a packet can circulate if forwarding state accidentally sends it around a loop.
- An exhausted loop limit stops further packet forwarding.Dropping at zero bounds the failure instead of allowing a bad path to consume forwarding effort indefinitely.
- ARP or Neighbor Discovery can resolve the next local delivery address.This step supplies link-layer addressing when required; it does not choose a complete end-to-end path for the application.
- The outgoing frame is new while the IP destination normally stays unchanged.Each hop must create a new local envelope for the selected neighbor while preserving the packet’s intended destination network.
Major section
Parent choice in a constrained mesh
RPL fits constrained meshes by organizing forwarding around selected parents.
- Battery operation and lossy links can change the usable parent.Sleeping neighbors, limited memory, and changing link quality make stable enterprise-network assumptions unsuitable for some constrained devices.
- RPL uses a destination-oriented directed acyclic graph near a border router.This structure can organize constrained nodes around selected parents rather than requiring each sensor to maintain a full network map.
- An objective function can guide the parent choice.Nodes maintain enough state to forward traffic, but the selected parent still needs evidence under the deployment’s actual link conditions.
- The review needs link quality, repair cost, and return-path evidence.Control-message budget and repair behavior determine whether a parent change fits the constrained devices after the preferred route fails.
Activity 2 · Draw it
✎ Trace a changed parent
I want you to sketch what changes when the preferred parent disappears.
Draw a sensor, its preferred parent, an alternative parent, and the gateway. Cross out the preferred parent. Mark the new next hop and list the route, packet, and return-path evidence needed to review recovery.
4 minutes · Pen and paper · Answer: Activity 2
Major section
The mesh, site, and provider boundaries
The constrained mesh hands traffic to site routing before an external edge applies provider policy.
- The RPL border router connects the mesh to an explicit site route.It terminates the constrained topology and sends non-mesh traffic toward a default or redistributed route under the reviewed boundary rules.
- An IGP carries reachability and path-cost information within an administrative domain.The site network can use this information to move the packet toward its enterprise edge without placing that responsibility on each sensor.
- BGP applies route policy between autonomous systems at a controlled edge.Provider-facing policy belongs at the managed network boundary and needs prefix advertisements, filtering, and path-selection evidence.
- The return path needs a route to the IoT prefix.An explicit translation and proxy design can define another arrangement, but a working outbound ping alone cannot establish inbound reachability.
Major section
Summary
Reliable routing joins the local forwarding rule to evidence from changed conditions.
- Destination lookup identifies the next step rather than a complete global path.The sensor, gateway, and ISP router can each use local forwarding state to move the cloud-bound packet toward its destination.
- Longest-prefix match keeps specific routes ahead of the default fallback.The chapter’s /24 wins over its matching /16 for 10.42.18.33, while the default remains the least-specific option.
- Loop limits and no-route drops can bound failed forwarding.A packet is dropped when its limit expires or no usable route exists, rather than circulating or advancing by guesswork.
- Mesh evidence must explain parent selection, repairs, and the return path.Sleeping nodes and changing links can invalidate a previously usable next hop, so a single successful message cannot establish recovery.
Deck summary
Key takeaways
Trust the path only when its forwarding choices and review triggers are visible.
- Route tables show intended choices, while packet traces show observed results.Keeping snapshots, parent state, timing, delivery, and loss together makes a failed sensor path diagnosable after a route change.
- A working default route does not establish the return path.The remote network still needs reachability to the IoT prefix or the explicitly documented translation and proxy arrangement.
- Changed neighbors and sleeping devices can invalidate an earlier decision.The next packet can encounter an unavailable preferred parent even after a previous message reached the gateway successfully.
- Traffic or routing changes require the evidence record to be reopened.Prefixes, gateway rules, metrics, parents, border routers, and sleep patterns define concrete reasons to retest the previously observed path.
Retrieval practice
Recall check 1 of 4
Packet Pete says: answer from memory, then check your reasoning.
Q1A gateway has a working uplink and receives a packet for a cloud service. Which statement best describes the routing decision?
Show answer
Answer: A Routing separates path information from per-packet forwarding.
Retrieval practice
Recall check 2 of 4
Packet Pete says: answer from memory, then check your reasoning.
Q2A gateway has routes for 10.0.0.0/8, 10.42.0.0/16, 10.42.18.0/24, and 0.0.0.0/0. Which route should it use for a packet destined to 10.42.18.33?
Show answer
Answer: A The routing evidence record should make the selected route visible.
Retrieval practice
Recall check 3 of 4
Packet Pete says: answer from memory, then check your reasoning.
Q3Why do constrained IoT meshes often need routing evidence beyond a normal gateway route table?
Show answer
Answer: A Under the hood, IoT routing evidence must connect forwarding mechanics with constrained-network behavior: parent choice, route freshness, loop limits, and failure recovery.
Retrieval practice
Recall check 4 of 4
Packet Pete says: answer from memory, then check your reasoning.
Q4Where should a low-power sensor's RPL forwarding normally hand off toward an external cloud service?
Show answer
Answer: A The border router is the evidence boundary between the RPL domain and site routing.
Print reference
Answers
Answer key.
- A · Routing separates path information from per-packet forwarding.
- A · The routing evidence record should make the selected route visible.
- A · Under the hood, IoT routing evidence must connect forwarding mechanics with constrained-network behavior: parent choice, route freshness, loop limits, and failure recovery.
- A · The border router is the evidence boundary between the RPL domain and site routing.
Print reference
Activity 1 answer
Model answer.
Work it out: 10.42.18.0/24 wins because it is the longest matching prefix. After its removal, 10.42.0.0/16 wins. The default 0.0.0.0/0 remains less specific than either route.
Print reference
Activity 2 answer
Model answer.
Draw it: The sketch sends the sensor toward an available alternative parent and onward to the gateway. Keep parent and route state before and after the change, packet delivery or loss and timing, loop-limit behavior, and a checked return path.