696  Routing Review: Advanced Configuration

This chapter focuses on practical routing configuration for production IoT deployments:

  • Redundant paths for high availability
  • Floating static routes for automatic failover
  • Router forwarding decisions step-by-step
  • Default routes for internet connectivity

These are the skills you need to configure and troubleshoot real IoT gateway routing.

If you need foundational routing concepts first, see: - Routing Review: Longest Prefix Matching - Route selection basics - Routing Review: Convergence and Loop Prevention - Protocol behavior

696.1 Learning Objectives

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

  • Configure Redundant Paths: Set up primary and backup routes for high availability
  • Implement Floating Static Routes: Use metrics for automatic failover
  • Trace Forwarding Decisions: Debug router behavior step-by-step
  • Design Gateway Routing: Plan routing tables for IoT deployments

696.2 Prerequisites

Required Chapters: - Routing Review: Longest Prefix Matching - Routing Review: Convergence and Loop Prevention

Technical Background: - Static route configuration - Routing table structure - Default gateway concepts

Estimated Time: 35 minutes

696.3 Redundant Path Configuration

Scenario: You’re deploying a critical industrial IoT system monitoring a chemical plant. The system must maintain 99.9% uptime to send real-time alerts about temperature and pressure anomalies. Your IoT gateway has two available paths to the cloud:

  • Primary Path: Via fiber connection through Router A - 10 hops, 5ms latency, $100/month
  • Backup Path: Via LTE cellular through Router B - 15 hops, 25ms latency, $500/month with per-GB charges

You need the backup path to activate automatically only when the primary fails (not for load balancing), then automatically fail back when primary recovers.

Think about: 1. How can you configure both paths so the backup stays dormant until needed? 2. What routing mechanism prevents the router from load balancing across both paths? 3. How will the router detect when to switch between paths?

Key Insight: Floating static routes solve this with metric-based priority. Configure primary route with low metric (10) and backup with high metric (100). Router installs only the lowest-metric route. When primary interface fails, primary route disappears, backup route (now lowest) automatically installs. When primary recovers, its lower metric reclaims the active slot. Typical failover time: 1-5 seconds.

Configuration:

# IoT Gateway routing configuration
# Primary route (preferred, low metric)
ip route 0.0.0.0 0.0.0.0 192.168.1.1 10

# Backup route (standby, high metric)
ip route 0.0.0.0 0.0.0.0 192.168.2.1 100

Routing Table States:

Normal Operation (Primary UP):
Destination    Gateway       Metric  Status
0.0.0.0/0      192.168.1.1   10      ACTIVE
0.0.0.0/0      192.168.2.1   100     Not installed (higher metric)

Traffic flows via Router A (fiber)

Primary Fails:
Destination    Gateway       Metric  Status
0.0.0.0/0      192.168.2.1   100     ACTIVE

Traffic automatically switches to Router B (LTE)
Failover time: ~2 seconds

Primary Recovers:
Destination    Gateway       Metric  Status
0.0.0.0/0      192.168.1.1   10      ACTIVE
0.0.0.0/0      192.168.2.1   100     Not installed (higher metric)

Traffic automatically fails back to Router A (fiber)

Why This Matters:

Cost Savings: - Primary fiber: Unlimited data, $100/month flat rate - Backup LTE: $500/month + $50/GB overage charges - Floating static ensures LTE only used during outages (~99 hours/year at 99.9% uptime) - Estimated LTE cost with floating static: $500-600/year (vs $6,000/year if load balanced)

Performance: - Primary: 5ms latency (optimal for real-time alerts) - Backup: 25ms latency (acceptable during emergencies) - Avoid load balancing which would degrade 50% of traffic to 25ms unnecessarily

Verify Your Understanding: - What happens if you set both routes to metric 10? (Equal-cost load balancing - backup used even when not needed) - What’s the failover time if you manually configure routes? (10-30 minutes - too slow for critical systems) - How does the router detect primary link failure? (Interface down event removes connected route, triggering backup installation)

Show Trade-Off Analysis

Floating Static Routes vs Alternatives:

Approach Failover Time Config Complexity Cost Impact Best For
Floating Static 1-5 seconds Low (2 commands) Optimal (backup dormant) Simple dual-path IoT
Equal-Cost Load Balance N/A (always active) Low (2 commands) High (backup always used) Equal-quality paths
Manual Failover 10-30 minutes Low (1 command) Optimal (backup dormant) Non-critical systems
Dynamic Routing (OSPF+BFD) <1 second High (full protocol) Optimal (backup dormant) Enterprise networks

