12  Routing Labs: Fundamentals

In 60 Seconds

Hands-on lab for examining routing tables using system commands on Windows, Linux, and macOS. Covers interpreting connected routes, static routes, and default gateways, using traceroute to map network paths, and configuring ESP32 networking to retrieve gateway information.

12.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 distinguishing connected routes, static routes, and default gateways
  • Trace network paths using traceroute to map routing hops and diagnose latency
  • Configure ESP32 networking to retrieve gateway information and verify routing decisions
  • Refute routing misconceptions such as “more routes = better connectivity” with evidence

These hands-on labs let you practice routing concepts by configuring devices and watching how data travels through a network. No prior experience needed – each exercise starts simple and builds up, like learning to navigate a small town before tackling a big city highway system.

“Time to look at a real routing table,” said Max the Microcontroller. “On your computer, you can type route print on Windows, netstat -rn on Linux, or netstat -nr on macOS to see how your own device routes packets.”

“You will see entries for connected networks, static routes, and the default gateway,” explained Sammy the Sensor. “The default gateway is especially important – it is the address your computer sends packets to when it does not know where a destination is.”

“Traceroute is another amazing tool,” added Lila the LED. “It shows every router between you and a destination by sending packets with increasing TTL values. Each router that drops a packet sends back an error message, revealing its address. You can literally map the internet path!”

“We even get to program an ESP32 to read its gateway information,” said Bella the Battery. “IoT devices need to know their default gateway to send data to the cloud. This lab shows you exactly how that works in embedded code.”

Lab Series:

Core Concepts:

IoT Routing:

Learning:

12.2 Prerequisites

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

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

Key Concepts

  • Cisco Packet Tracer: A free network simulation tool widely used for learning routing concepts; supports configuring routers, switches, and hosts with Cisco IOS commands.
  • Static Route Configuration: The manual process of adding ip route <destination> <mask> <next-hop> entries to a router’s configuration.
  • Ping (ICMP Echo): A network diagnostic sending ICMP Echo Request packets to test reachability; the response confirms the path to the destination is working.
  • Traceroute: A diagnostic tool that maps the route a packet takes by sending packets with incrementing TTL values and collecting ICMP Time Exceeded responses.
  • Subnet: A logical subdivision of an IP network identified by a network prefix (e.g., 192.168.1.0/24); routers connect separate subnets.

12.3 Lab 1: View Routing Table

Objective: Examine the routing table on your system.

12.3.1 Windows:

route print
# OR
netstat -r

12.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
Understanding 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

12.3.3 Route Types Explained

Diagram showing three types of routing table entries: Connected routes (automatically added when interface gets IP), Static routes (manually configured by administrator), and Default routes (catch-all for unknown destinations). Connected routes show direct delivery via local interface, static routes show next-hop gateway address, and default route (0.0.0.0/0) forwards to ISP gateway.
Figure 12.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.

12.4 Common Misconception: More Routes = Better

Common 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?!”

12.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)

12.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.

12.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

12.5.1 Understanding Traceroute Output

Traceroute output visualization showing packet journey from source through 5 hops to destination. Hop 1 is local gateway at 1ms, Hop 2 is ISP router at 5ms, Hop 3 is regional router at 12ms, Hop 4 is backbone router at 18ms, Hop 5 is destination at 25ms. Each hop shows TTL decrement and ICMP Time Exceeded message generation.
Figure 12.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.

12.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
Traceroute 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

12.6 Lab 3: Configure Static Route (ESP32 Example)

Objective: Add a static route on IoT device.

#include <WiFi.h>

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

