690  Routing Labs: Fundamentals

690.1 Learning Objectives

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

• Examine routing tables using system commands on Windows, Linux, and macOS platforms
• Interpret route entries including connected routes, static routes, and default gateways
• Use traceroute tools to map network paths and identify routing hops
• Configure ESP32 networking to retrieve gateway information and understand routing decisions
• Identify routing misconceptions such as “more routes = better connectivity”

NoteRelated Chapters

Lab Series: - Routing Labs: Overview - Lab series introduction and quiz - Routing Labs: Advanced - ESP32 packet forwarding and convergence simulation - Routing Labs: Algorithms - Python implementations of routing algorithms

Core Concepts: - Routing Fundamentals - Core routing theory and concepts - Routing Comprehensive Review - Advanced routing strategies

IoT Routing: - RPL Fundamentals - Low-power routing protocol - RPL Labs - Hands-on RPL implementation

Learning: - Simulations Hub - Routing simulators and tools - Videos Hub - Routing video tutorials

690.2 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

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

---

690.3 Lab 1: View Routing Table

Objective: Examine the routing table on your system.

690.3.1 Windows:

route print
# OR
netstat -r

690.3.2 macOS/Linux:

route -n
# OR
ip route show
# OR
netstat -rn

Expected output:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG    100    0        0 wlan0
192.168.1.0     0.0.0.0         255.255.255.0   U     100    0        0 wlan0

Interpretation:

• 0.0.0.0 = Default route (all unknown destinations)
• 192.168.1.0 = Connected local network
• 192.168.1.1 = Default gateway

TipUnderstanding the Output

Field	Meaning
Destination	Target network or host
Gateway	Next hop router (0.0.0.0 means direct delivery)
Genmask	Subnet mask defining network size
Flags	U=Up, G=Gateway, H=Host route
Metric	Route cost (lower = preferred)
Iface	Network interface to use

690.3.3 Route Types Explained

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
graph LR
    subgraph Connected["Connected Route"]
        C1["192.168.1.0/24"]
        C2["Gateway: 0.0.0.0<br/>(Direct Delivery)"]
        C3["Interface: eth0"]
        C1 --> C2 --> C3
    end

    subgraph Static["Static Route"]
        S1["172.16.0.0/16"]
        S2["Gateway: 10.0.0.2"]
        S3["Interface: eth1"]
        S1 --> S2 --> S3
    end

    subgraph Default["Default Route"]
        D1["0.0.0.0/0"]
        D2["Gateway: 192.168.1.1"]
        D3["Interface: eth0"]
        D1 --> D2 --> D3
    end

    style C1 fill:#16A085,stroke:#16A085,color:#fff
    style S1 fill:#E67E22,stroke:#E67E22,color:#fff
    style D1 fill:#2C3E50,stroke:#2C3E50,color:#fff

Figure 690.1: Route Types: Connected routes are added automatically when an interface is configured. Static routes are manually configured to direct traffic through specific gateways. The default route (0.0.0.0/0) is the “gateway of last resort” for all unknown destinations.

---

690.4 Common Misconception: More Routes = Better

WarningCommon Misconception: “More Routes = Better Connectivity”

The Misconception: Many beginners believe that adding more routes to the routing table improves network connectivity and performance. They think: “If I add 10 static routes, my network will be 10x faster!”

The Reality: Routing tables don’t generate connectivity - they document existing paths. Adding routes without corresponding network interfaces or gateways does nothing. Worse, incorrect routes break working connections.

Real-World Impact (Quantified):

Case 1: Route Overload on IoT Gateway

• System: 50-sensor LoRaWAN gateway with 2 interfaces (Wi-Fi + Ethernet)
• Misconfiguration: Admin added 247 static routes “just in case” for future subnets
• Result:
  • Route lookup time: 2ms to 45ms (22.5x slower)
  • Packet forwarding rate: 1,000 pps to 180 pps (82% drop)
  • CPU utilization: 12% to 67% (routing table scans)
  • Gateway became bottleneck for entire sensor network

Case 2: Duplicate Routes Causing Flapping

• System: Industrial PLC with dual Ethernet (production + backup)
• Misconfiguration: Two default routes with equal metrics to different gateways
• Result:
  • Connections to cloud server flapped every 30 seconds (load balancing)
  • TCP sessions reset repeatedly (different source IPs per gateway)
  • Data loss: 18% of MQTT messages failed (session disruption)
  • Downtime: 4 hours until correct metric prioritization configured

Case 3: Missing Connected Route

• System: ESP32 with static IP 192.168.1.100/24, gateway 192.168.1.1
• Misconfiguration: Manually added routes, forgot connected route for 192.168.1.0/24
• Result:
  • Device could NOT communicate with local devices (192.168.1.50, etc.)
  • All local traffic incorrectly forwarded to gateway (192.168.1.1)
  • Gateway rejected and looped packets back (routing loop!)
  • Network admin manually pinged device: “Why isn’t it responding?!”

