9  Lab: Forwarding and Convergence

Keywords

advanced routing lab, forwarding records, convergence lab, routing metric, ETX, RPL boundary, route failure

9.1 Start With the Change Event

Advanced routing behavior is easiest to test when something changes on purpose. A link fails, a metric worsens, a preferred parent disappears, a default route is withdrawn, or a gateway is replaced while traffic is still expected to move.

Use the change event as the center of the lab. Record the baseline path, the trigger, the new route state, the packet evidence, and the time it took to converge. That sequence shows whether the network recovered or merely found a different problem.

9.2 In 60 Seconds

These advanced labs move beyond “does a route exist?” and ask for routing records. You will build a forwarding decision record, observe convergence after a route change, compare path metrics, and document boundary behavior between a constrained IoT mesh and the wider IP network. The goal is not to memorize a simulator or copy a long code listing. The goal is to produce a traceable route record: selected prefix, next hop, TTL or Hop Limit result, route-change timing, link-quality impact, and return-path proof.

9.3 Learning Objectives

By the end of this lab chapter, you will be able to:

• Build a packet-forwarding decision record for route lookup, TTL or Hop Limit handling, and next-hop selection.
• Test failure cases such as no matching route, expired hop counter, stale static route, and missing return path.
• Record convergence behavior without assuming that every routing protocol converges the same way.
• Compare hop count, ETX, latency, and policy as routing metrics.
• Explain where RPL records stop and where border-router or upstream routing records begin.
• Produce a concise lab report that another engineer can reproduce.

Quick Check: IoT Routing Boundaries

9.4 Lab Scope and Rules

Use any safe local environment: a packet simulator, a container network, a small virtual topology, a classroom router lab, or a paper-and-spreadsheet model. Do not connect these labs to production networks. Do not treat a simulator run as proof of RF performance, formal compliance, installed reliability, device lifetime, or provider behavior.

Every lab in this chapter should produce these artifacts:

• A topology sketch or figure.
• A route table snapshot before the test.
• A packet or flow record with source, destination, hop counter, and expected direction.
• A decision log showing selected prefix, next hop, outgoing interface, and drop reason if any.
• A before/after record for route changes or failures.
• A short conclusion that separates proven records from assumptions.

9.5 Prerequisites

• Routing Fundamentals: routing versus forwarding, route sources, and record types.
• Routing Tables and Route Types: longest-prefix match, route sources, and metrics.
• TTL and Loop Prevention: hop counters and expiry behavior.
• Routing Labs: Fundamentals: basic command and observation discipline.

9.6 Lab 1: Forwarding Record Harness

Goal: Prove how a packet is handled by a forwarding decision process.

Set up a small test route set with at least four entries:

• One connected local prefix.
• One static route to a remote prefix.
• One more-specific route that overlaps a broader route.
• One default route.

Create packet records that exercise the route set. Include at least these cases:

• Destination matches the connected prefix.
• Destination matches both a broad prefix and a more-specific prefix.
• Destination uses the default route.
• Hop counter expires before forwarding.
• Return traffic lacks a valid route.

Figure 9.1: Forwarding record harness with packet cases, route table snapshot, decision engine, and event log.

For each packet, record:

• Packet ID and traffic direction.
• Source and destination address.
• TTL or Hop Limit before forwarding.
• Matching prefixes and the selected longest prefix.
• Route source: connected, static, dynamic, or default.
• Next hop and outgoing interface.
• Action: forward, deliver locally, drop expired, drop no route, or drop policy.
• Records you used to prove the action.

Acceptance standard: A teammate should be able to read your log and explain why each packet was forwarded or dropped without rerunning the lab.

9.7 Lab 2: Convergence and Failure Recovery

Goal: Observe how route state changes after a topology change.

Build a small topology with at least two possible paths between an edge node and a gateway. The topology can be simulated or physical, but the records must show route state before and after a change.

Run this sequence:

1. Record the initial route table and preferred next hop.
2. Send or model a packet along the preferred path.
3. Remove or degrade one link.
4. Record when the route table first changes.
5. Record when forwarding stabilizes on the new path.
6. Restore the link and record whether the original path returns.

Figure 9.2: Convergence lab timeline showing baseline route state, link change, route update, forwarding test, and stable final record.

Do not report only “it worked.” Report the route-change records:

• Which route changed?
• Which next hop was replaced?
• Was there a temporary drop, loop, or asymmetric path?
• Did the return path change at the same time?
• Which observation proves the new path was actually used?

If your environment cannot measure real time accurately, report convergence in update rounds or observation steps. That is acceptable as long as you define the unit clearly.

9.8 Lab 3: Metric Choice and RPL Boundary Checks

Goal: Compare routing choices when hop count is not the only useful metric.

Create two candidate paths from a sensor-side node to a gateway or border router:

• Path A has more hops but better observed link quality.
• Path B has fewer hops but worse observed link quality.

For each path, record:

• Hop count.
• Observed delivery ratio or retransmission records.
• Estimated ETX or similar link-quality score if your environment supports it.
• Whether the route crosses a border router or remains inside the constrained mesh.
• Whether command or reply traffic follows the same path back.

Figure 9.3: Metric comparison lab with two candidate paths: a longer stable path and a shorter lossy path evaluated by hop count, ETX, and boundary records.

The point is not that one metric always wins. Hop count may be appropriate in a stable wired lab. ETX may be more informative in a lossy wireless mesh. Latency may matter for control traffic. Policy may override all of them at a boundary. Your conclusion must name the objective function you used and the records that support it.

For RPL-oriented checks, separate three questions:

• Inside the mesh, which parent or path is preferred and why?
• At the border router, which route carries traffic into the wider IP network?
• On the return path, how does traffic reach the device or mesh prefix?

9.9 Routing Record Template

Use this structure for your lab report:

1. Topology: nodes, links, routing domains, and boundary devices.
2. Objective: the routing behavior being tested.
3. Inputs: route entries, packet records, link changes, and metric observations.
4. Expected result: selected route, next hop, hop-counter result, and return path.
5. Observed result: route-table records, packet records, and failure records.
6. Decision: pass, fail, or inconclusive.
7. Limitations: simulator limits, missing measurements, or assumptions that need field validation.

9.10 Verification Checklist

Before marking the advanced lab complete, confirm that you have:

• Tested at least one success path and one drop path.
• Shown the selected longest-prefix match for a packet.
• Shown TTL or Hop Limit before and after a forwarded hop.
• Captured route state before and after a topology or metric change.
• Checked the return path separately from the uplink.
• Recorded link-quality measurements if you discuss ETX or lossy links.
• Kept simulator results separate from production assertions.
• Removed stale diagrams, generic label/code quizzes, and unsupported device or lifetime assertions from the final report.

9.11 Common Mistakes

• Treating a simulator as proof of installed RF reliability.
• Reporting only application success without route or packet records.
• Comparing path metrics before checking longest-prefix match.
• Forgetting that a command or acknowledgment uses its own return path.
• Assuming a lower hop count is always better in lossy wireless conditions.
• Mixing RPL mesh records with upstream site routing records.
• Leaving stale code listings that are too long to check on mobile.

9.12 Knowledge Check

9.13 Matching Quiz

9.14 Ordering Quiz

Overview: Convergence Needs A Change Record

The advanced lab is not only asking whether routing recovers. It asks whether the learner can show what changed, when forwarding became stable again, which packets were affected during the change, and which return path or RPL boundary remained outside the local proof.

A convergence record is a sequence, not a final screenshot: baseline, trigger, transient behavior, stable route, packet proof, and the limitation that keeps the lab claim scoped.

Start with the baseline because it is the comparison point. A baseline row should name the active route, selected next hop or parent, route source, metric or objective function, and at least one packet that proves the path was actually used. Then name the trigger: a failed link, changed metric, withdrawn route, moved node, policy change, or gateway replacement. Without those two rows, the rest of the lab becomes guesswork because the reviewer cannot tell whether the new route is a repair, a normal alternate path, or a different test case.

The middle of the record is where many reports get weak. Record the transient state even when it is messy: dropped packets, loop symptoms, delayed DAO or route-table updates, temporary parents, or an unknown interval. The final stable state matters, but it should be accepted only after packet proof and return-path proof are attached. The limitation row is also part of the result. It says what this classroom, simulator, or bench lab did not prove, such as installed RF reliability, upstream firewall policy, or application retry behavior.

Before state

Record the selected prefix, next hop, route source, metric, and known return path before changing the topology.

Change window

Capture the route update, temporary drops, parent or next-hop replacement, and the first stable forwarding test.

Remaining limit

