684  Routing Tables and Route Types

684.1 Learning Objectives

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

• Configure Routing Tables: Work with routing table entries and next hops
• Differentiate Route Types: Distinguish between connected, static, and dynamic routes
• Apply Longest Prefix Match: Understand how routers select the most specific route
• Compare Routing Protocols: Know when to use RIP, OSPF, RPL, or BGP

684.2 Prerequisites

• Routing Basics: Understanding router operation and forwarding decisions
• TTL and Loop Prevention: How TTL prevents routing loops

---

684.3 Routing Tables: The Router’s Map

684.3.1 Structure of a Route

Every route in a routing table has THREE parts:

%%{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 LR
    Route[Route Entry]
    Dest[1. Destination<br/>Network/Prefix<br/>192.168.1.0/24]
    Next[2. Next Hop<br/>IP Address<br/>10.0.0.2]
    IF[3. Outbound<br/>Interface<br/>eth1]

    Route --> Dest
    Route --> Next
    Route --> IF

    style Route fill:#E67E22,stroke:#2C3E50,stroke-width:3px,color:#fff
    style Dest fill:#16A085,stroke:#2C3E50,stroke-width:2px,color:#fff
    style Next fill:#16A085,stroke:#2C3E50,stroke-width:2px,color:#fff
    style IF fill:#16A085,stroke:#2C3E50,stroke-width:2px,color:#fff

Figure 684.1: Three essential components of a routing table entry: destination network, next hop IP, and outbound interface

684.3.2 Example Routing Table

Destination Network	Next Hop	Interface	Metric	Type
192.168.1.0/24	Connected	eth0	0	C
10.0.0.0/8	Connected	eth1	0	C
172.16.0.0/16	10.0.0.2	eth1	10	S
192.168.50.0/24	10.0.0.5	eth1	20	D
0.0.0.0/0 (default)	192.168.1.1	eth0	1	S

Legend: - C = Connected route - S = Static route - D = Dynamic route (learned via protocol)

684.3.3 Reading a Route Entry

Example route:

Destination: 172.16.0.0/16
Next Hop: 10.0.0.2
Interface: eth1

Interpretation: - To reach network 172.16.0.0/16 - Send packets to router 10.0.0.2 - Out of interface eth1

{
  const container = document.getElementById('kc-route-tables-1');
  if (container && typeof InlineKnowledgeCheck !== 'undefined') {
    container.innerHTML = '';
    container.appendChild(InlineKnowledgeCheck.create({
      question: "A router has two routes: 192.168.0.0/16 via Router A, and 192.168.1.0/24 via Router B. A packet arrives destined for 192.168.1.50. Which route is selected?",
      options: [
        {text: "192.168.0.0/16 via Router A because it was added first", correct: false, feedback: "Route selection is not based on insertion order. The longest prefix match rule determines which route is selected based on specificity of the network prefix."},
        {text: "192.168.1.0/24 via Router B because it is the longest prefix match", correct: true, feedback: "Correct! The longest prefix match algorithm selects the most specific route. /24 (24 bits) is more specific than /16 (16 bits). Both routes match 192.168.1.50, but /24 matches more bits of the destination address, so Router B is selected."},
        {text: "Both routes are used for load balancing", correct: false, feedback: "Load balancing only occurs when multiple routes to the SAME destination have EQUAL metrics. These routes have different prefix lengths, so one is clearly more specific and will be selected."},
        {text: "The packet is dropped because multiple routes create ambiguity", correct: false, feedback: "Multiple matching routes are normal and expected. The longest prefix match rule resolves any ambiguity by always selecting the most specific (longest prefix) route."}
      ],
      difficulty: "medium",
      topic: "routing"
    }));
  }
}

---

684.4 Worked Example: Longest Prefix Match

NoteWorked Example: Packet Forwarding Decision

Context: An IoT gateway router receives a packet from a temperature sensor destined for a cloud analytics server. The router must decide where to forward the packet.

Given Information:

Incoming Packet: - Source IP: 192.168.1.50 (temperature sensor) - Destination IP: 192.168.1.100 (cloud server)

Router’s Routing Table:

Entry	Destination	Prefix Length	Next Hop	Interface
1	0.0.0.0	/0 (default)	10.0.0.1	eth0
2	192.168.0.0	/16	10.0.0.2	eth1
3	192.168.1.0	/24	10.0.0.3	eth2
4	192.168.1.64	/26	10.0.0.4	eth3

Problem: Which route should the router use to forward this packet?

---

Solution - Step 1: Convert Destination IP to Binary

First, convert 192.168.1.100 to binary:

192.168.1.100 in binary:
192 = 11000000
168 = 10101000
  1 = 00000001
100 = 01100100

Full address: 11000000.10101000.00000001.01100100

---

Solution - Step 2: Check Each Route for a Match

Entry 1 - Default Route (0.0.0.0/0): - Prefix length: /0 (matches 0 bits - matches everything) - Result: MATCH (but only 0 bits matched)

Entry 2 - (192.168.0.0/16): - Compare first 16 bits - Destination: 11000000.10101000 - Route: 11000000.10101000 - Result: MATCH (16 bits matched)

Entry 3 - (192.168.1.0/24): - Compare first 24 bits - Destination: 11000000.10101000.00000001 - Route: 11000000.10101000.00000001 - Result: MATCH (24 bits matched)

Entry 4 - (192.168.1.64/26): - 192.168.1.64/26 covers addresses 192.168.1.64 to 192.168.1.127 - 192.168.1.100 falls within this range! - Result: MATCH (26 bits matched)

---

Solution - Step 3: Apply Longest Prefix Match Rule

All four routes match! Now apply the Longest Prefix Match algorithm:

Entry	Route	Prefix Length	Match?
1	0.0.0.0/0	0 bits	Yes
2	192.168.0.0/16	16 bits	Yes
3	192.168.1.0/24	24 bits	Yes
4	192.168.1.64/26	26 bits	Yes

Winner: Entry 4 (192.168.1.64/26) with 26 matching bits

---

Final Answer:

Forward packet to: 10.0.0.4
Via interface: eth3
Reason: Longest prefix match (/26 > /24 > /16 > /0)

Why Longest Prefix Match Matters:

1. Specificity: More specific routes (longer prefixes) override general ones
2. Hierarchy: Allows network engineers to create layered routing policies
3. Default Routes: The /0 route acts as a “catch-all” for unknown destinations
4. Aggregation: Smaller networks can be summarized into larger prefixes

---

684.5 Three Types of Routes

684.5.1 Connected Routes (Automatically Added)

%%{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
    Router[Router]
    IF1[eth0<br/>192.168.1.1/24<br/>UP]
    IF2[eth1<br/>10.0.0.1/8<br/>UP]

    RT[Routing Table:<br/>192.168.1.0/24 -> Direct eth0<br/>10.0.0.0/8 -> Direct eth1]

    N1[Network<br/>192.168.1.0/24]
    N2[Network<br/>10.0.0.0/8]

    Router --- IF1
    Router --- IF2
    Router --> RT
    IF1 <--> N1
    IF2 <--> N2

    style Router fill:#E67E22,stroke:#2C3E50,stroke-width:3px,color:#fff
    style RT fill:#16A085,stroke:#2C3E50,stroke-width:2px,color:#fff
    style IF1 fill:#2C3E50,stroke:#16A085,stroke-width:2px,color:#fff
    style IF2 fill:#2C3E50,stroke:#16A085,stroke-width:2px,color:#fff
    style N1 fill:#ecf0f1,stroke:#2C3E50,stroke-width:2px,color:#2C3E50
    style N2 fill:#ecf0f1,stroke:#2C3E50,stroke-width:2px,color:#2C3E50

Figure 684.2: Connected routes: automatically added when interfaces are configured and enabled

Connected routes are: - Listed automatically when interface is configured with IP address - Added when interface is enabled and connected - Removed when interface goes down

No manual configuration needed!

684.5.2 Static Routes (Manually Configured)

%%{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 LR
    Admin[Network Admin<br/>Manual Config]
    R1[Router 1]
    R2[Router 2]
    Remote[Remote Network<br/>172.16.0.0/16]

    Admin -->|Configure:<br/>172.16.0.0/16 via R2| R1
    R1 <-->|Link| R2
    R2 <--> Remote

    style Admin fill:#E67E22,stroke:#2C3E50,stroke-width:3px,color:#fff
    style R1 fill:#2C3E50,stroke:#16A085,stroke-width:2px,color:#fff
    style R2 fill:#2C3E50,stroke:#16A085,stroke-width:2px,color:#fff
    style Remote fill:#16A085,stroke:#2C3E50,stroke-width:2px,color:#fff

Figure 684.3: Static routes: manually configured by network administrator, fixed unless updated manually

Static routes: - Configured manually by network engineer - Used on small networks with stable topology - Don’t change unless manually updated - Low overhead (no protocol messages)

Advantages: - Predictable paths - No bandwidth/CPU for routing protocols - Secure (no dynamic updates)

Disadvantages: - Manual configuration required - No automatic failover - Difficult to scale to large networks

IoT Use Case: - Simple sensor network with fixed gateway - Remote monitoring station with single WAN link - Small building automation system

{
  const container = document.getElementById('kc-route-tables-2');
  if (container && typeof InlineKnowledgeCheck !== 'undefined') {
    container.innerHTML = '';
    container.appendChild(InlineKnowledgeCheck.create({
      question: "A small IoT deployment has 5 sensors connected to a single gateway with a fixed internet connection. The network topology never changes. Which route type is MOST appropriate?",
      options: [
        {text: "Dynamic routes using OSPF for fast convergence", correct: false, feedback: "OSPF is overkill for a small, static network. It consumes CPU and bandwidth for hello packets and LSA flooding, which provides no benefit when the topology never changes."},
        {text: "Static routes for simplicity and low overhead", correct: true, feedback: "Correct! Static routes are ideal for small, stable networks. With only 5 sensors and a fixed gateway, there's no need for dynamic routing overhead. Static routes require no protocol messages and provide predictable, deterministic paths."},
        {text: "Dynamic routes using RIP for automatic failover", correct: false, feedback: "RIP's automatic failover is unnecessary when the topology never changes. The protocol overhead of periodic RIP updates every 30 seconds wastes bandwidth in a simple, static IoT deployment."},
        {text: "No routes needed - sensors can communicate directly", correct: false, feedback: "Even in a simple network, routing is needed to reach the cloud or other networks. The gateway needs a default route to forward sensor data to the internet."}
      ],
      difficulty: "easy",
      topic: "routing"
    }));
  }
}

684.5.3 Dynamic Routes (Learned via Protocols)

%%{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
    R1[Router 1<br/>OSPF Protocol]
    R2[Router 2<br/>OSPF Protocol]
    R3[Router 3<br/>OSPF Protocol]
    R4[Router 4<br/>OSPF Protocol]

    R1 <-->|Exchange<br/>Routes| R2
    R2 <-->|Exchange<br/>Routes| R3
    R3 <-->|Exchange<br/>Routes| R4
    R1 <-->|Exchange<br/>Routes| R4

    style R1 fill:#E67E22,stroke:#2C3E50,stroke-width:3px,color:#fff
    style R2 fill:#16A085,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 684.4: Dynamic routes: routers automatically exchange routing information via protocols like OSPF

Dynamic routes: - Learned automatically from routing protocol messages - Exchange topology information with other routers - Automatically adapt to network changes - Calculate best paths based on metrics

Advantages: - Automatic adaptation to topology changes - Load balancing across multiple paths - Automatic failover - Scales to large networks

Disadvantages: - CPU and bandwidth overhead - Convergence time (delay while learning new routes) - More complex configuration

---

684.6 Routing Protocols

684.6.1 What Are Routing Protocols?

Routing protocols are software used by routers to: 1. Inform each other of network topology changes 2. Exchange routing information 3. Calculate best paths to destination networks

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#ecf0f1', 'noteTextColor': '#2C3E50', 'noteBkgColor': '#f39c12', 'textColor': '#2C3E50', 'fontSize': '16px'}}}%%
flowchart TD
    DETECT[Topology Change<br/>Detected]
    SEND[Send Update<br/>Messages]
    RECV[Neighbors Receive<br/>Updates]
    CALC[Recalculate<br/>Best Paths]
    UPDATE[Update Routing<br/>Tables]
    CONVERGE[Network<br/>Converged]

    DETECT --> SEND
    SEND --> RECV
    RECV --> CALC
    CALC --> UPDATE
    UPDATE --> CONVERGE

    style DETECT fill:#E67E22,stroke:#2C3E50,stroke-width:3px,color:#fff
    style CONVERGE fill:#16A085,stroke:#2C3E50,stroke-width:3px,color:#fff
    style SEND fill:#2C3E50,stroke:#16A085,stroke-width:2px,color:#fff
    style RECV fill:#2C3E50,stroke:#16A085,stroke-width:2px,color:#fff
    style CALC fill:#2C3E50,stroke:#16A085,stroke-width:2px,color:#fff
    style UPDATE fill:#2C3E50,stroke:#16A085,stroke-width:2px,color:#fff

Figure 684.5: Routing protocol operation: topology change detection, information exchange, path calculation, and convergence

684.6.2 Common Routing Protocols

Protocol	Type	Metric	Use Case	IoT Relevance
RIP	Distance Vector	Hop count	Small networks	Legacy, simple
OSPF	Link State	Cost (bandwidth)	Enterprise LANs	Campus IoT networks
EIGRP	Advanced DV	Composite (BW, delay)	Cisco networks	Enterprise IoT
BGP	Path Vector	AS path, policies	Internet backbone	Cloud IoT connectivity
RPL	Distance Vector	Energy, hop count	IoT Low-Power Networks	LoRaWAN, 6LoWPAN

{
  const container = document.getElementById('kc-route-tables-3');
  if (container && typeof InlineKnowledgeCheck !== 'undefined') {
    container.innerHTML = '';
    container.appendChild(InlineKnowledgeCheck.create({
      question: "An enterprise deploys 500 sensors in a campus building with battery-powered Zigbee devices forming a mesh network. The network engineer must choose between OSPF and RPL. Which is more appropriate and why?",
      options: [
        {text: "OSPF because it has faster convergence for enterprise networks", correct: false, feedback: "While OSPF converges faster (seconds vs minutes), it requires frequent hello packets and LSA flooding that would drain batteries quickly. Battery-powered sensors need energy-efficient routing."},
        {text: "OSPF because enterprise networks require link-state protocols", correct: false, feedback: "Network type doesn't dictate protocol choice - constraints do. Battery-powered sensors can't afford OSPF's high control overhead. RPL's distance-vector approach uses minimal energy."},
        {text: "RPL because it optimizes for energy efficiency and lossy wireless links", correct: true, feedback: "Correct! RPL is designed specifically for Low-Power and Lossy Networks (LLNs). It uses adaptive trickle timers to minimize control messages, handles lossy wireless links with ETX metrics, and builds energy-efficient tree topologies (DODAGs)."},
        {text: "Neither - mesh networks don't need routing protocols", correct: false, feedback: "Mesh networks absolutely need routing protocols! With 500 sensors and multi-hop paths, packets must be routed from any sensor to the gateway. RPL provides this capability efficiently."}
      ],
      difficulty: "medium",
      topic: "routing"
    }));
  }
}

684.6.3 Protocol Selection Decision Tree

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#E8F6F3', 'fontSize': '11px'}}}%%
flowchart TD
    START["Select Routing<br/>Protocol"]

    Q1{"Network<br/>environment?"}
    Q2{"Scale of<br/>deployment?"}
    Q3{"Power<br/>constraints?"}

    RIP["RIP<br/>Hop count metric<br/>Max 15 hops<br/>Best for: Small<br/>office networks"]

    OSPF["OSPF<br/>Link-state, fast<br/>convergence<br/>Best for: Enterprise<br/>campus networks"]

    RPL["RPL<br/>Low-power optimized<br/>Lossy link tolerant<br/>Best for: IoT sensors<br/>6LoWPAN, LoRaWAN"]

    START --> Q1
    Q1 -->|"Enterprise<br/>wired/Wi-Fi"| Q2
    Q1 -->|"IoT constrained<br/>wireless"| Q3

    Q2 -->|"Small<br/>(<15 hops)"| RIP
    Q2 -->|"Large<br/>campus"| OSPF

    Q3 -->|"Battery<br/>powered"| RPL
    Q3 -->|"Mains<br/>powered"| OSPF

    style START fill:#2C3E50,stroke:#16A085,color:#fff
    style Q1 fill:#16A085,stroke:#2C3E50,color:#fff
    style Q2 fill:#16A085,stroke:#2C3E50,color:#fff
    style Q3 fill:#16A085,stroke:#2C3E50,color:#fff
    style RIP fill:#7F8C8D,stroke:#2C3E50,color:#fff
    style OSPF fill:#E67E22,stroke:#2C3E50,color:#fff
    style RPL fill:#E67E22,stroke:#2C3E50,color:#fff

Figure 684.6: Routing Protocol Selection Decision Tree - Choose based on network environment, scale, and power constraints

684.6.4 RPL: Routing for Low-Power IoT

RPL (Routing Protocol for Low-Power and Lossy Networks) is designed specifically for IoT:

Features: - Energy-efficient: Minimizes control messages - Supports lossy links: Wireless networks with packet loss - Battery-friendly: Optimizes routing for battery life - Tree topology: DODAG (Destination-Oriented Directed Acyclic Graph)

Used in: - 6LoWPAN networks - Thread (smart home protocol) - Industrial IoT sensor networks

{
  const container = document.getElementById('kc-route-tables-4');
  if (container && typeof InlineKnowledgeCheck !== 'undefined') {
    container.innerHTML = '';
    container.appendChild(InlineKnowledgeCheck.create({
      question: "RPL uses a DODAG (Destination-Oriented Directed Acyclic Graph) topology. A sensor 5 hops from the gateway loses its parent router. What happens according to RPL's design?",
      options: [
        {text: "The sensor immediately floods the network to find a new path", correct: false, feedback: "RPL avoids flooding to conserve energy. Instead, sensors listen for DIO (DODAG Information Object) messages from alternative parents and select a new parent based on rank and metrics."},
        {text: "The sensor selects a new parent from available neighbors with lower rank", correct: true, feedback: "Correct! In RPL's DODAG, each node has a 'rank' indicating distance to the root (gateway). When a parent fails, the sensor selects a new parent from neighbors advertising lower rank, ensuring the path leads toward the gateway without loops."},
        {text: "The sensor stops transmitting until the original parent recovers", correct: false, feedback: "RPL is designed for lossy networks where link failures are common. Sensors maintain backup parent candidates and switch quickly to alternative paths when the primary parent fails."},
        {text: "The gateway recalculates all routes and pushes updates to sensors", correct: false, feedback: "RPL uses distributed route computation, not centralized. Each sensor independently selects parents based on received DIO messages. This distributed approach scales better and doesn't require gateway involvement for local failures."}
      ],
      difficulty: "hard",
      topic: "routing"
    }));
  }
}

---

684.7 Summary

• Routing tables contain destination network, next hop, and outbound interface
• Longest prefix match selects the most specific route for each packet
• Connected routes are automatic; static routes are manual; dynamic routes are learned
• RIP for small networks, OSPF for enterprise, RPL for IoT
• Choose routing protocol based on network size, power constraints, and reliability needs

---

684.8 What’s Next

Continue to Packet Switching and Failover to understand how packets are dynamically rerouted when links fail.