How routing and forwarding really differ

The distinction between routing and forwarding is a distinction between two planes in a network device: the control plane and the data plane.

The control plane is where routing decisions are made. It builds and maintains the routing table by running routing protocols (BGP, OSPF, static configuration) or receiving external route information. The control plane operates on minutes to seconds timescales. It is computationally expensive and relatively slow.

The data plane (also called the forwarding plane) handles individual packets. For each packet, the router reads the destination IP address, looks it up in the forwarding table (derived from the routing table), and sends the packet out the appropriate interface. The data plane operates on microsecond timescales and is often implemented in dedicated hardware (ASICs) for line-rate performance.

Routing is how the router learns what it knows. Forwarding is what the router does with that knowledge for each packet. A routing protocol problem and a forwarding table problem are not the same fault.

Because the two planes are separable, the routing table can be filled by completely different means without the forwarding behaviour changing at all. A router does not care whether an entry was typed by an engineer or learned from a neighbour thirty seconds ago; it looks the entry up either way. What differs is how quickly the table notices that the world has moved.

A static route is manually configured: the network administrator tells the router "to reach network X, send packets to next hop Y." Static routes are simple and predictable but do not respond to topology changes. If the next hop fails, the static route remains in the table and packets continue being sent to a dead path.

Dynamic routing protocols allow routers to discover, share, and update routes automatically. Two major protocol families are relevant for this module.

OSPF (Open Shortest Path First), defined in RFC 2328, is a link-state interior gateway protocol. Routers using OSPF exchange Link State Advertisements (LSAs) describing their connected networks and link costs. Each router builds a complete map of the network and runs Dijkstra's algorithm to compute the shortest path to each destination. OSPF is used within a single organisation's network.

BGP (Border Gateway Protocol), defined in RFC 4271, is the exterior gateway protocol that interconnects autonomous systems across the internet. An autonomous system (AS) is a network under a single administrative control with a unique AS number. BGP carries path attributes, not just metrics. Route selection considers factors including AS path length, local preference, and origin type.

OSPF and BGP both end up writing entries into the same table, and those entries routinely overlap: a /16 learned from one source and a /24 covering part of it learned from another. The data plane needs one deterministic answer for every packet, and it gets it from a rule that ignores which protocol supplied the entry.

When a router's forwarding table contains multiple entries that could match a destination address, it uses the most specific match: the entry with the longest prefix (the most bits specified). This is longest prefix match.

Consider a router with two entries for the 10.0.0.0 space: one for 10.0.0.0/16 via interface A, and one for 10.0.1.0/24 via interface B. A packet for 10.0.1.5 matches both entries (10.0.1.5 is within 10.0.0.0/16 and within 10.0.1.0/24). The /24 entry is more specific, so the router forwards the packet via interface B.

This rule is why the Pakistan Telecom incident worked. YouTube's own /22 route was less specific than PTCL's /24 announcement. Every router in the world with both routes in its table chose the /24, because that is the rule, regardless of which announcement was legitimate.

If the most specific prefix always wins, the least specific one is the interesting edge case: the entry that matches every address and therefore only ever gets used when nothing else does.

The default gateway is the router a host sends packets to when it has no more specific route for the destination. On a home network, this is typically your router. Your laptop has routes for the local subnet and a default route pointing at the router for everything else.

In routing tables, the default route is written as 0.0.0.0/0. It matches every destination address (since every address starts with zero matching bits), but it is also the least specific possible prefix. Any more specific route will override it via longest prefix match. The default route only handles destinations with no other match.

Everything to this point describes how a router acts on the routes it holds. It says nothing about whether those routes are true. Inside one organisation that gap is closed by the fact that one team configures every router. Between organisations there is no such team, which is the problem the rest of this module deals with.

BGP-4, specified in RFC 4271, has no mechanism for deciding whether an announcement is truthful. A router that receives an UPDATE checks that the message is well formed and that its own policy permits the neighbour, then it believes what the neighbour said about which prefixes it can reach. That is the design. The Pakistan Telecom incident was not an exploit of a flaw; it was BGP working exactly as specified on an announcement nobody had any way to check.

The check now exists. Route Origin Validation, specified in RFC 6811, gives a router a way to test an announcement against a signed statement from the address holder. The address holder publishes a Route Origin Authorisation (ROA) in the Resource Public Key Infrastructure: a cryptographically signed record naming the prefix, the maximum prefix length permitted, and the autonomous system authorised to originate it. Routers fetch the validated set of these records and compare every announcement against it.

The comparison produces one of three states. Valid means a ROA covers the prefix and the announcing AS is the authorised origin. Invalidmeans a ROA covers the prefix but the origin AS is wrong or the announcement is more specific than the ROA's maximum length. NotFound means no ROA covers the prefix at all, which is the honest answer for address space whose holder has never published one. RFC 6811 deliberately stops there and leaves the action to local policy. The operational norm that has settled around it is to reject Invalid announcements outright, to accept Valid ones, and to accept NotFound because rejecting it would disconnect every network that has not yet signed its space.

An announcement like PTCL's is Invalid today wherever the prefix holder has published a ROA, because the origin AS in the announcement is not the one the signed record authorises, and a validating router drops it before it can spread. That is a real improvement and a bounded one. ROV checks the origin of a route, not the AS path attached to it, so an attacker who forges a plausible path with the correct origin still passes validation. Path validation is a separate and far less deployed problem.

The adoption figures are what make this teachable as engineering rather than as a story about a bad day in 2008. Reading the NIST RPKI Monitor in July 2026, ROAs now cover more than half of the IPv4 routes in the global table, from a published set of roughly 480,000 ROAs. The same measurement exposes the gap: only about 12 percent of stub autonomous systems, the networks at the edge that originate their own space and transit nobody, are fully protected. Signing your prefixes and validating what you accept are two separate acts, and the edge of the internet has done far less of either than the core has.

For an operator, that turns routing security into two checkable questions rather than a warning. Has this organisation published ROAs for every prefix it originates, at the right maximum length so its own more specific announcements do not read as Invalid? And does it reject Invalid routes at every peering session, rather than logging them? Both have answers you can produce from a configuration and a monitor, which is what a measurable partial fix looks like.