Why Not Equal-Cost Load Balancing?

# WRONG: Both routes with same metric
ip route 0.0.0.0 0.0.0.0 192.168.1.1 10
ip route 0.0.0.0 0.0.0.0 192.168.2.1 10  # Same metric!

Problems:
X Router installs BOTH routes simultaneously
X Traffic split 50/50 across fiber + LTE
X Half of traffic gets 25ms latency (vs 5ms)
X LTE data charges apply to 50% of traffic ($3,000/month extra!)
X Wastes backup capacity when primary is healthy

Why Not Manual Failover?

# WRONG: Only configure primary, manually add backup during outage
ip route 0.0.0.0 0.0.0.0 192.168.1.1

When primary fails:
1. Monitoring system detects failure (5 minutes)
2. Admin receives alert (5 minutes)
3. Admin logs into gateway (5 minutes)
4. Admin runs: ip route 0.0.0.0 0.0.0.0 192.168.2.1
5. Traffic resumes via backup (30 seconds)

Total: 15-20 minutes of downtime

Problems:
X Chemical plant sensors offline for 15+ minutes
X Temperature/pressure alerts not sent to operators
X Safety systems degraded during critical window
X Violates 99.9% uptime SLA (allows only 8.7 hours/year downtime)

Floating Static Route Benefits:

 Automatic failover (1-5 seconds vs 15+ minutes manual)
 Automatic failback when primary recovers
 No routing protocol overhead (no OSPF hellos, LSAs)
 Simple configuration (2 static routes)
 Predictable behavior (lowest metric wins)
 Cost-effective (backup dormant until needed)
 Perfect for IoT gateways with dual uplinks

Real-World Industrial IoT Example:

Oil and Gas Pipeline Monitoring Gateway:
-- Primary: Fiber to operations center (10 hops, 5ms, $100/mo)
-- Backup: Satellite VSAT (25 hops, 600ms, $1,000/mo + $100/GB)
-- Configuration:
   ip route 0.0.0.0 0.0.0.0 192.168.10.1 10   # Fiber (preferred)
   ip route 0.0.0.0 0.0.0.0 192.168.20.1 100  # Satellite (backup)

Normal operation:
- All sensor data via fiber (5ms latency optimal for real-time)
- Satellite link idle (saves $100/GB overage charges)

Fiber outage (rare):
- Automatic failover to satellite in 2 seconds
- Critical pressure/flow alerts still reach operators
- Higher latency acceptable during emergency
- Satellite costs ~$1,200/month during outage (vs $6,000 if always active)

Fiber restoration:
- Automatic failback to fiber
- Latency returns to 5ms optimal
- Satellite link returns to standby

Key Takeaway: Floating static routes provide automatic failover with manual route simplicity - ideal for cost-sensitive IoT deployments with redundant connectivity where backup paths should remain dormant until needed. The metric-based priority ensures predictable behavior without routing protocol complexity.

696.4 Router Forwarding Decisions

Question: A smart factory has deployed 500 sensors across 4 production lines. Each line has its own subnet (192.168.1.0/24, 192.168.2.0/24, 192.168.3.0/24, 192.168.4.0/24) connected to a central router. The router’s routing table has entries for each line subnet plus a default route to the internet gateway (10.0.0.1). A sensor at 192.168.2.50 sends data to a cloud server at 8.8.8.8. What forwarding decision does the router make?

Explanation: This demonstrates router forwarding decision process and default route usage:

From the text - Router Forwarding Decisions:

When a router receives a packet, it makes one of three decisions:

  1. Specific Route Match - Routing table contains route to destination network
  2. Default Route - No specific route found, but default route (0.0.0.0/0) is configured
  3. Drop Packet - No specific route and no default route

Forwarding Decision Process:

Flowchart diagram

Flowchart diagram
Figure 696.1: Router forwarding decision flowchart for smart factory packet destined to 8.8.8.8. Starting with packet arrival (navy box), router sequentially checks four local subnet routes (192.168.1.0/24 through 192.168.4.0/24, shown as teal decision diamonds), finding no matches for each. Router then checks default route 0.0.0.0/0 (orange diamond), which matches and leads to successful forwarding to default gateway 10.0.0.1 (navy box with checkmark). Alternative path shows drop action if no default route exists (orange box with X mark). Arrows show sequential table lookup progression.

