Introduction

After DNS resolves a domain name to an IP address, the sending host must determine where to send packets destined for that address. Routing provides this path-selection and forwarding capability.

Routing is the process of selecting a path through one or more networks so that an IP packet can move from its source toward its destination.

Routing answers questions such as:

• Is the destination directly reachable on the local network?
• Which network interface should carry the packet?
• Which next-hop router should receive the packet?
• Which route is most specific to the destination?
• What happens when several routes are available?
• What happens when a link or router fails?
• Does the return path follow the same route?

In your System Design curriculum, Routing is Topic 3.3 under Networking and Web Request Lifecycle. It follows DNS and precedes TLS, allowing learners to trace how a resolved destination is reached before secure application communication begins.

Prerequisites

Routing and Forwarding

Routing and forwarding are related but distinct concepts.

Routing Table

A routing table contains destination prefixes and information describing where matching packets should be sent.

A route can contain:

• Destination prefix
• Prefix length
• Next-hop address
• Outgoing interface
• Route source
• Metric or preference information
• Scope or protocol-specific attributes

Simplified Routing Table

Directly Connected Destination

When a destination belongs to a directly connected network, the host can send the packet through the local interface without first forwarding it to an IP router.

Host A
Address: 192.0.2.10/24

Destination:
192.0.2.50

Matching connected route:
192.0.2.0/24

Result:
Send through the local interface
toward the destination's link-layer address.

An address-resolution mechanism is normally used to discover the applicable link-layer destination for the local network.

Remote Destination

When the destination is not directly reachable, the host sends the packet to an applicable next-hop router.

Application Host
Address: 192.0.2.10/24
        |
        | Packet for 198.51.100.20
        v
Default Gateway
192.0.2.254
        |
        v
Additional Router or Network
        |
        v
Destination
198.51.100.20

The packet's IP destination remains the final destination. The link-layer destination for the current hop identifies the next local receiver.

Next Hop

A next hop is the next router or directly reachable endpoint to which a packet is forwarded.

Current Router
      |
      | Routing decision
      v
Next-hop Router
      |
      v
Later Hop
      |
      v
Destination Network

Each router repeats the destination lookup using its own routing and forwarding information.

Longest-prefix Matching

Several routing-table entries can match the same destination. The forwarding decision uses the route with the longest matching prefix, meaning the most specific matching destination prefix.

Example

Destination address:
10.20.30.40

Matching routes:

0.0.0.0/0
10.0.0.0/8
10.20.0.0/16
10.20.30.0/24

Selected route:

10.20.30.0/24

Reason:

/24 has the longest matching prefix
and is the most specific route.

Specific vs Broad Route

Default Route

A default route matches destinations for which no more specific route is selected.

IPv4 default route:

0.0.0.0/0


IPv6 default route:

::/0

A client machine commonly uses a default route toward its local gateway. Routers can also use default routes where the network design permits them.

The default route is always selected.

The default route is selected only when
no more specific matching route is used.

Outgoing Interface

The selected route identifies the outgoing interface directly or through a resolvable next-hop relationship.

Route:

198.51.100.0/24
via 192.0.2.1
dev eth0


Destination:

198.51.100.20


Forwarding result:

Next hop: 192.0.2.1
Interface: eth0

A host with several interfaces can use different routes for private networks, public traffic, management communication or virtual networks.

Routing across Several Hops

Client
  |
  | Local default route
  v
Router A
  |
  | Route toward destination prefix
  v
Router B
  |
  | More specific route
  v
Router C
  |
  | Directly connected destination network
  v
Server

Each router usually knows the appropriate next hop, not necessarily the complete end-to-end path that the packet will take.

Autonomous Systems

The Internet is composed of independently administered networks commonly organized as autonomous systems.

Autonomous System A
        |
        | Inter-domain routing
        v
Autonomous System B
        |
        v
Autonomous System C

Routing within one administrative network is described as intra-domain routing. Routing between autonomous systems is described as inter-domain routing.

Static vs Dynamic Routing

Static Routes

A static route explicitly identifies a destination and forwarding action.

sudo ip route add 198.51.100.0/24 via 192.0.2.1 dev eth0

The exact command applies a runtime route on an applicable Linux system. Persistent network configuration depends on the distribution and network management system.

Static routes are useful when:

• The topology is small and stable
• A controlled default gateway is required
• A specific network must use an explicit next hop
• A temporary diagnostic override is required
• A dynamic protocol is unnecessary

Dynamic Routing Protocols

Dynamic routing protocols exchange reachability information and apply protocol-specific path-selection rules.

OSPF

Open Shortest Path First is an interior routing protocol. Routers exchange topology information and calculate paths within the OSPF routing domain.

OSPF design can include:

• Areas
• Link-state information
• Path costs
• Intra-area routes
• Inter-area routes
• Externally introduced routes

Detailed OSPF configuration is vendor- and topology-specific and belongs to network implementation design rather than application code.

BGP

Border Gateway Protocol exchanges network-prefix reachability and path-related information between routing participants, especially across autonomous-system boundaries.

Network Prefix
      |
      | Announced with routing attributes
      v
Neighboring Routing System
      |
      | Applies policy
      v
Additional Routing Systems

BGP path selection is policy-driven and uses several protocol attributes. It should not be reduced to shortest physical distance.

Route Metrics

A metric expresses a protocol- or implementation-specific preference among candidate routes to the same destination prefix.

Metrics can reflect concepts such as:

• Configured path cost
• Hop-related information
• Link properties
• Routing policy
• Protocol-specific attributes

Equal-cost Multipath

A router can have several equal-cost next hops for one destination prefix. An applicable forwarding implementation can distribute traffic across those paths.

                 +--> Next Hop A --+
Source Router ---+                 +--> Destination
                 +--> Next Hop B --+

Traffic distribution is commonly based on flow-related fields rather than strict packet-by-packet alternation. Exact behaviour depends on the forwarding implementation.

Design considerations include:

• Flow consistency
• Unequal traffic distribution
• Path capacity
• Failure detection
• Stateful middleboxes
• Packet reordering

Symmetric and Asymmetric Routing

Symmetric routing uses the same sequence of network devices in both directions. Asymmetric routing uses different forward and return paths.

Symmetric:

Client -> Router A -> Router B -> Server
Client <- Router A <- Router B <- Server


Asymmetric:

Client -> Router A -> Router B -> Server
Client <- Router C <- Router D <- Server

Asymmetric routing can be valid, but it can affect:

• Stateful firewalls
• Network address translation
• Packet capture interpretation
• Different one-way latency
• Troubleshooting across independent paths

Network Address Translation

Network Address Translation, or NAT, changes selected address or port information as traffic crosses a translation boundary.

Private Client
10.0.0.20:50000
      |
      v
NAT Device
      |
      | Translated source
      v
Public Address
192.0.2.100:61000
      |
      v
Remote Server

The NAT device maintains translation state so response traffic can be associated with the internal endpoint.

NAT considerations include:

• Translation-table capacity
• Port availability
• Idle timeouts
• Stateful return paths
• Inbound reachability
• Logging and troubleshooting

Routing vs Firewall Policy

Routing determines where traffic should be forwarded. A firewall or network policy determines whether applicable traffic is permitted.

A valid route does not prove that traffic is allowed, and an allow rule does not create a missing route.

Policy-based Routing

Traditional destination-based routing primarily selects paths from the destination address. Policy-based designs can choose paths using additional packet or context information.

Policy inputs can include:

• Source address
• Incoming interface
• Packet marks
• Traffic class
• Administrative policy

Policy-based routing adds flexibility but also increases troubleshooting complexity because identical destinations can use different paths.

Multiple Routing Tables

Linux can use routing-policy rules to select among several routing tables.

ip rule show
ip route show table all

A troubleshooting session should not assume that the main routing table is the only source of path selection.

Time to Live and Hop Limit

IPv4 uses a Time to Live field and IPv6 uses a Hop Limit field to restrict how long a packet can continue through forwarding hops.

Initial hop limit: 4

Router A forwards: 3
Router B forwards: 2
Router C forwards: 1
Router D would reduce to 0

Packet is discarded instead of circulating forever.

This mechanism limits the effect of forwarding loops. It does not prevent a routing loop from existing.

Routing Loops

A routing loop occurs when routers repeatedly forward a packet through a cycle instead of moving it toward the destination.

Router A -> Router B -> Router C
    ^                     |
    |                     v
    +---------------------+

Routing loops can cause:

