687 End-to-End Connectivity and Worked Examples

687.1 Learning Objectives

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

Identify Connectivity Requirements: Three essential components for IoT end-to-end connectivity
Configure Static Routes: Set up routes for IoT gateways
Diagnose Routing Issues: Use traceroute to identify problems
Apply Knowledge: Complete worked examples of routing configuration

687.2 Prerequisites

Routing Basics: Understanding router operation
Routing Tables: Route types and structures
IoT Routing: IoT-specific challenges

687.3 End-to-End Connectivity Requirements

687.3.1 Three Essential Components

For IoT devices to communicate globally, you need:

%%{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
    subgraph Components["End-to-End Connectivity"]
        ADDR[1. Global Addressing<br/>IPv6 addresses<br/>Unique identifiers]
        ROUTE[2. Routing Mechanism<br/>RPL protocol<br/>Multi-hop forwarding]
        CONST[3. IoT Constraints<br/>Low power<br/>Limited resources]
    end

    IOT[IoT Device] --> ADDR
    ADDR --> ROUTE
    ROUTE --> CONST
    CONST --> CLOUD[Cloud Server]

    style IOT fill:#E67E22,stroke:#2C3E50,stroke-width:3px,color:#fff
    style CLOUD fill:#16A085,stroke:#2C3E50,stroke-width:3px,color:#fff
    style ADDR fill:#2C3E50,stroke:#16A085,stroke-width:2px,color:#fff
    style ROUTE fill:#2C3E50,stroke:#16A085,stroke-width:2px,color:#fff
    style CONST fill:#2C3E50,stroke:#16A085,stroke-width:2px,color:#fff

Figure 687.1: Three essential components for IoT end-to-end connectivity

687.3.2 1. Global Addressing

Unique identifiers for every device: - IPv6 addresses (128-bit) - Globally routable - No NAT complications

687.3.3 2. Routing Mechanism

Transfer information between endpoints: - Routing protocols (RPL for IoT) - Path discovery - Multi-hop forwarding

687.3.4 3. IoT Constraints Handling

Deal with limited resources: - Reduced computation capabilities - Small message sizes - Limited energy (battery-powered) - Lossy wireless links

Show code

{
  const container = document.getElementById('kc-route-conn-1');
  if (container && typeof InlineKnowledgeCheck !== 'undefined') {
    container.innerHTML = '';
    container.appendChild(InlineKnowledgeCheck.create({
      question: "An IoT deployment requires end-to-end connectivity from battery-powered sensors to a cloud server. The sensors use IPv6 over 6LoWPAN. Which combination of components is essential for this connectivity?",
      options: [
        {text: "NAT gateway + RIP routing + TCP transport", correct: false, feedback: "NAT is typically not used with IPv6 since it provides abundant address space. RIP is inefficient for constrained IoT devices. While TCP can work, the combination doesn't address IoT-specific constraints."},
        {text: "Global IPv6 addresses + RPL routing + CoAP application protocol", correct: true, feedback: "Correct! Global IPv6 addresses enable direct addressability without NAT. RPL provides energy-efficient routing for constrained devices. CoAP is designed for IoT with low overhead, making this combination ideal for battery-powered sensors."},
        {text: "Private IPv4 + OSPF routing + HTTP transport", correct: false, feedback: "Private IPv4 requires NAT for internet connectivity, adding complexity. OSPF is too resource-intensive for constrained devices. HTTP has high overhead compared to IoT-optimized protocols."},
        {text: "MAC addresses only + static routes + raw sockets", correct: false, feedback: "MAC addresses don't provide end-to-end internet routing - they only work on local networks. Global connectivity requires IP addressing and a routing mechanism."}
      ],
      difficulty: "hard",
      topic: "routing"
    }));
  }
}

687.4 Worked Example: Configuring Static Routes for IoT Gateway

Worked Example: Configuring Static Routes for an IoT Gateway

Scenario: You are configuring an IoT gateway that connects three network segments: a sensor network (internal), a management network (internal), and the internet (via ISP). The gateway needs static routes to ensure sensors can reach the cloud while management traffic stays local.

Given: - Gateway interfaces: - eth0: 192.168.1.1/24 (sensor network - 50 temperature sensors) - eth1: 10.0.0.1/24 (management network - admin workstations) - eth2: 203.0.113.5/30 (ISP uplink, gateway 203.0.113.6) - Cloud server: 198.51.100.50 (via ISP) - Internal MQTT broker: 10.0.0.100 (on management network) - Requirement: Sensors reach cloud; management stays internal

Steps:

Step 1: Identify the routing requirements

Traffic Flow Analysis:
- Sensors (192.168.1.x) -> Cloud (198.51.100.50): via eth2 to ISP
- Sensors (192.168.1.x) -> MQTT (10.0.0.100): via eth1 to management
- Management (10.0.0.x) -> Sensors (192.168.1.x): via eth0
- All other traffic -> Internet via default route

Step 2: Configure connected routes (automatic)

Destination        Gateway         Interface    Type
192.168.1.0/24     0.0.0.0         eth0         Connected
10.0.0.0/24        0.0.0.0         eth1         Connected
203.0.113.4/30     0.0.0.0         eth2         Connected

Step 3: Add static route for cloud server

# Route to cloud server via ISP
ip route add 198.51.100.50/32 via 203.0.113.6 dev eth2

# Or as a network route for entire cloud subnet
ip route add 198.51.100.0/24 via 203.0.113.6 dev eth2

Step 4: Configure default route for internet access

# Default route - all unknown destinations via ISP
ip route add default via 203.0.113.6 dev eth2

Step 5: Verify final routing table

Destination        Gateway         Interface    Metric
192.168.1.0/24     0.0.0.0         eth0         0 (connected)
10.0.0.0/24        0.0.0.0         eth1         0 (connected)
203.0.113.4/30     0.0.0.0         eth2         0 (connected)
198.51.100.0/24    203.0.113.6     eth2         100 (static)
0.0.0.0/0          203.0.113.6     eth2         200 (default)

Result: Sensors can reach both the local MQTT broker (via directly connected route to management network) and the cloud server (via static route through ISP). Management workstations can access sensors directly.

Key Insight: Connected routes are automatically created when you assign an IP address to an interface. Static routes override the default route for specific destinations, enabling traffic engineering.

687.5 Worked Example: Diagnosing a Routing Loop

Worked Example: Diagnosing a Routing Loop with TTL Analysis

Scenario: An IoT sensor mesh network is experiencing packet loss. Sensors report that some data never reaches the gateway, and the gateway logs show “TTL exceeded” ICMP messages. You need to diagnose and fix the routing loop.

Given: - Network topology: 5 sensors in a mesh, 1 gateway - Routing protocol: Static routes (configured manually) - Initial TTL: 64 (Linux default) - Symptom: Packets from Sensor E never reach gateway - ICMP log shows TTL=0 discards from Router C

Steps:

Step 1: Analyze the path using traceroute

$ traceroute 192.168.1.1 (gateway)
1  192.168.5.1 (Router B)   2ms
2  192.168.4.1 (Router C)   3ms
3  192.168.5.1 (Router B)   4ms   <- Loop detected!
4  192.168.4.1 (Router C)   5ms
5  192.168.5.1 (Router B)   6ms
... (continues until TTL expires)
30 * * * (TTL exceeded, packet dropped)

Step 2: Examine routing tables on the looping routers

Router B routing table:
Destination        Next Hop        Interface
192.168.1.0/24     192.168.4.1     eth0    <- Points to Router C
0.0.0.0/0          192.168.4.1     eth0

Router C routing table:
Destination        Next Hop        Interface
192.168.1.0/24     192.168.5.1     eth0    <- Points BACK to Router B!
0.0.0.0/0          192.168.5.1     eth0    <- MISCONFIGURED

Step 3: Identify the root cause

Problem: Router C's default route points to Router B instead of gateway

Correct path should be:
Sensor E -> Router B -> Router C -> Router A -> Gateway

Current (broken) path:
Sensor E -> Router B -> Router C -> Router B -> Router C -> ... (loop)

Step 4: Fix the routing configuration

# On Router C - correct the default route
ip route del default via 192.168.5.1

# Add correct route to gateway via Router A
ip route add default via 192.168.3.1 dev eth1

Step 5: Verify the fix

$ traceroute 192.168.1.1
1  192.168.5.1 (Router B)   2ms
2  192.168.4.1 (Router C)   3ms
3  192.168.3.1 (Router A)   4ms
4  192.168.1.1 (Gateway)    5ms   <- Success!

Result: After correcting Router C’s default route, packets from Sensor E reach the gateway successfully in 4 hops.

Key Insight: TTL (Time-To-Live) is the network’s safety mechanism against routing loops. When you see “TTL exceeded” errors, use traceroute to identify where packets start repeating. Routing loops almost always result from misconfigured static routes or slow convergence in dynamic routing protocols.

687.6 Summary: Complete Routing Fundamentals

687.6.1 Key Concepts Covered

Routing Implementation: Routing is the network layer process that implements packet switching through forwarding decisions based on destination IP addresses
Router Decision Process: Routers make one of three decisions for each packet: forward to specific next hop, forward to default gateway, or drop packet
Time-To-Live (TTL): TTL field in IP headers prevents infinite routing loops by decrementing at each hop and dropping packets when TTL reaches zero
Route Types: Connected routes (automatically added), static routes (manually configured), and dynamic routes (learned via protocols) serve different network scenarios
Routing Table Structure: Each route contains destination network/prefix, next hop IP address, and outbound interface for forwarding decisions
Protocol Classification: Distance-vector (RIP, RPL), link-state (OSPF), and path-vector (BGP) protocols trade complexity for scalability and convergence speed
IoT-Specific Routing: RPL (Routing Protocol for Low-Power and Lossy Networks) optimizes for energy efficiency, lossy wireless links, and resource-constrained devices through DODAG topology

687.6.2 Quick Reference: When to Use Each Route Type

Scenario	Route Type	Protocol
Single gateway, static topology	Static	None
Small network (<15 hops)	Dynamic	RIP
Enterprise campus	Dynamic	OSPF
Battery-powered sensors	Dynamic	RPL
Internet connectivity	Dynamic	BGP
Mission-critical, sub-second failover	Dynamic	OSPF + BFD

687.6.3 Troubleshooting Checklist

When routing fails: 1. Check if default route is configured 2. Verify interface is UP and has correct IP 3. Use traceroute to find where packets stop 4. Check for TTL exceeded errors (routing loop) 5. Verify routing table has expected entries 6. Check for route flapping in logs

687.7 What’s Next

You have completed the Routing Fundamentals series. Next steps:

RPL Fundamentals: Deep dive into IoT-specific routing with RPL
Routing Labs and Quiz: Hands-on practice with Cisco Packet Tracer
Network Topologies: Understanding how topology affects routing design

Return to the Routing Fundamentals Overview for the complete chapter guide.