690.4.1 Key Routing Principles

Principle	Explanation	Example
Routes document paths, don’t create them	A route to 10.0.0.0/8 is useless if no interface can reach that network	Adding ip route 10.0.0.0 255.0.0.0 192.168.1.254 won’t work if 192.168.1.254 doesn’t exist
Fewer, specific routes > Many generic routes	3 well-designed routes outperform 50 redundant routes	Home network: 192.168.1.0/24 connected, 10.0.0.0/8 via VPN, 0.0.0.0/0 via ISP
Default route is your safety net	If you have a default route (0.0.0.0/0), you rarely need additional static routes	Most IoT devices need ONLY: connected routes (automatic) + default gateway (1 route)
Equal-metric routes = Load balancing OR flapping	Two routes to same destination with equal cost causes round-robin	Avoid equal metrics for failover - use different metrics (10 vs 100)

690.4.2 Correct Approach for IoT Devices

Minimal routing table (ESP32, Arduino, Raspberry Pi):

Destination       Gateway       Interface  Type
192.168.1.0/24    0.0.0.0       wlan0      Connected (automatic)
0.0.0.0/0         192.168.1.1   wlan0      Default (one static route)

That’s it! Two routes. One connected (automatic), one default (configured). Covers 100% of destinations.

---

690.5 Lab 2: Traceroute

Objective: Map the path packets take to a destination.

# Windows
tracert google.com

# macOS/Linux
traceroute google.com

Sample output:

 1  192.168.1.1 (Gateway)              1.234 ms
 2  10.0.0.1 (ISP Router)              5.678 ms
 3  203.0.113.1 (Regional)            12.345 ms
 4  198.51.100.1 (Backbone)           18.901 ms
...
15  142.250.185.46 (google.com)       25.678 ms

Each line = One router (hop) along the path

690.5.1 Understanding Traceroute Output

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
sequenceDiagram
    participant S as Source
    participant G as Gateway<br/>(Hop 1)
    participant I as ISP Router<br/>(Hop 2)
    participant R as Regional<br/>(Hop 3)
    participant D as Destination<br/>(Hop 4)

    Note over S,D: Probe 1: TTL=1
    S->>G: TTL=1
    G-->>S: ICMP Time Exceeded<br/>1.2ms

    Note over S,D: Probe 2: TTL=2
    S->>G: TTL=2
    G->>I: TTL=1
    I-->>S: ICMP Time Exceeded<br/>5.6ms

    Note over S,D: Probe 3: TTL=3
    S->>G: TTL=3
    G->>I: TTL=2
    I->>R: TTL=1
    R-->>S: ICMP Time Exceeded<br/>12.3ms

    Note over S,D: Probe 4: TTL=4
    S->>G: TTL=4
    G->>I: TTL=3
    I->>R: TTL=2
    R->>D: TTL=1
    D-->>S: ICMP Echo Reply<br/>18.9ms

Figure 690.2: How Traceroute Works: Sends packets with incrementing TTL values. Each router decrements TTL; when TTL reaches 0, the router sends ICMP Time Exceeded back to source. The response reveals the router’s IP and round-trip time.

690.5.2 Common Traceroute Patterns

Pattern	Meaning	Example
* * *	Router not responding to ICMP	Firewall blocking, stealth router
Increasing latency	Normal - each hop adds delay	1ms, 5ms, 12ms, 25ms
Sudden jump	Geographic distance or congestion	12ms to 180ms (crossing ocean)
Same IP repeated	Routing loop or load balancer	Same IP at hops 5, 6, 7
Private IPs (10.x, 192.168.x)	Internal network hops	Your ISP’s internal routing

TipTraceroute for IoT Debugging

Use traceroute to diagnose:

• Cloud connection issues: See where packets get stuck
• High latency: Identify congested hops
• Routing loops: Detect loops before TTL expires
• Path changes: Compare traces over time

---

690.6 Lab 3: Configure Static Route (ESP32 Example)

Objective: Add a static route on IoT device.

#include <Wi-Fi.h>

const char* ssid = "YourNetwork";
const char* password = "YourPassword";

void setup() {
  Serial.begin(115200);
  Wi-Fi.begin(ssid, password);

  while (Wi-Fi.status() != WL_CONNECTED) {
    delay(500);
    Serial.print(".");
  }

  Serial.println("\n\n=== Default Gateway ===");
  Serial.print("Gateway: ");
  Serial.println(Wi-Fi.gatewayIP());

  // In production, you might need to add static routes
  // for VPN or multi-homed networks
  // (ESP32 doesn't directly support static routes via API,
  //  but gateway configuration determines default path)
}

void loop() {
  // Your application
}

TipTry It: ESP32 Network Information Simulator