• Packet loss after hop-limit exhaustion
• Unnecessary bandwidth consumption
• High latency
• Repeated traffic across the same links
• Service unreachability

Black Holes

A routing black hole occurs when traffic is forwarded into a path where it is silently discarded or cannot reach the destination.

Source
  |
  v
Router A
  |
  | Route exists
  v
Router B
  |
  | Missing or invalid onward path
  v
Packet discarded

Black-hole behaviour can result from incomplete routes, failed tunnels, incorrect filtering, broken next hops or intentional discard routes.

Route Convergence

Convergence is the process through which routing participants reach an updated, consistent view after a topology or reachability change.

Link fails
   |
   v
Failure detected
   |
   v
Routing information updated
   |
   v
Alternative route selected
   |
   v
Forwarding state updated

During convergence, traffic can experience temporary loss, loops, suboptimal paths or inconsistent forwarding, depending on the routing system and failure.

Route Failure and Failover

Redundant links do not guarantee immediate or successful failover. The design must consider:

• Failure detection
• Route withdrawal
• Alternative-path availability
• Convergence behaviour
• Remaining path capacity
• Stateful network devices
• Return-path consistency
• Application timeouts and retries

Routing in Cloud Networks

Cloud virtual networks commonly provide routing tables that map destination prefixes to virtual gateways, network interfaces, peering connections, translation services or other supported targets.

Application Subnet
        |
        | Virtual route table
        v
Selected Target
        |
        +--> Local virtual network
        +--> Peered network
        +--> Private gateway
        +--> Internet-facing gateway
        +--> Translation service

Cloud routing must be considered together with security rules, subnet boundaries, gateways, peering configuration and managed-service behaviour.

Routing and Load Balancers

Routing and load balancing operate at different decision boundaries.

A request can pass through several routers before reaching a load balancer, after which another routing decision carries traffic toward the selected backend.

Routing in the Web Request Lifecycle

User enters URL
      |
      v
DNS resolves hostname
      |
      v
Client obtains destination address
      |
      v
Client selects local route
      |
      v
Packet reaches default gateway
      |
      v
Routers forward packet across networks
      |
      v
Destination network receives packet
      |
      v
TCP or UDP transport processing
      |
      v
TLS and application protocol continue

DNS selects or returns candidate destination addresses. Routing determines how packets travel toward the selected address.

Routing and Latency

End-to-end network latency can include propagation, transmission, queueing and processing delays at several hops.

\[ L_{network} = \sum_{i=1}^{n} \left( L_{propagation,i} + L_{transmission,i} + L_{queueing,i} + L_{processing,i} \right) \]

More hops do not always mean proportionally greater latency. Physical distance, link capacity, congestion, route quality and device behaviour also matter.

Display Linux Routes

ip route show

Display IPv6 Routes

ip -6 route show

Sample Output

default via 192.0.2.1 dev eth0
192.0.2.0/24 dev eth0 proto kernel scope link src 192.0.2.10
198.51.100.0/24 via 192.0.2.2 dev eth0

The output indicates:

• The default next hop
• The directly connected network
• The selected outgoing interface
• The preferred source address where shown
• An explicit route to another destination prefix

Determine the Selected Route

ip route get 198.51.100.20

The output can show the selected next hop, interface and source address for the tested destination under the current routing policy.

Test a Source Context

ip route get 198.51.100.20 from 192.0.2.10

Source-aware testing is useful when policy rules or multiple network interfaces can affect route selection.

Display Routing-policy Rules

ip rule show

Display All Route Tables

ip route show table all

Display Interfaces and Addresses

ip link show
ip address show

A route referring to a disabled interface, missing address or unavailable next hop cannot provide the expected communication path.

Test Reachability

ping -c 4 198.51.100.20

A successful response provides evidence that the applicable diagnostic traffic completed a round trip. It does not prove that a TCP port, TLS endpoint or application is healthy.

tracepath and traceroute

Route-tracing tools send probes with controlled hop limits to observe responses from intermediate network devices.

tracepath 198.51.100.20

traceroute 198.51.100.20

These tools can help identify:

• Intermediate responding hops
• Unexpected path changes
• Where diagnostic responses stop
• Large latency changes between observed hops
• Potential path-MTU information

Test the Application Destination

nc -vz 198.51.100.20 443

curl -v https://example.com/