void setup() {
  Serial.begin(115200);
  WiFi.begin(ssid, password);

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

  Serial.println("\n\n=== Default Gateway ===");
  Serial.print("Gateway: ");
  Serial.println(WiFi.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
}
Try 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 WiFi.localIP() and WiFi.subnetMask() for full routing context

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

12.6.1 ESP32 Network Stack

ESP32 network stack diagram showing layers from application code through TCP/IP stack to Wi-Fi driver. Application layer calls WiFi.gatewayIP(), TCP/IP stack manages routing decisions, and Wi-Fi driver handles wireless communication. Default gateway configuration determines where non-local packets are forwarded.
Figure 12.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.

12.7 Lab Network Topology Overview

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

Network topology diagram showing multi-router lab environment with three networks. Network 1 (192.168.1.0/24) contains PC1 and ESP32 connected to Router R1 (gateway at 192.168.1.1). Network 2 (10.0.0.0/8) contains IoT Sensor 1 and Sensor 2 connected to Router R2 (10.0.0.1). Network 3 (172.16.0.0/16) contains Web Server and Database connected to Router R3 (172.16.0.1). Routers are interconnected: R1 connects to R2 with metric 1, R1 to R3 with metric 5, R2 to R3 with metric 10, and R1 has default route to ISP router for internet access.
Figure 12.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.
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

How fast is route lookup in practice? Consider a router forwarding 1 Gbps traffic (100-byte packets = 1.25 million packets/second).

Linear search (check each route sequentially): - 100,000 routes in table - Average 50,000 comparisons per lookup - At 2 ns per comparison: \(50{,}000 \times 2\text{ ns} = 100\text{ µs per packet}\) - Maximum throughput: \(1 / 100\text{ µs} = 10{,}000\text{ packets/sec}\) = 8 Mbps (bottleneck!)

Longest prefix match (binary trie data structure): - Lookup time: \(O(\log_2 n) = \log_2(100{,}000) \approx 17\) comparisons - At 2 ns per comparison: \(17 \times 2 = 34\text{ ns per packet}\) - Maximum throughput: \(1 / 34\text{ ns} \approx 29.4\text{ million packets/sec}\) = 23.5 Gbps (no bottleneck)

Hardware CAM (Content Addressable Memory - modern routers): - Parallel lookup: all routes checked simultaneously in 1 clock cycle (< 5 ns) - Maximum throughput: \(1 / 5\text{ ns} = 200\text{ million packets/sec}\) = 160 Gbps

Real-world impact: A $50 home router uses software lookup (34 ns) → handles 1 Gbps fine. A $10,000 enterprise router uses CAM → handles 100 Gbps. Algorithm choice determines hardware cost!

Try It: Route Lookup Performance Calculator

Adjust routing table size and lookup method to see the impact on maximum packet throughput.

Common Pitfalls

Adding a static route command doesn’t guarantee the route is installed correctly. Always view the routing table after configuration to confirm the route appears with the correct prefix, mask, and next-hop.

A ping failure might mean the request doesn’t reach the destination OR the reply doesn’t reach the source. Check routing tables at both ends and trace both directions of the path independently.

Lab exercises use private IP ranges (10.x.x.x, 192.168.x.x) that differ from production addressing. When transitioning from lab to production, verify all address ranges, subnet masks, and default gateways are updated.

12.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

12.9 Knowledge Check

Common Mistake: Configuring Static Routes Without Testing Reachability

The Mistake: Administrators add static routes to routing tables without verifying that the next-hop gateway is actually reachable. The route appears in the routing table, but packets get dropped because the next hop doesn’t respond.

Real-World Example:

Scenario: IoT gateway for 50 environmental sensors needs to reach corporate data center at 172.16.0.0/16

Administrator configures:

# Add static route to data center
ip route add 172.16.0.0/16 via 192.168.1.254

# Check routing table
ip route show
# Output: 172.16.0.0/16 via 192.168.1.254 dev eth0

Result: Routing table shows the route, but sensors can’t reach data center!

What Went Wrong:

Problem 1: Next-Hop Not in Local Subnet

# Gateway IP configuration
ip addr show eth0
# Output: inet 192.168.1.10/24 brd 192.168.1.255 scope global eth0

# Next-hop specified: 192.168.1.254
# Local subnet: 192.168.1.0/24 (covers .1 to .254)
# Next-hop IS in local subnet ✓

# BUT: Is 192.168.1.254 actually online?
ping 192.168.1.254 -c 4
# Output: 100% packet loss (0 received)

Why This Happens: The next-hop router 192.168.1.254 doesn’t exist or is offline. The static route references a non-existent gateway.

Problem 2: ARP Cannot Resolve Next-Hop MAC Address

# Check ARP table
arp -n | grep 192.168.1.254
# Output: (empty - no ARP entry)

# The gateway tries to forward packets to 192.168.1.254
# But without MAC address, packets cannot be sent at Layer 2
# Packets are queued then dropped

Correct Configuration Process:

Step 1: Verify Next-Hop Reachability

# Ping the next-hop gateway FIRST
ping 192.168.1.254 -c 4

# Expected output:
# 64 bytes from 192.168.1.254: icmp_seq=1 ttl=64 time=1.2 ms
# 4 packets transmitted, 4 received, 0% packet loss

# If ping fails, next hop is unreachable - DO NOT add static route

Step 2: Check ARP Resolution

# After successful ping, check ARP table
arp -n | grep 192.168.1.254

# Expected output:
# 192.168.1.254   ether   aa:bb:cc:dd:ee:ff   C   eth0

# This confirms Layer 2 reachability

Step 3: Add Static Route

# NOW add the static route
ip route add 172.16.0.0/16 via 192.168.1.254

# Verify installation
ip route show | grep 172.16
# Output: 172.16.0.0/16 via 192.168.1.254 dev eth0

Step 4: Test End-to-End Connectivity

# Test actual destination reachability
ping 172.16.0.10 -c 4

# Expected output:
# 64 bytes from 172.16.0.10: icmp_seq=1 ttl=62 time=15 ms
# 4 packets transmitted, 4 received, 0% packet loss

# If this fails, problem is beyond the next hop (e.g., return routing)

Diagnostic Checklist:

Test Command Pass Criteria If Fails
Next-hop ping ping 192.168.1.254 0% packet loss Next hop unreachable - check cabling/config
ARP resolution arp -n \| grep 192.168.1.254 MAC address present Layer 2 issue - check switch/VLAN
Route installed ip route show \| grep 172.16 Route visible in table Syntax error or permission issue
Destination ping ping 172.16.0.10 0% packet loss Return path issue or firewall blocking
Traceroute traceroute 172.16.0.10 Shows path via 192.168.1.254 Routing loop or asymmetric path

IoT Gateway Automation (Prevent This Mistake):

#!/bin/bash
# safe-static-route.sh - Add static route only if next-hop reachable

DESTINATION="172.16.0.0/16"
NEXTHOP="192.168.1.254"
INTERFACE="eth0"

echo "Testing reachability of next-hop $NEXTHOP..."
if ping -c 3 -W 2 "$NEXTHOP" > /dev/null 2>&1; then
    echo "Next-hop reachable. Adding static route..."
    ip route add "$DESTINATION" via "$NEXTHOP" dev "$INTERFACE"

    # Verify route installation
    if ip route show | grep -q "$DESTINATION"; then
        echo "Route added successfully:"
        ip route show | grep "$DESTINATION"
    else
        echo "ERROR: Route installation failed"
        exit 1
    fi
else
    echo "ERROR: Next-hop $NEXTHOP is unreachable. Route NOT added."
    exit 1
fi

Key Takeaways:

  1. Always ping next-hop before adding static route – verify reachability
  2. Check ARP resolution to confirm Layer 2 connectivity
  3. Test end-to-end after adding route to verify full path
  4. Automate validation in deployment scripts to prevent human error
  5. Monitor next-hop availability – if gateway goes down, route becomes useless even if still in table

Why This Matters for IoT: IoT gateways often operate remotely with limited physical access. A misconfigured static route can cause hours of downtime while technicians travel to site, when the issue could have been prevented with 30 seconds of ping testing before deployment.

This lab builds upon:

This lab connects to:

Real-world applications:

  • IoT gateway configuration for cloud connectivity
  • Troubleshooting sensor-to-cloud paths with traceroute
  • Designing redundant uplinks for critical deployments

Command Reference:

ESP32 Networking:

Related Labs:

12.10 What’s Next

Previous Up Next
Routing Labs and Quiz Routing Labs and Quiz Routing Labs: Advanced

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.