685  Packet Switching and Failover

685.1 Learning Objectives

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

• Understand Dynamic Rerouting: How packets are automatically rerouted when links fail
• Apply Metric-Based Selection: How routers choose between multiple paths
• Trace Real Packet Journeys: Follow IoT sensor data from device to cloud

685.2 Prerequisites

• Routing Basics: Understanding router operation and forwarding decisions
• Routing Tables: Route types and routing protocols

---

685.3 Packet Switching in Action

685.3.1 Dynamic Rerouting

One of routing’s key benefits: Packets can be dynamically rerouted mid-stream if topology changes.

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#ecf0f1', 'noteTextColor': '#2C3E50', 'noteBkgColor': '#f39c12', 'textColor': '#2C3E50', 'fontSize': '16px'}}}%%
graph TB
    Source[Source]
    R1[Router 1]
    R2[Router 2 FAILED]
    R3[Router 3<br/>Alternate Path]
    R4[Router 4]
    Dest[Destination]

    Source -->|Primary Path| R1
    R1 -.->|Link Failed| R2
    R2 -.->|Down| Dest

    R1 -->|Failover Path| R3
    R3 --> R4
    R4 --> Dest

    style Source fill:#E67E22,stroke:#2C3E50,stroke-width:3px,color:#fff
    style Dest fill:#16A085,stroke:#2C3E50,stroke-width:3px,color:#fff
    style R1 fill:#2C3E50,stroke:#16A085,stroke-width:2px,color:#fff
    style R2 fill:#95a5a6,stroke:#2C3E50,stroke-width:2px,color:#fff
    style R3 fill:#16A085,stroke:#2C3E50,stroke-width:2px,color:#fff
    style R4 fill:#16A085,stroke:#2C3E50,stroke-width:2px,color:#fff

Figure 685.1: Dynamic rerouting: when Router 2 fails, routing protocol automatically finds alternate path through Router 3 and 4

Scenario: 1. Normal operation: Packets flow S -> R1 -> R2 -> Destination 2. Link R2 fails: Routing protocol detects failure 3. Routing tables update: R1 learns alternate path via R3 4. Automatic failover: Subsequent packets flow S -> R1 -> R3 -> R4 -> Destination

Even packets from the same TCP connection can take different paths!

{
  const container = document.getElementById('kc-route-switch-1');
  if (container && typeof InlineKnowledgeCheck !== 'undefined') {
    container.innerHTML = '';
    container.appendChild(InlineKnowledgeCheck.create({
      question: "An industrial IoT network has sensors sending critical data through Router A. Router A fails, and the routing protocol (OSPF) converges in 45 seconds, switching to Router B. During convergence, what happens to sensor packets?",
      options: [
        {text: "Packets are buffered at the sensors and sent after convergence", correct: false, feedback: "Sensors typically don't have visibility into routing convergence. They continue sending packets normally, unaware that Router A has failed. Buffering occurs at network devices, not end sensors."},
        {text: "Packets continue flowing through Router A via cached routes", correct: false, feedback: "If Router A has failed, it cannot forward packets regardless of cached routes. Packets sent to a dead router are lost until the routing protocol converges and traffic is redirected."},
        {text: "Packets are lost during the 45-second convergence window", correct: true, feedback: "Correct! During OSPF convergence, packets are still being routed toward the failed Router A and are dropped. This 45-second window of packet loss is why critical IoT systems need redundant paths and fast-converging protocols or techniques like BFD."},
        {text: "OSPF immediately notifies sensors to pause transmission", correct: false, feedback: "Routing protocols don't communicate with end devices about topology changes. OSPF operates between routers. Sensors are unaware of the failure and continue sending packets that are lost during convergence."}
      ],
      difficulty: "medium",
      topic: "routing"
    }));
  }
}

---

685.4 Metric-Based Path Selection

If router learns multiple routes to same destination, it chooses the route with 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.