State which claims the lab still does not prove, such as installed RF reliability, upstream policy, or application behavior.

Practitioner: Prove The Change Window

A practitioner report should make the unstable interval visible. The useful record is not a long packet dump; it is a compact sequence that ties a link or metric change to route-table updates, packet outcomes, and the decision to accept or reject the recovered path.

Use observation numbers if the lab cannot measure wall-clock time accurately. For example, "step 3" or "update round 2" is better than pretending the lab measured milliseconds. Each row should be small enough to audit: one route-table change, one forwarding test, one return-path check, or one boundary note. If several things change at once, split them so the reviewer can see which evidence supports which conclusion.

Change-Window Record

1. Snapshot the baseline route table and preferred next hop.
2. Record the injected link, metric, or route withdrawal change.
3. Mark the first observation where route state changes.
4. Record packets that drop, loop, or take a temporary path.
5. Mark the first observation where forward and return paths are stable.
6. Name the retest trigger, such as topology change, firmware change, new objective function, or gateway replacement.

Worked Record: Stable Final Path, Risky Window

A mesh node moves from parent A to parent B after A is degraded. The final route works, but two telemetry packets are dropped during parent replacement and the return path stabilizes one observation step later. The release note should accept the new path only with that outage window and retest trigger attached.

Keep the acceptance decision separate from the observation. "Forward path recovered" is an observation. "Accept for this lab" is a decision that also needs the return path, owner, and retest trigger. In an RPL-oriented lab, the owner might be the mesh firmware team for parent selection, the border-router owner for prefix advertisement, and the site-network owner for upstream routing. Naming those boundaries prevents a local mesh result from being overstated as an end-to-end service guarantee.

Under The Hood: Metrics Move The Risk

Hop count, ETX, latency, and policy answer different questions. A shorter route can lose more packets. A stable mesh path can still fail at the border router. A metric that works for telemetry can be wrong for commands. The advanced lab should show which risk the metric reduces and which risk it leaves for another record.

Do not compare metrics until the route candidates are comparable. First prove the packet destination, matching prefix, route source, and boundary. Longest-prefix match still comes before ordinary metric comparison. After that, the metric record should state the objective: minimize hop count, reduce expected transmissions, avoid a policy boundary, keep traffic inside a mesh, or prefer a route with better observed delivery. The same topology can produce different choices when the objective changes.

Hop count

Reduces path length, but can prefer a short lossy link unless link quality is recorded separately.

ETX or link quality

Targets delivery reliability, but needs enough observations and does not prove upstream or return-path behavior.

Policy boundary

Can override local metrics at a gateway, border router, firewall, or application ownership boundary.

Metric Risk Record

• Candidate set: list only routes that actually match the destination and are eligible under policy.
• Metric evidence: show the measured or configured evidence, such as hop count, observed loss, retransmissions, or selected objective function.
• Chosen risk: state what the chosen path optimizes and what it may worsen.
• Boundary check: prove whether the forward path, return path, and border-router behavior are inside or outside the lab scope.

This is why ETX-style reasoning needs careful wording. A lower expected-transmission path can be a better mesh parent and still be insufficient evidence for cloud reachability. A policy route can be correct for security and still add latency. A return path can fail even when the uplink packet succeeds. Under the hood, the lab is teaching evidence ownership: metrics explain a route choice, packet records prove forwarding behavior, and boundary notes prevent one proof from being stretched across the whole system.

9.15 Summary

Advanced routing labs should produce records, not just output. The important records are selected prefixes, next hops, hop-counter behavior, convergence changes, metric assumptions, border-router responsibilities, and return-path results. A useful lab report is reproducible, scoped, and honest about what the environment proves and what it does not prove.

9.16 Key Takeaway

Routing labs are useful when they leave records of topology, assumptions, route decisions, failures, and the reasoning behind each selected path.

9.17 Concept Relationships

• Routing Fundamentals explains the control-plane and data-plane vocabulary used in these labs.
• Routing Tables and Route Types provides the route-selection mechanics.
• TTL and Loop Prevention explains hop-counter records.
• Routing Labs: Algorithms continues with route-computation exercises.
• RPL Fundamentals connects constrained-network records to DODAG behavior.

9.18 What’s Next

Continue to Routing Labs: Algorithms when you are ready to compare route-computation methods. Then use Routing Labs and Quiz to check the lab sequence before moving deeper into RPL-specific implementation and check chapters.