This variant shows the routing decision as a prefix-based search, emphasizing how specificity determines the match:

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085'}}}%%
graph TB
    DEST["Destination: 8.8.8.8"]

    subgraph ROUTES["Available Routes (sorted by prefix)"]
        R24["192.168.1.0/24<br/>Prefix: 24 bits"]
        R24B["192.168.2.0/24<br/>Prefix: 24 bits"]
        R0["0.0.0.0/0<br/>Prefix: 0 bits"]
    end

    subgraph MATCH["Match Check"]
        M1["8.8.8.8 in 192.168.1.0/24?<br/>NO - Different subnet"]
        M2["8.8.8.8 in 192.168.2.0/24?<br/>NO - Different subnet"]
        M3["8.8.8.8 in 0.0.0.0/0?<br/>YES - Default matches all"]
    end

    DEST --> R24 --> M1
    DEST --> R24B --> M2
    DEST --> R0 --> M3

    M3 --> RESULT["Forward to 10.0.0.1<br/>(Default Gateway)"]

    style DEST fill:#E67E22,stroke:#2C3E50,color:#fff
    style R24 fill:#7F8C8D,stroke:#2C3E50,color:#fff
    style R24B fill:#7F8C8D,stroke:#2C3E50,color:#fff
    style R0 fill:#16A085,stroke:#2C3E50,color:#fff
    style M1 fill:#7F8C8D,stroke:#2C3E50,color:#fff
    style M2 fill:#7F8C8D,stroke:#2C3E50,color:#fff
    style M3 fill:#16A085,stroke:#2C3E50,color:#fff
    style RESULT fill:#2C3E50,stroke:#16A085,color:#fff

This view emphasizes that routers try specific routes first (higher prefix numbers), then fall back to less specific routes. The default route (0.0.0.0/0) is the least specific and matches all destinations.

This variant presents routing decisions as a matrix showing destination, route matches, and outcomes:

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085'}}}%%
graph LR
    subgraph DEST["Destinations"]
        D1["192.168.1.50<br/>(Local sensor)"]
        D2["192.168.2.100<br/>(Local sensor)"]
        D3["8.8.8.8<br/>(Cloud DNS)"]
        D4["1.1.1.1<br/>(Cloudflare)"]
    end

    subgraph ACTION["Forwarding Action"]
        A1["Forward to eth0<br/>(Direct delivery)"]
        A2["Forward to eth1<br/>(Direct delivery)"]
        A3["Forward to 10.0.0.1<br/>(Default gateway)"]
        A4["Forward to 10.0.0.1<br/>(Default gateway)"]
    end

    D1 --> A1
    D2 --> A2
    D3 --> A3
    D4 --> A4

    style D1 fill:#16A085,stroke:#2C3E50,color:#fff
    style D2 fill:#16A085,stroke:#2C3E50,color:#fff
    style D3 fill:#E67E22,stroke:#2C3E50,color:#fff
    style D4 fill:#E67E22,stroke:#2C3E50,color:#fff
    style A1 fill:#16A085,stroke:#2C3E50,color:#fff
    style A2 fill:#16A085,stroke:#2C3E50,color:#fff
    style A3 fill:#2C3E50,stroke:#16A085,color:#fff
    style A4 fill:#2C3E50,stroke:#16A085,color:#fff

Local destinations (green) go to connected interfaces, while external destinations (orange) go to the default gateway.

Step-by-Step Analysis:

1. Packet arrives at router:

Source:      192.168.2.50 (sensor)
Destination: 8.8.8.8 (Google DNS - cloud server)

2. Router checks routing table:

Destination          Next Hop         Interface  Type
192.168.1.0/24       Connected        eth0       C
192.168.2.0/24       Connected        eth1       C
192.168.3.0/24       Connected        eth2       C
192.168.4.0/24       Connected        eth3       C
0.0.0.0/0            10.0.0.1         eth4       S (default route)

3. Longest Prefix Match: - Check 192.168.1.0/24: Does 8.8.8.8 match? NO - Check 192.168.2.0/24: Does 8.8.8.8 match? NO - Check 192.168.3.0/24: Does 8.8.8.8 match? NO - Check 192.168.4.0/24: Does 8.8.8.8 match? NO - Check 0.0.0.0/0 (default): Does 8.8.8.8 match? YES