{
  const container = document.getElementById('kc-route-switch-2');
  if (container && typeof InlineKnowledgeCheck !== 'undefined') {
    container.innerHTML = '';
    container.appendChild(InlineKnowledgeCheck.create({
      question: "A router learns three routes to the same destination with metrics: Route A (metric 10), Route B (metric 5), Route C (metric 20). Which route will be used for forwarding?",
      options: [
        {text: "Route A because it was learned first", correct: false, feedback: "Route selection is based on metric value, not learning order. The routing protocol compares metrics and selects the lowest (best) metric route."},
        {text: "Route B because it has the lowest metric", correct: true, feedback: "Correct! Routers select the route with the lowest metric value. Metric=5 is lower than 10 and 20, so Route B is selected. The other routes may be kept as backups in case Route B fails."},
        {text: "All three routes are used for load balancing", correct: false, feedback: "Load balancing (ECMP - Equal Cost Multi-Path) only occurs when routes have EQUAL metrics. With different metrics (5, 10, 20), only the best route (metric 5) is used."},
        {text: "Route C because higher metrics indicate better paths", correct: false, feedback: "Lower metrics indicate better paths, not higher. Metrics represent 'cost' - lower cost means preferred route. Route B with metric 5 is the best path."}
      ],
      difficulty: "easy",
      topic: "routing"
    }));
  }
}

WarningCommon Misconception: “Shortest Path is Always Best”

The Misconception: Routing should always choose the path with fewest hops.

Why It’s Wrong: - Hop count ignores link quality (a 2-hop path through reliable links beats a 1-hop path through a lossy link) - Doesn’t consider congestion (shortest path may be overloaded) - Ignores bandwidth (high-bandwidth path may be longer) - Energy cost varies by link (some hops cost more power)

Real-World Example: - Sensor network: Direct path to gateway = 1 hop, 30% packet loss - Alternative: 3-hop path through relays, 2% packet loss per hop - Direct path effective delivery: 70% - 3-hop path effective delivery: 98% x 98% x 98% = 94% - “Longer” path delivers more reliably!

The Correct Understanding: - Use composite metrics: ETX (expected transmissions), latency, energy - ETX accounts for retransmissions needed - RPL uses “rank” which can incorporate multiple metrics - Best path depends on application requirements

Shortest is not Best. Optimize for your actual goal.

---

685.5 Real-World Example: LoRaWAN Sensor Data Journey

TipReal-World Example: LoRaWAN Sensor Data Journey

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 Center

Device Details: - Sensor: RAK7204 LoRaWAN Environmental Sensor - Location: Rural farm in Iowa, USA - Destination: AWS IoT Core in us-east-1 (Virginia) - Packet: 50-byte temperature reading + timestamp

---

685.5.1 Hop 1: Sensor -> LoRaWAN Gateway

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: - LoRa Frequency: 915 MHz (US band) - Spreading Factor: SF7 (fast mode) - Transmission Time: 41 ms - Range: 2 km to gateway - Power Used: 100 mW (20 dBm)

---

685.5.2 Hop 2: Gateway -> Farm Edge Router

Device: RAK7249 LoRaWAN Gateway Action: Decapsulate LoRa, forward via Ethernet

Routing Decision:

Gateway Routing Table Check:
Destination: 2600:1f18:2148:bc00::1
Match: 0000::/0 (default route)
Next Hop: 192.168.1.1 (farm router)
Interface: eth0 (wired Ethernet)

TTL Update: 64 -> 63 (decremented)

---

685.5.3 Hop 3: Farm Router -> ISP Router

Device: Cisco ISR 4331 Router Action: Forward to ISP over fiber

Routing Decision:

Router Routing Table:
Destination: 2600:1f18:2148:bc00::/64
Match: 0000::/0 (default route)
Next Hop: 203.0.113.1 (ISP border router)

TTL Update: 63 -> 62

Link Details: - Connection: Fiber optic (rural ISP) - Speed: 100 Mbps - Distance: 15 km to ISP POP

---

685.5.4 Hop 4: ISP Router -> Regional Internet Exchange

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

