Forwarding & Routing

A router does two very different jobs, and the network layer splits them into two planes: the data plane moves packets fast, and the control plane decides where they should go. Keeping these separate is the central idea of Layer 3.

Forwarding vs routing

• Forwarding (data plane) - the local, per-packet action: a packet arrives on an input port, the router looks up the destination address in its forwarding table, and moves the packet to the correct output port. This happens in nanoseconds, for every packet, usually in hardware.
• Routing (control plane) - the network-wide process of building that forwarding table. Routing protocols (OSPF, BGP) exchange reachability information so each router learns which next hop leads toward each destination.

	Forwarding	Routing
Plane	Data plane	Control plane
Scope	Local - one router, one packet	Network-wide
Timescale	Per packet (nanoseconds)	Seconds to minutes
Question	Which output port for this packet?	How is the forwarding table built?
Typically runs in	Hardware (ASIC)	Software (routing daemon)

Inside a router

At a high level a router is four cooperating pieces:

• Input ports - receive incoming packets, do the forwarding-table lookup, and decide the output port.
• Switching fabric - the internal interconnect that physically moves a packet from an input port to its chosen output port.
• Output ports - transmit packets onto the outgoing link.
• Queues (buffers) - hold packets when they arrive faster than they can be forwarded or transmitted. Queues absorb bursts; when they overflow, packets are dropped. This is where congestion and delay show up.

The forwarding table and longest-prefix match

The forwarding table maps destination prefixes to outgoing interfaces. Prefixes can overlap, so a single destination address may match several rows.

Destination prefix	Outgoing interface
200.23.16.0/20	0
200.23.24.0/23	1
200.23.0.0/16	2
0.0.0.0/0 (default)	3

Suppose a packet is destined for 200.23.24.50. It matches 200.23.16.0/20, 200.23.24.0/23, and the /16, and the default route. Which row wins?

info

When several rows match a destination, the router picks the one with the longest prefix - the most specific route (the most leading bits in common). For 200.23.24.50 that is 200.23.24.0/23 (interface 1), because /23 is longer than /20 and /16. The 0.0.0.0/0 default route matches everything with prefix length 0, so it only wins when nothing more specific does.

Longest-prefix match is why routing scales: providers advertise a few large aggregate prefixes, and a customer's more specific prefix automatically takes precedence without needing to remove the aggregate.

Two more lookups against the same table

Using the same forwarding table above, trace a couple more destinations to see how the match set changes:

• 200.23.18.100 - in binary the third octet 18 is 00010010. Against 200.23.16.0/20 (16 = 00010000, matches the top 4 bits 0001) it matches. Against 200.23.24.0/23 (24 = 00011000) it does not match, since bit patterns diverge above the /23 boundary. Against 200.23.0.0/16 it matches (same first two octets). Longest match among /20 and /16 is the /20, so the packet goes out interface 0.
• 200.23.5.9 - matches only 200.23.0.0/16 (interface 2) - it falls outside both 200.23.16.0/20 and 200.23.24.0/23. Longest match is the /16 itself, so it goes out interface 2.
• 74.125.20.1 - matches none of the specific prefixes, so it falls through to the default route 0.0.0.0/0 and goes out interface 3.

⚠A missing or wrong default route creates a silent black hole

If a router's forwarding table has no 0.0.0.0/0 entry and a packet's destination doesn't match any specific prefix, the packet is dropped right there - often with no error surfaced to the sender beyond a generic timeout, since the router may not even send back an ICMP "destination unreachable" if that behavior is disabled or filtered upstream. In production this shows up as traffic to a specific IP range mysteriously vanishing while everything else works fine: a newly acquired IP block that hasn't been advertised into the aggregate prefix yet, or a static route that was removed during cleanup but was still the only path to some third-party service, both produce this exact symptom. Because longest-prefix match always prefers a more specific route silently, a stale or overly broad static route can also shadow a more correct dynamically-learned route without any alert - the fix is often invisible until someone traces the actual forwarding table hop by hop.