11  Routing Labs and Quiz

In 60 Seconds

A lab series covering routing table examination, static route configuration, route selection analysis with longest-prefix matching, traceroute troubleshooting, and multi-subnet IoT deployment planning. Includes hands-on exercises for Windows, Linux, macOS, and ESP32 platforms.

11.1 Learning Objectives

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

• Examine routing tables using system commands to view and interpret entries on Windows, Linux, and macOS
• Configure static routes to add, modify, and delete routes for network segmentation
• Analyze route selection by tracing how routing decisions are made based on metrics and longest-prefix matching
• Diagnose connectivity failures using traceroute and ping to isolate routing issues in IoT networks
• Implement default gateways to configure gateway addresses for proper internet connectivity
• Design subnet routing to plan routing tables for multi-subnet IoT deployments

Related Chapters

Deep Dives:

• Routing Fundamentals - Core routing theory and concepts
• Routing Comprehensive Review - Advanced routing strategies
• RPL Operation - DODAG formation and routing metrics

IoT Routing:

• RPL Fundamentals - Low-power routing protocol
• RPL Labs - Hands-on RPL implementation
• WSN Routing - Sensor network patterns

Topologies:

• Network Topologies - How topology impacts routing
• Topologies Labs - Topology design and documentation

Related Protocols:

• 6LoWPAN - IPv6 routing over constrained networks
• Thread Routing - Thread mesh routing

Learning:

• Simulations Hub - Routing simulators and tools
• Videos Hub - Routing video tutorials

Sensor Squad: Hands-On Routing Practice!

“These labs are where routing theory meets practice,” said Max the Microcontroller. “You will examine real routing tables, configure static routes, use traceroute to map network paths, and even program an ESP32 to forward packets.”

“The series builds progressively,” explained Sammy the Sensor. “Start with fundamentals – looking at routing tables on your own computer. Then move to algorithm implementation in Python. Finally, tackle advanced labs with ESP32 packet forwarding and convergence simulation.”

“I love the troubleshooting exercises,” added Lila the LED. “You get broken network scenarios and have to use ping and traceroute to figure out what is wrong. Is it a missing route? A wrong next hop? A TTL that is too low? These are real-world skills.”

“The quiz at the end tests your practical understanding,” said Bella the Battery. “It covers route selection, longest prefix matching, and multi-subnet design for IoT deployments. If you can pass the quiz, you are ready to configure routing for real IoT networks!”

11.2 Lab Series Overview

This routing lab series is organized into three focused chapters:

Chapter	Focus	Difficulty	Time
Routing Labs: Fundamentals	View tables, traceroute, ESP32 basics	Intermediate	30 min
Routing Labs: Advanced	Packet forwarding, convergence simulation	Advanced	45 min
Routing Labs: Algorithms	Dijkstra, Bellman-Ford, longest prefix	Advanced	40 min

---

11.3 Prerequisites

These labs build on the core routing theory. You will find them easier if you have already studied:

• Networking Basics - IP addressing, subnets, and default gateways
• Layered Models: Fundamentals - how the network layer fits into the stack
• Routing Fundamentals - static vs dynamic routing, metrics, and longest-prefix match
• Transport Fundamentals - basic understanding of TCP/UDP and ports

You should also be comfortable running simple commands in a terminal (PowerShell, Command Prompt, or a Linux shell).

Key Concepts

• Lab Environment: The simulated or physical network setup used for hands-on routing exercises, including routers, hosts, configured subnets, and connectivity.
• Knowledge Check: A formative assessment question verifying understanding of a specific routing concept before proceeding to more complex topics.
• OSPF Configuration: The process of enabling OSPF routing protocol on a router, defining OSPF area, advertising networks, and verifying neighbor relationships and routing table population.
• RIP Configuration: The simpler distance-vector routing protocol configuration; enables route sharing between directly connected neighbors using UDP port 520.
• Convergence Testing: Lab exercises verifying that the routing protocol correctly updates routing tables after topology changes (link failure, node addition/removal).

11.4 Cross-Hub Connections

These labs connect to multiple learning resources:

Simulations Hub:

• Network Topology Visualizer - Interactive tool to explore star, mesh, tree topologies and understand how topology affects routing decisions
• Routing Protocol Simulators - Compare distance-vector (RIP) vs link-state (OSPF) convergence behavior