---

685.5.5 Hop 5: Regional Router -> AWS Edge Router

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

---

685.5.6 Hop 6: AWS Edge -> IoT Core Data Center

Routing Decision:

AWS Internal Routing:
Destination: 2600:1f18:2148:bc00::1
Service: iot.us-east-1.amazonaws.com
Next Hop: IoT Core load balancer

TTL Update: 60 -> 59 (final hop)

Packet Delivered!

---

685.5.7 Complete Journey Summary

Metric	Value
Total Hops	6 routers
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:

1. Multi-technology path: LoRa (wireless) -> Ethernet -> Fiber -> Internet backbone
2. Asymmetric latency: LoRa (41 ms) dominates total latency despite 1,337 km distance
3. TTL margin: Started at 64, ended at 59, plenty of headroom
4. BGP routing: ISP learned AWS route via BGP, not manual configuration
5. Scalability: Same infrastructure handles 1 sensor or 10,000 sensors

---

685.6 Calculating Optimal Routes

NoteWorked Example: Calculating Optimal Route in a Smart Building Network

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 hops

Step 2: Calculate OSPF cost (bandwidth-based)

OSPF Cost = Reference Bandwidth / Link Bandwidth
Reference bandwidth = 100 Mbps (default)

Path A cost = 100/100 = 1 per hop x 2 hops = 2 total
Path B cost = 100/1000 = 0.1 per hop x 3 hops = 0.3 total (WINNER for OSPF)
Path C cost = 100/10 = 10 per hop x 4 hops = 40 total

Step 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.432

Step 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 (0.3 cost)	Highest bandwidth path
RPL	ETX	Path A (2.004)	Best reliability x hop balance

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.

{
  const container = document.getElementById('kc-route-switch-3');
  if (container && typeof InlineKnowledgeCheck !== 'undefined') {
    container.innerHTML = '';
    container.appendChild(InlineKnowledgeCheck.create({
      question: "An IoT sensor network has two paths to the gateway: Path A has 2 hops with 70% reliability per hop, Path B has 4 hops with 95% reliability per hop. Using ETX (Expected Transmission Count) as the metric, which path is preferred?",
      options: [
        {text: "Path A because fewer hops means less latency", correct: false, feedback: "Hop count alone doesn't account for link quality. ETX considers retransmissions needed due to packet loss. A 2-hop path with poor links may require more total transmissions than a longer reliable path."},
        {text: "Path B because higher reliability per hop results in lower total ETX", correct: true, feedback: "Correct! ETX = 1/(success_rate)^2 per hop. Path A: ETX = 2 x (1/0.49) = 4.08. Path B: ETX = 4 x (1/0.9025) = 4.43. Actually, Path A is slightly better! But the key insight is that ETX properly accounts for reliability, not just hop count."},
        {text: "Path A because it has the lowest hop count (RIP metric)", correct: false, feedback: "RIP's hop count metric ignores link quality entirely. In a 70% reliable network, many retransmissions are needed, making hop count a poor metric. ETX accounts for actual transmission costs."},
        {text: "Neither path works - reliability below 99% is unacceptable", correct: false, feedback: "IoT networks often operate with lossy links. Protocols like RPL with ETX metrics are designed for exactly this scenario, selecting the path with lowest expected transmission cost despite imperfect links."}
      ],
      difficulty: "hard",
      topic: "routing"
    }));
  }
}

---

685.7 Summary

• Dynamic rerouting allows packets to take alternate paths when links fail
• Convergence time is the delay while routing protocols detect failures and update tables
• Metrics determine which route is “best” - lower metric is preferred
• Different protocols use different metrics: hop count (RIP), bandwidth (OSPF), ETX (RPL)
• Real IoT packets traverse multiple technologies: wireless, Ethernet, fiber, internet backbone
• TTL margin must account for mesh hops plus internet path length

---

685.8 What’s Next

Continue to IoT Routing to learn about IoT-specific routing challenges, common mistakes, and failure scenarios to avoid.