These tests move beyond IP reachability to transport or application-level communication.

Packet Capture

Capture Traffic to a Destination

sudo tcpdump -i any -nn host 198.51.100.20

Capture ICMP Traffic

sudo tcpdump -i any -nn icmp

Capture IPv6 Control Traffic

sudo tcpdump -i any -nn icmp6

Packet capture can show whether packets leave the expected interface and whether responses return. Capture only in approved environments because network traces can expose sensitive metadata and payloads.

Routing Troubleshooting Workflow

1. Confirm the destination name and resolved address.
2. Identify the source host and expected source address.
3. Use ip route get to inspect the selected route.
4. Verify that the selected interface is operational.
5. Verify local address and prefix configuration.
6. Check whether the next hop is reachable.
7. Inspect policy-routing rules and alternate routing tables.
8. Trace the path through the network.
9. Check firewall, NAT and security policies separately.
10. Test the destination port and application protocol.
11. Capture packets when lighter evidence is insufficient.
12. Compare the forward and return paths where possible.

Scenario: No Route to Destination

ip address show
ip route show
ip rule show
ip route get 198.51.100.20
ping -c 4 192.0.2.1

Investigate:

• Whether a matching route exists
• Whether the default route is present
• Whether the selected interface is active
• Whether the configured source address is valid
• Whether the next hop is directly reachable
• Whether policy routing selects another table

Scenario: Destination Is Slow

ping -c 10 198.51.100.20
tracepath 198.51.100.20
traceroute 198.51.100.20
curl -o /dev/null -sS \
  -w 'connect=%{time_connect}\ntls=%{time_appconnect}\ntotal=%{time_total}\n' \
  https://example.com/

Investigate:

• Round-trip changes
• Packet loss
• Unexpected route changes
• Network congestion
• Connection establishment delay
• TLS and application processing separately
• Differences between forward and return paths

Scenario: Works from One Host Only

Compare the affected and working hosts:

ip address show
ip route show
ip rule show
ip route get DESTINATION_ADDRESS
cat /etc/resolv.conf
ss -tn

Compare:

• Resolved destination addresses
• Source addresses
• Routing tables
• Policy-routing rules
• Default gateways
• Network namespaces
• Firewall and security policies
• Proxy or VPN configuration

Routing Security Risks

Routing-related risks include:

• Unauthorized route announcements
• Route leaks
• Incorrectly broad route propagation
• Traffic interception or redirection
• Black-hole routes
• Unprotected routing sessions
• Incorrect cloud route-table changes
• Overly permissive network paths

Defensive controls can include:

• Route filtering
• Prefix and maximum-length policies
• Routing-session authentication where supported
• Least-privilege administration
• Change review and rollback
• Monitoring route announcements and withdrawals
• Validating expected route origins where supported
• Alerting on unexpected path changes

Important Routing Metrics

Common Routing Mistakes

Recommended Test Cases

Routing Best Practices

Practice Exercise

Trace the route from a Linux client to an approved web endpoint and connect the routing evidence to DNS, TCP and application behaviour.

Tasks

1. Resolve the endpoint's A and AAAA records.
2. Record the selected destination address.
3. Display the client's interfaces and addresses.
4. Display the main routing table.
5. Display policy-routing rules.
6. Use ip route get for the selected destination.
7. Record the selected source address, interface and next hop.
8. Test next-hop reachability.
9. Run a path trace toward the destination.
10. Test the destination TCP port.
11. Complete an HTTPS request.
12. Capture selected packets in an approved environment.
13. Compare application latency with the observed network path.
14. Document one failure scenario and expected failover behaviour.

Result Template

Destination name:
<Fully qualified domain name>

Resolved address:
<Selected IPv4 or IPv6 address>

Source address:
<Address selected by the host>

Selected route:
<Destination prefix>

Outgoing interface:
<Interface name>

Next hop:
<Gateway or directly connected result>

Policy rule:
<Rule and route table used>

Observed hops:
<Trace result>

Transport result:
<Connection success or failure>

Application result:
<HTTP or service response>

Packet-capture evidence:
<Observed outgoing and returning traffic>

Failure scenario:
<Link, route, next-hop or endpoint failure>

Expected recovery:
<Failover, timeout or controlled failure>

Conclusion:
<Evidence-based explanation>

Frequently Asked Questions