Run this code to see how ESP32 retrieves gateway and network configuration. The simulator shows the connection process and displays the default gateway IP.

What to Observe:

• Gateway IP: The router address that forwards packets to other networks
• Routing Decisions: ESP32 sends all internet-bound traffic to this gateway
• Try: Modify code to print Wi-Fi.localIP() and Wi-Fi.subnetMask() for full routing context

Note: Most IoT devices use single default route to gateway. Multi-route scenarios typically handled by gateway/router.

690.6.1 ESP32 Network Stack

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
graph TD
    subgraph Application["Application Layer"]
        A1["Your Code<br/>Wi-Fi.gatewayIP()"]
    end

    subgraph TCPIP["TCP/IP Stack"]
        T1["Socket API"]
        T2["TCP/UDP Layer"]
        T3["IP Layer<br/>(Routing Decision)"]
    end

    subgraph Network["Network Layer"]
        N1["LwIP (Lightweight IP)"]
        N2["ARP Cache"]
        N3["Routing Table"]
    end

    subgraph Driver["Wi-Fi Driver"]
        D1["ESP-IDF Wi-Fi"]
        D2["802.11 MAC"]
    end

    A1 --> T1
    T1 --> T2
    T2 --> T3
    T3 --> N1
    N1 --> N2
    N1 --> N3
    N3 --> D1
    D1 --> D2

    style A1 fill:#E67E22,stroke:#E67E22,color:#fff
    style T3 fill:#16A085,stroke:#16A085,color:#fff
    style N3 fill:#2C3E50,stroke:#2C3E50,color:#fff

Figure 690.3: ESP32 Network Stack: When your application sends data, it passes through the TCP/IP stack. The IP layer consults the routing table (typically just a default gateway) to decide where to forward packets. For most IoT applications, all non-local traffic goes to the Wi-Fi gateway.

---

690.7 Lab Network Topology Overview

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

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
graph TD
    subgraph Net1["Network 1: 192.168.1.0/24<br/>(Your Local Network)"]
        PC1["PC1<br/>192.168.1.100"]
        ESP1["ESP32<br/>192.168.1.50"]
    end

    subgraph Net2["Network 2: 10.0.0.0/8<br/>(IoT Sensor Network)"]
        IoT1["Sensor 1<br/>10.0.0.10"]
        IoT2["Sensor 2<br/>10.0.0.20"]
    end

    subgraph Net3["Network 3: 172.16.0.0/16<br/>(Backend Servers)"]
        Server["Web Server<br/>172.16.0.100"]
        DB["Database<br/>172.16.0.200"]
    end

    R1["Router R1<br/>Gateway<br/>192.168.1.1"]
    R2["Router R2<br/>10.0.0.1"]
    R3["Router R3<br/>172.16.0.1"]
    ISP["ISP Router<br/>(Internet)"]

    PC1 ---|"Direct"| R1
    ESP1 ---|"Direct"| R1
    R1 ---|"metric 1"| R2
    R1 ---|"metric 5"| R3
    R2 ---|"metric 10"| R3
    R1 ---|"Default route"| ISP
    R2 --- IoT1
    R2 --- IoT2
    R3 --- Server
    R3 --- DB

    style PC1 fill:#2C3E50,stroke:#16A085,color:#fff
    style ESP1 fill:#E67E22,stroke:#16A085,color:#fff
    style IoT1 fill:#E67E22,stroke:#16A085,color:#fff
    style IoT2 fill:#E67E22,stroke:#16A085,color:#fff
    style Server fill:#16A085,stroke:#16A085,color:#fff
    style DB fill:#16A085,stroke:#16A085,color:#fff
    style R1 fill:#2C3E50,stroke:#16A085,color:#fff
    style R2 fill:#16A085,stroke:#16A085,color:#fff
    style R3 fill:#16A085,stroke:#16A085,color:#fff
    style ISP fill:#7F8C8D,stroke:#16A085,color:#fff

Figure 690.4: 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.

TipLab 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

---

690.8 Summary

• Viewing routing tables with route print (Windows) or ip route show (Linux/macOS) reveals how your system makes forwarding decisions
• Routing table entries include connected routes (automatic), static routes (manual), and default routes (catch-all)
• Traceroute maps the complete path packets take by incrementing TTL values and capturing ICMP responses
• ESP32 gateway configuration determines where non-local packets are forwarded since most IoT devices use a single default route
• Common misconceptions about routing tables include thinking more routes improve performance when in reality minimal, correct routes are optimal
• Route types (connected, static, default) serve different purposes and are selected based on longest-prefix matching

690.9 What’s Next

Continue to Routing Labs: Advanced for hands-on ESP32 packet forwarding simulation and Python convergence visualization.

Alternatively, explore Routing Labs: Algorithms for Python implementations of routing table lookup, Dijkstra’s algorithm, and distance vector protocols.

---