A host can deliver a frame directly only across its current link. Reaching an address on another IP network requires one or more routers to forward the packet between links.

No router needs to know the packet's complete path. The sender chooses a first local next hop. Each router then examines the destination IP address, chooses its own next hop, and creates the link-layer frame needed for that one transmission. The process repeats until the packet reaches its destination or a device can no longer forward it.

This hop-by-hop model explains why an IP packet and its enclosing Ethernet frame have different destination addresses, why default gateways are local, why the most specific route wins, and why a working outbound route is not enough without a return path.

The terms routing and forwarding are often used together, but they describe different work.

Routing builds and maintains knowledge about reachable IP prefixes. Connected interfaces, administrator-defined routes, and routing protocols can all contribute information.

Forwarding applies that information to an individual packet. A device reads the destination address, finds the best matching entry, and sends the packet through the selected interface.

The Routing Information Base, or RIB, contains routes considered by the control plane. It can include several candidates for the same prefix.

The Forwarding Information Base, or FIB, contains the selected forwarding entries in a form suited to fast packet lookup. A software router can use optimized prefix trees. High-speed routers and switches can use specialized hardware such as ternary content-addressable memory to compare a destination with many prefixes efficiently.

The distinction matters during failures. A route can appear in a routing protocol's state but fail to reach the FIB. Conversely, an old FIB entry can briefly remain while the control plane reacts to a topology change.

Routing is not limited to dedicated routers. Every IP host needs a routing table to decide whether to deliver locally or use a gateway.

Consider this interface:

A simplified host table is:

For destination 192.0.2.50, the connected /24 route matches. The host treats the destination as on-link and resolves 192.0.2.50 to the link-layer address needed for direct delivery.

For destination 203.0.113.20, the connected route does not match. The default route selects 192.0.2.1 as the next hop. The packet and frame use different destinations:

The gateway must itself be reachable on the local link. Otherwise the host would need another gateway to reach its gateway, leaving the first forwarding step unresolved.

A default gateway is not required to use the first usable address or end in .1. That is a configuration convention, not a protocol rule.

A route associates an IP prefix with a forwarding action. Common sources and roles include the following.

Local Routes

A local route identifies an address owned by the current host. A packet sent to that address is delivered inside the host rather than transmitted on a physical link.

Local routing tables commonly represent owned addresses with /32 for IPv4 and /128 for IPv6:

Connected Routes

Configuring an address and prefix on an interface normally creates a connected route for that network:

The absence of a gateway means destinations in the prefix are directly reachable through that interface.

Static Routes

An administrator can define an explicit path:

Static routes are predictable and useful for stable, simple topologies. They do not discover a replacement path by themselves when the configured next hop becomes unusable.

Dynamically Learned Routes

Routing protocols exchange reachability information and adapt as networks change. The routing system evaluates learned candidates and installs selected routes.

A learned route still becomes an ordinary prefix, next hop, and forwarding action in the FIB. Packet forwarding does not rerun the routing protocol for every packet.

Default Routes

The IPv4 default route fixes zero destination bits:

The IPv6 equivalent is:

Both match every destination in their address family. A default route is the least specific possible match and is used only when no longer matching prefix wins.

The next hop selected by a default route might lead to the public Internet, a corporate backbone, a VPN, or another internal router. “Default” describes fallback behavior, not the type of network beyond it.

Route displays vary across operating systems and network vendors, but an entry commonly carries a destination prefix, a next-hop address or on-link action, an outgoing interface, a metric or preference, and a route source. Flags, lifetimes, and policy context can add more detail.

Consider:

The destination prefix identifies the packets that can match. 198.51.100.2 is the local next hop. wan0 is the outgoing interface. The metric helps choose between eligible routes to the same prefix.

The route does not say that 198.51.100.2 is the final destination. It identifies a neighboring router able to move matching packets closer to 203.0.113.0/24.

An on-link route has no separate gateway:

For this entry, the final destination itself is the local next hop. The sender resolves the destination's link-layer address on lan1.

Several routes can match the same destination. The forwarding decision uses longest-prefix matching: the matching prefix with the greatest length wins.

Consider this simplified table:

The table is abbreviated and assumes each next hop is reachable through its listed interface.

Different destinations select different entries:

The metric on the default route does not compete with the metric on a matching /24. Prefix length is considered first. A more-specific route wins even when it has a numerically higher metric.

This lets a network install a broad aggregate and then add exceptions:

Most of 10.20.0.0/16 uses router A, while addresses inside 10.20.30.0/24 use router B.

For each route, the destination can be tested against its prefix:

A naive implementation could scan every route and retain the longest match. Large forwarding tables require faster structures.

A binary prefix trie walks destination bits from left to right. Every deeper matching node represents a longer prefix. The lookup remembers the last node containing a valid forwarding action.