Videos Hub:

• Routing Fundamentals Videos - Visual explanations of longest-prefix matching, TTL decrement, and routing table lookup
• RPL Protocol Deep Dive - DODAG formation, rank calculation, and parent selection in IoT networks

Knowledge Gaps Hub:

• Common Routing Misconceptions - Default route confusion, metric vs hop count, and static route precedence
• TTL vs Hop Count Confusion - Why TTL prevents loops but doesn’t measure distance

Quizzes Hub:

• Routing Mastery Quiz - Test longest-prefix matching, route selection, and failover scenarios
• RPL Protocol Quiz - DODAG construction, rank calculation, and routing metrics

These labs work best when combined with simulations (see routing behavior visually) and videos (understand WHY routes are selected before practicing HOW to configure them).

11.5 Getting Started (For Beginners)

For Beginners: Making the Most of Routing Labs

Routing can feel abstract until you see packets actually taking different paths. These labs are designed to connect the theory to real tools.

• If you are on a laptop where you can run route, ip route, ping, and traceroute:
  • Work through the labs in order and copy the commands exactly.
  • Compare your output with the examples and note any differences (different gateways, subnets, or hop counts).
• If you cannot run privileged commands (e.g., on a managed corporate machine):
  • Focus on reading the command examples and explanations.
  • Sketch routing tables on paper and answer the quiz questions to check your understanding.

Key ideas to keep in mind:

Idea	Plain-language explanation
Default route	“Send everything I don’t recognise to this next hop.”
Connected route	Automatically added when an interface gets an IP address
Metric	Cost value; lower metric = more preferred route
Hop	Each router a packet passes on its way to the destination

When the questions talk about “floating static routes” or “failover”, picture two default routes with different metrics, where the backup only becomes active when the primary path disappears. If that feels fuzzy, revisit Routing Fundamentals first, then come back to these labs.

---

11.6 Lab Network Topology Overview

Before diving into individual labs, let’s visualize a typical multi-router lab network topology that demonstrates routing concepts:

Figure 11.1: Lab Network Topology Setup: Multi-router lab environment demonstrating key routing concepts. Network 1 (192.168.1.0/24) represents your local network with a computer and ESP32, connected via gateway router R1. Network 2 (10.0.0.0/8) simulates an IoT sensor network behind router R2. Network 3 (172.16.0.0/16) represents backend servers behind router R3. Multiple paths exist between networks with different metrics, enabling testing of route selection, TTL decrement, longest-prefix matching, and multi-hop forwarding scenarios.

Figure 11.2: Alternative View: Router Decision Process - While the topology shows network layout, this flowchart shows HOW a router decides where to send each packet. First check: is destination local? If yes, deliver directly via ARP. If no, consult routing table using longest-prefix matching. The most specific matching route wins (172.16.0.0/16 beats 0.0.0.0/0 default). If no route matches, drop the packet and send ICMP unreachable. Understanding this decision process helps debug “destination unreachable” errors.

Putting Numbers to It

Longest-prefix matching determines which route wins when multiple overlap. For destination 192.168.10.50:

\[ \text{Prefix Length} = N \text{ (bits matched from left)} \]

where a /24 prefix matches the first 24 bits, /16 matches the first 16 bits, and /0 (default) matches zero bits (always matches).

Worked example: Routing table has three entries: - Route A: 192.168.0.0/16 (16-bit prefix, 65,536 hosts) - Route B: 192.168.10.0/24 (24-bit prefix, 256 hosts) - Route C: 0.0.0.0/0 (0-bit prefix, all destinations)

For 192.168.10.50: Route B matches with /24 (24 bits match), Route A with /16 (16 bits match), Route C with /0 (0 bits required). Route B wins (longest prefix = most specific). The router forwards to Route B’s next-hop, not the default route.

Lab Scenarios You Can Test

This topology enables hands-on practice with:

1. Direct Delivery (PC1 to ESP1): Both on 192.168.1.0/24, packets delivered locally without routing
2. Single Hop Routing (PC1 to IoT1): R1 forwards to R2 (one hop between networks)
3. Multi-Hop Routing (PC1 to Server): Packets traverse R1 to R2 to R3 or R1 to R3 (metric decides)
4. Default Route Testing (PC1 to Internet): All unknown destinations forward via R1 to ISP
5. Path Selection (R1 to R3): Direct link (metric 5) vs via R2 (metric 11), demonstrates lowest-cost path selection
6. TTL Tracking: traceroute from PC1 to DB shows TTL decrement at each hop