4. Default route matches ALL destinations:

# Pseudocode for route matching
def matches_route(dest_ip, route_network, route_prefix):
    if route_network == "0.0.0.0" and route_prefix == 0:
        return True  # Default route matches EVERYTHING
    # Otherwise check if dest_ip is in route_network/prefix
    return ip_in_network(dest_ip, route_network, route_prefix)

matches_route("8.8.8.8", "0.0.0.0", 0)  # Returns True!

5. Forward to next hop: - Forward packet to 10.0.0.1 (default gateway) - Send out interface eth4 (connected to internet gateway) - Default gateway will route to internet

Why Other Options Are Wrong:

A: Forward to 192.168.2.0/24 (local subnet):

Problem: 8.8.8.8 is NOT in 192.168.2.0/24

Check membership:
192.168.2.0/24 covers: 192.168.2.0 - 192.168.2.255
8.8.8.8 is in:         8.0.0.0 - 8.255.255.255

Result: No match! Router won't forward to subnet.

B: Drop the packet (no specific route):

Problem: Router DOES have default route!

Forwarding decision flowchart:
1. Check specific routes -> Not found
2. Check default route -> FOUND!
3. Only drop if NO default route exists

Since default route exists, packet is forwarded (not dropped).

C: CORRECT - Forward to default gateway:

 No specific route to 8.8.8.8
 Default route 0.0.0.0/0 exists
 Forward to next hop: 10.0.0.1
 Internet gateway handles routing to 8.8.8.8

D: Broadcast to all interfaces:

Problem: Routers don't broadcast at Network Layer!

Routers use routing tables for forwarding decisions:
- Layer 2 (switches): Flood/broadcast for MAC learning
- Layer 3 (routers): Never broadcast IP packets
- Routers make intelligent forwarding decisions based on routing table

Broadcasting would:
- Create network storms
- Violate routing principles
- Waste bandwidth on all interfaces

Default Route Behavior:

Default route (0.0.0.0/0) is the “catch-all”:

Specificity hierarchy (longest prefix match):

Most specific:  192.168.2.50/32  (single host)
                192.168.2.0/24   (256 hosts)
                192.168.0.0/16   (65,536 hosts)
                10.0.0.0/8       (16M hosts)
Least specific: 0.0.0.0/0        (ALL hosts - default route)

Router always chooses most specific match.
If no specific match found, uses default route.

Real-World IoT Routing Table:

# Show routing table on IoT gateway
$ route -n

Destination     Gateway         Genmask         Flags Metric Ref  Use Iface
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0      0 eth0
192.168.2.0     0.0.0.0         255.255.255.0   U     0      0      0 eth1
192.168.3.0     0.0.0.0         255.255.255.0   U     0      0      0 eth2
192.168.4.0     0.0.0.0         255.255.255.0   U     0      0      0 eth3
0.0.0.0         10.0.0.1        0.0.0.0         UG    1      0      0 eth4

# Legend:
# U = Route is up
# G = Use gateway (default route)
# Metric = Route cost (lower is better)

Packet Flow:

Step 1: Sensor sends packet
        Source: 192.168.2.50
        Dest: 8.8.8.8

Step 2: Packet arrives at router eth1
        Router: "Where should I forward this?"

Step 3: Check routing table
        "No specific route to 8.8.8.0/24"
        "No specific route to 8.8.0.0/16"
        "No specific route to 8.0.0.0/8"

Step 4: Use default route
        "Found 0.0.0.0/0 -> 10.0.0.1"

Step 5: Forward to gateway
        Next hop: 10.0.0.1
        Out interface: eth4

Step 6: Internet gateway routes to 8.8.8.8
        Packet continues to cloud server

Why Default Routes are Essential for IoT:

Without default route:

Scenario: Sensor needs to reach cloud server

Problem:
- Cloud servers have millions of possible IPs
- Can't store specific route for every internet destination
- Routing table would be enormous
- Manual configuration impossible

Result: Packet dropped (no route to destination)

With default route:

Solution:
- Local subnets: Use specific connected routes
- Everything else: Use default route to internet gateway
- Gateway has more specific routes (BGP from ISP)
- Hierarchical routing reduces table size

Result: Sensor can reach any internet destination

IoT Gateway Configuration:

# Configure default route on IoT gateway
ip route add default via 10.0.0.1 dev eth4 metric 1

# Verify routing table
ip route show

# Expected output:
# default via 10.0.0.1 dev eth4 metric 1
# 192.168.1.0/24 dev eth0 scope link
# 192.168.2.0/24 dev eth1 scope link
# 192.168.3.0/24 dev eth2 scope link
# 192.168.4.0/24 dev eth3 scope link

Configuration Decision Tree:

Graph diagram

Graph diagram
Figure 696.2: IoT gateway routing configuration decision tree starting with gateway needing internet connectivity (navy box). First decision checks if multiple uplinks exist (orange diamond): if yes, leads to floating static routes with primary plus backup configuration (teal box); if no, proceeds to second decision checking cloud connectivity type (orange diamond). General cloud connectivity leads to default route 0.0.0.0/0 configuration (teal box), while specific cloud needs lead to static route using ip route add command (teal box). Tree guides optimal routing strategy selection.

Key Takeaways:

  1. Default routes enable internet connectivity without storing millions of routes
  2. Longest prefix match tries specific routes before default route
  3. Routers never broadcast at Network Layer (only switching does that)
  4. Default gateway is responsible for routing to internet destinations
  5. IoT gateways always need default route for cloud connectivity

696.6 Key Concepts

  • Floating Static Route: Static route with higher metric that activates only when lower-metric route fails
  • Default Route: Catch-all route (0.0.0.0/0) used for any destination without more specific match
  • Connected Route: Automatically created route for subnets directly attached to router interfaces
  • Static Route: Manually configured route; appropriate for small networks and critical infrastructure
  • Failover: Automatic switching to backup path when primary fails
  • Failback: Automatic return to primary path when it recovers
  • Metric: Cost value used to prioritize routes; lower metrics preferred

696.7 Summary

Advanced routing configuration enables reliable IoT deployments:

Floating Static Routes: - Configure primary route with low metric (10) - Configure backup route with high metric (100) - Router automatically uses lowest-metric available route - Failover in 1-5 seconds; automatic failback when primary recovers - Cost-effective: backup only used during outages

Router Forwarding Decisions: 1. Check specific routes in routing table 2. If no match, use default route (0.0.0.0/0) 3. If no default route, drop packet 4. Never broadcast at Network Layer

Default Routes: - Essential for internet connectivity - Match all destinations when no specific route exists - Enable IoT sensors to reach any cloud server - Reduce routing table size dramatically

696.8 Key Takeaways

  • Routing implements packet switching - packets forwarded hop-by-hop to destination
  • Routers examine destination IP in each packet and consult routing table
  • Three forwarding decisions: specific route, default route, or drop packet
  • TTL (Time-To-Live) prevents routing loops by limiting packet lifetime
  • Routing tables contain destination network, next hop, and outbound interface
  • Three route types: Connected (automatic), Static (manual), Dynamic (learned)
  • Routing protocols enable routers to exchange topology information and adapt to changes
  • RPL protocol is designed specifically for low-power IoT networks
  • Dynamic rerouting allows automatic failover when links fail

696.9 What’s Next

Having completed this comprehensive routing review, you’re prepared to explore:

Network Topologies - How physical and logical arrangements of devices affect routing decisions and network scalability

Advanced Routing Protocols - Deep dives into OSPF, BGP, and specialized IoT protocols like RPL and AODV

Network Security - Securing routing infrastructure against attacks like route hijacking, spoofing, and denial-of-service

Quality of Service (QoS) - Prioritizing critical IoT traffic and managing bandwidth allocation across routes

The routing principles covered here - metric-based selection, failover mechanisms, and protocol behavior - form the foundation for designing resilient IoT networks. When you design mesh networks with Zigbee or Thread, configure multi-WAN gateways, or troubleshoot connectivity issues, you’ll apply these routing fundamentals daily.

TipFurther Resources

Interactive Tools: - Cisco Packet Tracer - Simulate routing scenarios - GNS3 - Advanced network simulator

Video Tutorials: - ARP Demonstration - Address Resolution Protocol - Routing Demonstration - Packet Tracer routing

Documentation: - RPL RFC 6550 - IoT routing protocol specification - OSPF Basics

Practice: - Run traceroute to different destinations and analyze paths - Examine routing tables on your home router - Configure static routes in Packet Tracer labs

Continue to: Wired Communication Protocols