Hardware forwarding tables can compare masked prefixes in parallel rather than walk a software tree. The implementation changes the lookup speed, not the selection rule: the longest matching prefix remains authoritative.

Longest-prefix matching chooses the most specific destination prefix. A separate decision is needed when several routes exist for that same prefix.

Suppose two candidates both describe 203.0.113.0/24:

If the routes have equal administrative trust and otherwise comparable attributes, the lower metric is normally preferred.

Routes can come from connected interfaces, static configuration, and several routing protocols. Systems use an administrative preference to decide which source is trusted when multiple sources offer the same prefix. The names, numeric ranges, and ordering are platform-specific.

The selection order can be summarized as:

A default route with metric 1 still loses to a /24 route with metric 1000 for a destination inside the /24. Comparing those metrics before prefix lengths reverses the selection order and produces the wrong result.

A route can identify a next hop without directly stating how that next hop is reached.

Consider:

The first route selects 198.51.100.2. The device then resolves that next-hop address against its routing information. The connected /30 confirms that 198.51.100.2 is reachable through wan0.

This second lookup is called recursive next-hop resolution. The final result installed in the FIB can contain the resolved interface and neighbor information needed for forwarding.

If no route reaches 198.51.100.2, the first route cannot provide a usable forwarding path. A destination prefix can therefore exist in configuration while remaining inactive or failing to install.

After selecting the interface and next-hop IP, the device still needs the local link-layer destination. On Ethernet, IPv4 uses ARP and IPv6 uses Neighbor Discovery to obtain it.

The responsibilities remain separate:

A valid route with failed neighbor resolution produces a different failure from having no route at all.

When a router receives a frame containing an IP packet, its forwarding path performs work similar to this:

If the lifetime field reaches zero, the router discards the packet. This prevents a forwarding loop from circulating one packet indefinitely.

An IPv4 router also updates the IPv4 header checksum after changing the TTL. IPv6 has no base-header checksum, so changing the Hop Limit does not require that calculation.

The outgoing link can have a smaller MTU than the incoming link. IPv4 may fragment a packet when fragmentation is permitted. An IPv6 router never fragments a forwarded packet; the source must adapt to the path.

If the output interface is congested, the router may queue the packet or drop it. A correct route therefore does not guarantee delivery.

The following isolated example uses documentation address ranges:

R1 has:

R2 has:

The reverse route on R2 is necessary for the server's response to return toward the client.

The client first matches its default route and sends the frame to R1. The IP destination remains 203.0.113.20.

R1 removes the first frame, decreases the TTL, matches 203.0.113.0/24, and selects 198.51.100.2. It then creates a new frame on the transit link.

R2 removes that frame, decreases the TTL again, and finds that 203.0.113.0/24 is directly connected. It resolves the server's local link-layer address and transmits the final frame.

The source and destination IP addresses remain the endpoint addresses in this ordinary routed example. The source and destination MAC addresses change for every Ethernet link.

A routing system can retain multiple paths with the same preference and cost. Equal-Cost Multipath, or ECMP, spreads traffic across those next hops.

Per-packet distribution can reorder packets, which harms protocols and applications that expect stable ordering. Implementations therefore commonly hash fields from the packet, such as source and destination addresses and transport ports, to keep one flow on one path.

ECMP does not guarantee perfectly even utilization. A small number of large flows can hash unevenly, and different devices can use different hash inputs.

When a next hop fails, the forwarding set changes. Existing flows can move to another path, producing a brief interruption or a change in latency. ECMP provides path capacity and redundancy, while the surrounding routing system still has to detect failures and update the installed next hops.

A routing loop occurs when routers repeatedly forward a destination toward one another. The TTL or Hop Limit bounds the damage to each packet, but traffic is lost and links still carry the looping packets until their lifetime expires.

A black hole occurs when a route accepts traffic toward a path that does not deliver it. The router might have a stale route, a failed next hop, a filtering rule, or an intentionally configured discard route.

Some routing tables support explicit black-hole entries:

This route deliberately discards matching traffic. Such entries can contain unwanted traffic or enforce aggregate boundaries, but they can also hide a more specific configuration mistake.

Asymmetric routing means the request and response use different paths. IP does not require both directions to cross the same routers. Asymmetry can still cause operational problems when a stateful firewall observes only one direction, a policy expects a particular ingress interface, or the two paths have very different capacity.

Route correctness must therefore be checked in both directions. A client can have a perfect route to a server while the server or an intermediate router lacks a route back to the client's source prefix.

Networks change when links fail, interfaces go down, metrics change, or new reachability information arrives.

The control plane must detect the change, select replacement routes, and update the FIB. The time from topology change to consistent forwarding is convergence time.