The labs below use this topology conceptually, even if you’re working on a simpler single-router setup.

11.6.1 Route Path Selection Calculator

Use this calculator to explore how metric values determine which path a router selects:

viewof primary_metric = Inputs.range([1, 50], {value: 5, step: 1, label: "Primary path metric (R1→R3 direct)"})

viewof via_r2_hop1 = Inputs.range([1, 30], {value: 1, step: 1, label: "R1→R2 link metric"})

viewof via_r2_hop2 = Inputs.range([1, 30], {value: 10, step: 1, label: "R2→R3 link metric"})

{
  const via_r2_total = via_r2_hop1 + via_r2_hop2;
  const winner = primary_metric <= via_r2_total ? "Direct (R1→R3)" : "Via R2 (R1→R2→R3)";
  const winner_metric = Math.min(primary_metric, via_r2_total);
  const color = primary_metric <= via_r2_total ? "#16A085" : "#E67E22";
  return html`<div style="background: var(--bs-light, #f8f9fa); padding: 1rem; border-radius: 8px; border-left: 4px solid ${color}; margin: 0.5rem 0;">
    <p><strong>Direct path (R1→R3):</strong> metric ${primary_metric}</p>
    <p><strong>Via R2 (R1→R2→R3):</strong> metric ${via_r2_hop1} + ${via_r2_hop2} = ${via_r2_total}</p>
    <p style="font-size: 1.1em;"><strong>Selected path:</strong> <span style="color: ${color};">${winner}</span> (metric ${winner_metric})</p>
    <p style="font-size: 0.85em; color: #7F8C8D;">Lower metric wins. Try setting primary metric > ${via_r2_total} to force the via-R2 path.</p>
  </div>`;
}

---

11.7 Quick Lab Navigation

Start with the fundamentals and progress to advanced topics:

11.7.1 1. Routing Labs: Fundamentals

• Lab 1: View routing tables with route print / ip route show
• Lab 2: Trace packet paths with traceroute
• Lab 3: ESP32 gateway configuration
• Common misconception: “More routes = better connectivity”

11.7.2 2. Routing Labs: Advanced

• Lab 4: ESP32 packet forwarding simulator (TTL decrement, route lookup)
• Lab 5: Python network convergence simulator
• Routing metrics comparison (hop count, ETX, latency)

11.7.3 3. Routing Labs: Algorithms

• Implementation 1: Routing table with longest prefix matching
• Implementation 2: Dijkstra’s shortest path (link-state routing)
• Implementation 3: Distance vector protocol (RIP simulation)
• Algorithm comparison: OSPF vs RIP

---

11.8 Quiz: Test Your Understanding

Understanding Check: IoT Gateway Redundancy Design

Scenario: You’re deploying 500 environmental sensors in a remote warehouse. Internet connectivity is critical for real-time alerts, but the site has unreliable internet:

• Primary connection: Fiber (99.9% uptime, 500 Mbps)
• Backup connection: 4G LTE (95% uptime when fiber fails, 25 Mbps, $50/GB overage)

Current Setup (Single Default Route):

ip route 0.0.0.0/0 via 192.168.1.1  # Fiber gateway only

Problem: When fiber fails (0.1% of time = 8.8 hours/year), sensors can’t send alerts. Fire detected at 2 AM? No alert until fiber restored 6 hours later.

Solution Options:

Option A: Manual failover (call IT, add LTE route, wait 30 min response time) Option B: Dual default routes with equal metrics (load balancing) Option C: Floating static route (primary metric 10, backup metric 100)

Floating Static Route Config:

ip route 0.0.0.0/0 via 192.168.1.1 metric 10   # Fiber - preferred
ip route 0.0.0.0/0 via 10.0.0.1 metric 100     # LTE - standby

How It Works:

• Normal: Fiber installed (metric 10 < 100), all traffic to fiber, LTE route ignored
• Fiber fails: Fiber route removed (link down), LTE route activates (only remaining default)
• Fiber returns: Fiber route reinstalled (metric 10 < 100), LTE route deactivated, failback automatic

The Math:

• Fiber downtime: 8.8 hours/year
• During downtime: 500 sensors x 12 readings/hour x 8.8 hours = 52,800 packets
• Average packet: 200 bytes
• LTE usage: 52,800 x 200 bytes = 10.56 MB/year
• LTE cost: 10.56 MB x $50/GB = $0.52/year (negligible)
• Benefit: Zero downtime for critical fire/safety alerts

Key Insight: The metric difference (10 vs 100) creates a clear preference hierarchy. When fiber is up, LTE costs $0. When fiber fails, LTE costs cents but maintains system availability.

Question 1: Router Decision Making

Question 2: Time-To-Live

Question 3: Routing Table Entries

Question 4: IoT Routing Protocols

Question 5: Floating Static Routes

---

11.9 RPL DODAG Formation

Figure 11.3: RPL DODAG Formation Process: Shows how RPL builds a Destination-Oriented Directed Acyclic Graph in three phases. Phase 1: Root node broadcasts DIO (DODAG Information Object) messages. Phase 2: Neighboring nodes receive DIOs, calculate their rank, and select the root as parent. Phase 3: Multi-level hierarchy forms as nodes propagate DIOs and deeper nodes select intermediate parents. Lower rank values indicate proximity to root, and routing follows parent relationships toward the root node.

Alternative View: RPL Message Exchange Timeline

This sequence diagram shows the temporal flow of RPL control messages during DODAG formation and data transmission, emphasizing the message types and their purposes.

Figure 11.4: RPL message exchange timeline showing three phases: DIO messages propagate downward from root to build DODAG hierarchy with each node calculating its rank. DAO messages flow upward to register routes and aggregate reachability information. Finally, sensor data follows the established parent chain upward to the border router. This temporal view complements the static topology diagram by showing HOW the routing structure is established through message exchanges.

Understanding RPL DODAG Formation

The diagram above illustrates how RPL creates routing hierarchies in IoT networks:

• Rank: Numerical value indicating distance from root (lower = closer)
• Parent Selection: Nodes choose best parent based on metrics (ETX, latency, hop count)
• Self-Healing: If a parent fails, nodes automatically select alternate parents
• Upward Routes: Established via DIO messages (toward root)
• Downward Routes: Established via DAO messages (toward leaf nodes)

This hierarchical structure is ideal for sensor networks where most traffic flows to/from a central gateway or border router.

---

11.10 Visual Reference Gallery

Routing Concept Visualizations

Explore visual representations of routing concepts covered in this chapter.

Distance Vector Routing

Figure 11.5: Distance vector routing protocol operation showing routers exchanging routing tables with neighbors, demonstrating the Bellman-Ford algorithm with hop counts and next-hop information.

Routing Tables

Figure 11.6: Routing table structure showing destination networks, subnet masks, next-hop addresses, and interface assignments.

Mesh Network Routing

Figure 11.7: Mesh network routing showing multiple redundant paths between nodes, enabling self-healing route discovery when links fail.

Match the Routing Protocol to Its Characteristic

Order the Router Forwarding Decision Steps

Common Pitfalls

1. Completing Labs Without Understanding the Underlying Protocol Behavior

Lab completion is not the goal — understanding why the protocol behaves as it does is. For every lab exercise, explain the routing protocol behavior observed before moving to the next exercise.

2. Not Testing Failure Scenarios in Labs

Labs that only verify successful routing miss the most important behavior — recovery from failures. Always include at least one failure injection test in every routing lab.

3. Skipping the Quiz to Focus on Labs

The quiz questions target conceptual gaps that hands-on labs may not reveal. Routing misconceptions at the conceptual level lead to hard-to-debug production issues. Complete both labs and quiz.

🏷️ Label the Diagram

Code Challenge

11.11 Summary

• Routing tables can be examined using route print (Windows) or ip route show (Linux/macOS) to view how packets are forwarded
• Traceroute commands map the complete path packets take across multiple routers, revealing network topology and performance bottlenecks
• Static routes can be manually configured on IoT devices and routers to direct traffic through specific gateways or interfaces
• TTL (Time-To-Live) decrements at each router hop and prevents routing loops by dropping packets when TTL reaches zero
• Routing protocols like RPL are specifically designed for low-power IoT networks, providing automatic route discovery and self-healing capabilities
• Longest prefix matching ensures routers select the most specific route available, with default routes serving as catch-all when no specific match exists
• Hands-on labs with ESP32 and Python demonstrate packet forwarding, route lookup algorithms, and convergence behavior in real networks

