By the end of this section, you will be able to:
Packet switching means your data is broken into small pieces that each find their own way through the network, like cars on a highway that can take different exits to reach the same destination. Failover is what happens when a path breaks – the network automatically reroutes data through an alternate path, keeping communication alive.
“What happens when the path to the gateway is blocked?” asked Sammy the Sensor nervously. Max the Microcontroller reassured him. “In a packet-switched network, each packet finds its own way. If the usual path fails, routers automatically send your data on a detour – that is called failover.”
“Imagine a highway with multiple routes to your destination,” said Lila the LED. “If there is a traffic jam on Route A, you take Route B. Routers do the same thing – they keep backup paths ready and switch to them in milliseconds when the primary path fails.”
“The key word is AUTOMATIC,” emphasized Bella the Battery. “Nobody has to manually fix anything. The routing protocols constantly check link health and update their tables. When a link goes down, the next packet is already being sent on an alternate path. For IoT, this self-healing behavior is critical because nobody is going to climb a cell tower or wade into a field to manually reconnect a failed sensor.”
One of routing’s key benefits: Packets can be dynamically rerouted mid-stream if topology changes.
Scenario:
Even packets from the same TCP connection can take different paths!
If a router learns multiple routes to the same destination, it chooses the route with the lowest metric:
| Route | Next Hop | Metric | Selected? |
|---|---|---|---|
| Route 1 | 10.0.0.2 | 10 | No |
| Route 2 | 10.0.0.5 | 5 | Best |
| Route 3 | 10.0.0.8 | 20 | No |
Router always forwards packets along the “best” route.
The Misconception: Routing should always choose the path with fewest hops.
Why It’s Wrong:
Real-World Example:
The Correct Understanding:
Shortest is not Best. Optimize for your actual goal.
Let’s trace a real packet from an IoT temperature sensor to AWS cloud, with actual numbers and realistic network hops.
Scenario: Smart Agriculture Temperature Monitoring
Network Setup:
Farm Sensor -> LoRaWAN Gateway -> Edge Router -> ISP Router ->
Regional Router -> AWS Edge -> AWS Data CenterDevice Details:
Device: RAK7204 Sensor Action: Create packet and transmit via LoRa radio
Packet Created:
Source IP: 2001:db8:a:10::5 (sensor)
Dest IP: 2600:1f18:2148:bc00::1 (AWS)
TTL: 64 (initial value)
Payload: {"temp": 72.5, "humidity": 65, "timestamp": 1701234567}Transmission:
Device: RAK7249 LoRaWAN Gateway Action: Decapsulate LoRa, forward via Ethernet
Routing Decision:
Gateway Routing Table Check:
Destination: 2600:1f18:2148:bc00::1
Match: ::/0 (default route)
Next Hop: fd00:1::1 (farm router)
Interface: eth0 (wired Ethernet)TTL Update: 64 -> 63 (decremented)
Device: Cisco ISR 4331 Router Action: Forward to ISP over fiber
Routing Decision:
Router Routing Table:
Destination: 2600:1f18:2148:bc00::/64
Match: ::/0 (default route)
Next Hop: 2001:db8:b::1 (ISP border router)TTL Update: 63 -> 62
Link Details:
Device: Juniper MX960 Router Action: Forward to internet backbone
Routing Decision:
ISP Router Routing Table:
Destination: 2600:1f18:2148:bc00::/64
Protocol: BGP (Border Gateway Protocol)
AS Path: 64512 -> 7018 -> 16509 (to AWS)TTL Update: 62 -> 61
Routing Decision:
Regional Router Routing Table:
Destination: 2600:1f18:2148:bc00::/64
Protocol: BGP
Next Hop: AWS edge router (direct peer)TTL Update: 61 -> 60
Routing Decision:
AWS Internal Routing:
Destination: 2600:1f18:2148:bc00::1
Service: iot.us-east-1.amazonaws.com
Next Hop: IoT Core load balancerTTL Update: 60 -> 59 (final hop)
Packet Delivered!
| Metric | Value |
|---|---|
| Total Hops | 5 forwarding routers + destination |
| Total Distance | ~1,337 km |
| Total Latency | ~35.5 ms |
| Initial TTL | 64 |
| Final TTL | 59 |
| Packet Size | 90 bytes (payload + header) |
Path Taken:
Iowa Farm (sensor)
-> 2 km LoRa wireless
LoRaWAN Gateway
-> 50 m Ethernet
Farm Router
-> 15 km fiber
ISP Router (Des Moines)
-> 120 km dark fiber
Regional Router (Chicago)
-> 5 m cross-connect
AWS Edge Router
-> 1,200 km AWS backbone
AWS IoT Core (Virginia)Key Takeaways:
Scenario: A smart building has three routing paths from a temperature sensor cluster (192.168.10.0/24) to the central building management system (BMS). You need to determine which route the routing protocol will select.
Given:
| Path | Hops | Bandwidth | Delay | Link Reliability |
|---|---|---|---|---|
| Path A | 2 | 100 Mbps | 5 ms | 99.9% |
| Path B | 3 | 1 Gbps | 2 ms | 99.99% |
| Path C | 4 | 10 Mbps | 15 ms | 95% |
Step 1: Calculate RIP metric (hop count only)
RIP selects lowest hop count:
- Path A: 2 hops (WINNER for RIP)
- Path B: 3 hops
- Path C: 4 hopsStep 2: Calculate OSPF cost (bandwidth-based)
OSPF Cost = Reference Bandwidth / Link Bandwidth (minimum cost = 1)
Reference bandwidth = 100 Mbps (Cisco default)
Path A cost = 100/100 = 1 per hop x 2 hops = 2 total
Path B cost = 100/1000 = 0.1 -> rounds up to 1 per hop x 3 hops = 3 total
Path C cost = 100/10 = 10 per hop x 4 hops = 40 totalNote: OSPF costs are integers (minimum 1). With a 100 Mbps reference bandwidth, any link at or above 100 Mbps gets cost 1. To differentiate Gigabit from 100 Mbps links, increase the reference bandwidth (e.g., auto-cost reference-bandwidth 10000 for 10 Gbps). With a 10 Gbps reference:
Path A cost = 10000/100 = 100 per hop x 2 = 200 total
Path B cost = 10000/1000 = 10 per hop x 3 = 30 total (WINNER for OSPF)
Path C cost = 10000/10 = 1000 per hop x 4 = 4000 totalStep 3: Calculate RPL ETX metric (for IoT with lossy links)
ETX (Expected Transmission Count) = 1 / (delivery_rate x ack_rate)
Assuming symmetric links (delivery = ack rate):
Path A: ETX per hop = 1/(0.999 x 0.999) = 1.002
Total ETX = 1.002 x 2 = 2.004
Path B: ETX per hop = 1/(0.9999 x 0.9999) = 1.0002
Total ETX = 1.0002 x 3 = 3.001
Path C: ETX per hop = 1/(0.95 x 0.95) = 1.108
Total ETX = 1.108 x 4 = 4.432Step 4: Compare protocol selections
| Protocol | Metric Used | Selected Path | Why |
|---|---|---|---|
| RIP | Hop count | Path A (2 hops) | Fewest hops regardless of speed |
| OSPF | Bandwidth cost | Path B (cost 30)* | Highest bandwidth path |
| RPL | ETX | Path A (2.004) | Best reliability x hop balance |
*With 10 Gbps reference bandwidth. With the 100 Mbps default, OSPF selects Path A (cost 2) since 100 Mbps and 1 Gbps links both get cost 1.
Key Insight: Protocol selection dramatically affects routing behavior. For battery-powered IoT sensors on lossy wireless links, RPL’s ETX metric often chooses better paths than traditional hop count or bandwidth metrics.
ETX (Expected Transmission Count) quantifies how many transmissions are needed to successfully deliver one packet.
\[\text{ETX} = \frac{1}{p_{\text{fwd}} \times p_{\text{ack}}}\]
where \(p_{\text{fwd}}\) is forward delivery probability and \(p_{\text{ack}}\) is ACK delivery probability.
For a multi-hop path, cumulative ETX is:
\[\text{ETX}_{\text{total}} = \sum_{i=1}^{n} \text{ETX}_i\]
For example, a 3-hop path with link qualities 95%, 98%, 90%:
\[\begin{align*} \text{ETX}_1 &= 1/(0.95 \times 0.95) = 1.108 \\ \text{ETX}_2 &= 1/(0.98 \times 0.98) = 1.041 \\ \text{ETX}_3 &= 1/(0.90 \times 0.90) = 1.235 \\ \text{ETX}_{\text{total}} &= 1.108 + 1.041 + 1.235 = 3.384 \end{align*}\]
This means you need an average of 3.384 transmission attempts to successfully deliver one packet end-to-end. Compare this to a 2-hop path with 99% links: \(ETX = 1/(0.99 \times 0.99) \times 2 = 1.020 \times 2 = 2.04\). Fewer hops with better quality wins.
The Mistake: Many IoT developers assume that if a packet successfully travels from Sensor A to Gateway B, the return path from B to A will follow the same routers in reverse order. This assumption leads to connectivity issues when only one direction works.
Why This Happens:
Building: 12-story office with 480 IoT thermostats
Symptom: 60% of thermostats could send temperature readings but could not receive control commands.
Network Path Analysis:
Uplink (Working):
Thermostat → Floor Router → Border Router (NAT) → Cloud
- 2 hops, 5 ms latency
- NAT creates state entry: internal IP mapped to public IP
Downlink (Failing):
Cloud → Border Router → Building Core Router → Floor Router → Thermostat
- 3 hops, 12 ms latency (different path!)
- NAT state expired (60 s timeout) before return packet arrived
- Router dropped packet: "No NAT mapping found"Why Paths Differed:
The Fix:
# Increase NAT connection tracking timeout from 60s to 300s
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=300
sysctl -w net.netfilter.nf_conntrack_udp_timeout_stream=300
# Add static route to force symmetric return path
ip route add 10.0.0.0/8 via 192.168.1.1 dev eth0
# Alternative: Use connection tracking to force same-path return
iptables -t mangle -A PREROUTING -m conntrack --ctstate RELATED,ESTABLISHED \
-j CONNMARK --restore-markResults: Downlink delivery improved from 40% to 98%.
How to Detect Asymmetric Routing:
mtr --report --report-cycles 100 <target>) – high loss in only one direction indicates asymmetric path issuesDesign Principles:
Circuit switching guarantees dedicated bandwidth and fixed latency; packet switching provides best-effort delivery with variable latency. IoT real-time control applications need to account for packet switching’s variable delays.
Each router in a path introduces store-and-forward delay. Over 5 hops at 1 ms per hop, cumulative switching delay is 5 ms — negligible for telemetry but significant for real-time control. Calculate end-to-end switching delay for latency budgets.
Network packet loss has probabilistic characteristics (burst loss vs random loss) that affect application performance differently. TCP congestion control handles random loss well but struggles with burst loss from interference.
| Previous: Routing Tables | Next: IoT Routing |
| If you want to… | Read this |
|---|---|
| Understand how routes are determined | Routing Basics |
| Learn about connectivity requirements | End-to-End Connectivity |
| Study TTL and loop prevention | TTL and Loop Prevention |
| Apply concepts in hands-on labs | Routing Lab Fundamentals |
Continue to IoT Routing to learn about IoT-specific routing challenges, common mistakes, and failure scenarios to avoid.