During convergence, packets can follow an old path, encounter a temporary loop, or reach a router that has already removed the route. Different routers do not update at the exact same instant.

Fast failure detection can reduce the interruption, but aggressive timers also increase control traffic and can react to brief instability. Backup routes help only when they are independent of the failed component.

Applications experience convergence as packet loss, retransmissions, latency spikes, or connection failure. The network can recover while an application-level deadline still expires.

Ordinary forwarding primarily selects a route from the destination IP address. The examples in this chapter use that model.

A system can maintain several routing tables or apply policies before lookup. A policy can choose a table based on source address, incoming interface, packet mark, or another configured attribute. Virtual routing contexts can let separate tenants reuse the same prefixes without sharing one forwarding table.

Tunnels also add another layer of lookup. A system first routes the outer packet between tunnel endpoints; after decapsulation, it routes the inner packet in the appropriate context.

These features do not remove longest-prefix matching. They determine which routing context and destination lookup the packet uses. Debugging requires identifying that context before reading a route table.

Linux displays the main IPv4 routing table with:

A host can show:

Inspect the kernel's selected path for one destination with:

Example output:

This answers several questions at once: which next hop, which interface, and which source address the host intends to use.

IPv6 uses equivalent commands:

On macOS, inspect IPv4 routes and a selected destination with:

On Windows:

A machine with several interfaces can receive packets without forwarding them between interfaces. On Linux, inspect forwarding state with:

Forwarding must also be allowed by firewall and system policy. Enabling the kernel setting alone does not create the required routes or authorize the traffic.

Start at the endpoint making the wrong decision and follow the intended path one hop at a time.

Packet captures on both sides of a router are especially useful. Receiving a packet on the ingress interface without seeing it on the expected egress interface narrows the problem to forwarding state, policy, lifetime, MTU handling, or local delivery on that router.

The host has an IP address but no default route. Local destinations can work while every remote network fails.

The default gateway is outside every connected prefix. The host cannot resolve the first next hop, so the default route is unusable without special on-link configuration.

A broad route hides the absence of a required specific path. The packet matches a default or aggregate and travels in the wrong direction.

A static route names an unreachable next hop. The destination entry exists, but recursive next-hop resolution cannot produce an outgoing action.

The outbound path works but responses never arrive. The destination or an intermediate network may lack a route to the source prefix.

A lower metric route is ignored. A longer matching prefix wins before metrics for less-specific prefixes are compared.

Neighbor resolution fails after route lookup. The routing table can select the correct interface while ARP or Neighbor Discovery cannot identify the local receiver.

One ECMP path is broken. Only flows hashing to that next hop fail, creating intermittent symptoms across clients or connections.

A multihomed host receives traffic but does not forward it. IP forwarding may be disabled, or firewall policy may deny traffic between interfaces.

A route change causes a short outage. Control-plane convergence and FIB updates can take longer than the application's timeout.

A router does not choose an entire end-to-end path for every packet. It selects one local forwarding action, and the next router makes its own decision.

The default gateway is a local next hop. Its address must be reachable through an attached link under ordinary configuration.

The destination MAC is not the remote server's MAC. Each Ethernet frame targets the next receiver on that local link.

The default route does not always win. It is /0, so every more-specific matching prefix takes precedence.

Lowest metric is not the first selection rule. Longest-prefix matching occurs before metrics are compared among routes to the same prefix.

A routing-table entry does not guarantee forwarding. The next hop, interface, neighbor state, FIB installation, MTU, and policy must all be usable.

A working request path does not prove a working return path. IP routing can be asymmetric, and each direction is selected independently.

Connected does not mean local to the process. A connected route reaches another interface on the link; a local route delivers to an address owned by the host.

Routing and neighbor resolution solve different problems. Routing selects a next-hop IP and interface; neighbor discovery supplies the local link-layer destination.

TTL and Hop Limit do not select faster routes. They limit how many routers can forward a packet before it is discarded.

Routing builds reachability information; forwarding applies it to packets. Hosts and routers use connected, local, static, learned, and default routes to choose local delivery, an on-link destination, or a gateway.

Longest-prefix matching selects the most specific route, while source preference and metrics choose among candidates for that prefix. Recursive resolution maps the next-hop IP to an outgoing interface, then ARP or Neighbor Discovery resolves the link-layer destination.

At each router, incoming framing is removed, TTL or Hop Limit decreases, the destination is looked up, and new framing is created. Endpoint IP addresses normally remain stable while Ethernet addresses change on every link. ECMP may distribute flows across equal-cost paths, so one failed member can affect only some traffic.

Valid-looking routes can still fail because of loops, black holes, asymmetric paths, convergence, MTU limits, or filtering. Diagnosis must verify the selected route, next-hop reachability, forwarding state, and return path at each boundary.

Routing is a sequence of local decisions over hierarchical prefixes.