Worked Example: Designing Routing for a Multi-Subnet Industrial IoT Deployment

Scenario: A manufacturing plant needs to deploy 300 IoT devices across 4 production lines plus an office network. Each area requires network isolation for security, but devices must reach a central SCADA server and cloud analytics platform.

Network Requirements:

• Line 1 (Welding): 80 devices, 192.168.10.0/24
• Line 2 (Assembly): 100 devices, 192.168.20.0/24
• Line 3 (Packaging): 70 devices, 192.168.30.0/24
• Line 4 (QA/Testing): 50 devices, 192.168.40.0/24
• Office Network: 30 devices, 192.168.100.0/24
• SCADA Server: 10.50.50.10 (in DMZ 10.50.50.0/24)
• Cloud Gateway: Internet via 203.0.113.1

Design Challenge: Configure routing on the central gateway router to enable: 1. All production lines can reach SCADA server 2. All production lines can reach cloud (internet) 3. Office network can reach production lines (for diagnostics) 4. Production lines CANNOT reach each other directly (security isolation)

Gateway Router Configuration:

Interface Assignments:

eth0: 192.168.10.1/24   # Line 1 gateway
eth1: 192.168.20.1/24   # Line 2 gateway
eth2: 192.168.30.1/24   # Line 3 gateway
eth3: 192.168.40.1/24   # Line 4 gateway
eth4: 192.168.100.1/24  # Office gateway
eth5: 10.50.50.1/24     # SCADA DMZ gateway
eth6: 203.0.113.10/30   # Internet uplink

Step 1: Connected Routes (Automatic)

# These routes are automatically created when interfaces configured
ip addr show
# Output shows connected routes:
# 192.168.10.0/24 dev eth0
# 192.168.20.0/24 dev eth1
# 192.168.30.0/24 dev eth2
# 192.168.40.0/24 dev eth3
# 192.168.100.0/24 dev eth4
# 10.50.50.0/24 dev eth5
# 203.0.113.8/30 dev eth6

Step 2: Default Route for Internet Access

# All production lines need internet connectivity for cloud analytics
ip route add 0.0.0.0/0 via 203.0.113.9 dev eth6 metric 10

Step 3: Firewall Rules for Security Isolation

# ALLOW: Production lines → SCADA server
iptables -A FORWARD -s 192.168.10.0/24 -d 10.50.50.10 -j ACCEPT
iptables -A FORWARD -s 192.168.20.0/24 -d 10.50.50.10 -j ACCEPT
iptables -A FORWARD -s 192.168.30.0/24 -d 10.50.50.10 -j ACCEPT
iptables -A FORWARD -s 192.168.40.0/24 -d 10.50.50.10 -j ACCEPT

# ALLOW: Production lines → Internet (cloud)
iptables -A FORWARD -s 192.168.10.0/24 -o eth6 -j ACCEPT
iptables -A FORWARD -s 192.168.20.0/24 -o eth6 -j ACCEPT
iptables -A FORWARD -s 192.168.30.0/24 -o eth6 -j ACCEPT
iptables -A FORWARD -s 192.168.40.0/24 -o eth6 -j ACCEPT

# ALLOW: Office → Production lines (diagnostics)
iptables -A FORWARD -s 192.168.100.0/24 -d 192.168.10.0/24 -j ACCEPT
iptables -A FORWARD -s 192.168.100.0/24 -d 192.168.20.0/24 -j ACCEPT
iptables -A FORWARD -s 192.168.100.0/24 -d 192.168.30.0/24 -j ACCEPT
iptables -A FORWARD -s 192.168.100.0/24 -d 192.168.40.0/24 -j ACCEPT

# DENY: Production lines → Other production lines (security)
iptables -A FORWARD -s 192.168.10.0/24 -d 192.168.20.0/24 -j DROP
iptables -A FORWARD -s 192.168.10.0/24 -d 192.168.30.0/24 -j DROP
# ... (repeat for all cross-line combinations)

# Default DENY
iptables -P FORWARD DROP

Step 4: NAT for Internet-Bound Traffic

# Production devices use private IPs - need NAT for internet access
iptables -t nat -A POSTROUTING -o eth6 -j MASQUERADE

Verification Tests:

Test	Source	Destination	Expected Result	Actual Result
SCADA reachability	192.168.10.50 (Line 1)	10.50.50.10	Success	ping 10.50.50.10 - 0% loss ✓
Cloud connectivity	192.168.20.75 (Line 2)	8.8.8.8 (Google DNS)	Success	ping 8.8.8.8 - 0% loss ✓
Cross-line isolation	192.168.10.50 (Line 1)	192.168.20.75 (Line 2)	Blocked	ping 192.168.20.75 - 100% loss (filtered) ✓
Office diagnostics	192.168.100.10 (Office)	192.168.10.50 (Line 1)	Success	ping 192.168.10.50 - 0% loss ✓

Routing Table on Gateway:

ip route show
# Output:
# default via 203.0.113.9 dev eth6 metric 10
# 192.168.10.0/24 dev eth0 scope link
# 192.168.20.0/24 dev eth1 scope link
# 192.168.30.0/24 dev eth2 scope link
# 192.168.40.0/24 dev eth3 scope link
# 192.168.100.0/24 dev eth4 scope link
# 10.50.50.0/24 dev eth5 scope link
# 203.0.113.8/30 dev eth6 scope link

Key Design Decisions:

Decision	Rationale	Alternative Considered
Use single gateway router	Centralized control, easier firewall management	Per-line routers (more complex, higher cost)
Connected routes only	Simple, no dynamic routing overhead	OSPF (unnecessary for static topology)
Firewall for isolation	Layer 4 security without routing complexity	VLANs + inter-VLAN routing (requires Layer 3 switches)
NAT on internet egress	Conserve public IPs, hide internal topology	Public IPs for each device (expensive, security risk)

Lessons Learned:

1. Connected routes sufficient for star topologies – static routing works when all traffic funnels through central gateway
2. Firewall rules enforce security policies that routing alone cannot provide
3. Default route handles internet without needing specific routes for every cloud service
4. Proper testing verifies both positive cases (should work) and negative cases (should be blocked)

Scalability Considerations:

• Current: 300 devices across 5 subnets - single gateway handles easily
• Growth: If expanding to 10+ production lines, consider:
  • Route summarization (e.g., 192.168.0.0/20 for all lines)
  • Dynamic routing (OSPF) if topology becomes mesh
  • Load balancing across multiple gateways

Concept Relationships

This lab series builds upon:

• Networking Basics - IP addressing and subnets
• Layered Models: Fundamentals - Network layer function
• Routing Fundamentals - Core routing theory

This lab series connects to:

• Network Topologies - How topology affects routing
• Topologies Labs - Designing network layouts
• RPL Fundamentals - IoT-specific routing
• 6LoWPAN - IPv6 routing over constrained networks

Real-world applications:

• Configuring IoT gateways for multi-subnet deployments
• Designing redundant connectivity for critical systems
• Troubleshooting sensor-to-cloud communication paths
• Implementing failover routing for high-availability

See Also

Network Simulators:

• Cisco Packet Tracer - Routing configuration practice
• GNS3 - Advanced network emulation
• Contiki-NG COOJA - IoT routing simulator

Video Tutorials:

• ARP Demonstration - Address Resolution Protocol
• Routing Demonstration - Packet Tracer routing

Documentation:

• RPL RFC 6550 - IoT routing protocol spec
• OSPF Basics
• Linux ip route man page

Hands-On Resources:

• Simulations Hub - Routing simulators and tools
• Videos Hub - Routing video tutorials
• Knowledge Map - See routing in context

11.12 What’s Next

Previous	Up	Next
Routing Review: Advanced	Routing Fundamentals	Routing Labs: Fundamentals

After mastering routing fundamentals through hands-on practice, you’re ready to explore:

Network Topologies - Understanding how devices are physically and logically arranged in star, mesh, tree, and hybrid configurations

Wired Communication Protocols - Diving into RS-232, I2C, SPI, and other protocols for direct device-to-device connections

Wireless IoT Protocols - Exploring Wi-Fi, BLE, LoRaWAN, Zigbee, and their routing characteristics in mesh and star topologies

The routing concepts you’ve practiced - longest prefix matching, TTL management, and route convergence - directly apply when designing IoT networks. Many wireless protocols like Zigbee and Thread implement RPL routing internally, making your understanding of routing mechanics essential for troubleshooting and optimizing real deployments.

---