How Routers Work: Routing Tables, Next Hop & Longest Prefix Match

How Routers Work: Control Plane vs Data Plane

A router\'s job sounds simple — get this packet to that network — but it splits into two separate jobs that run on different timescales:

• Control plane: learns which destinations exist and computes the best path to each one. This is slow, periodic work: routing protocols exchange updates, the router recalculates, and the result lands in the RIB (Routing Information Base).
• Data plane (forwarding plane): forwards packets, one at a time, at line rate. It never re-runs a routing algorithm per packet — it does a lookup against a precomputed table, the FIB (Forwarding Information Base), and moves on.

Everything below — routing tables, longest prefix match, next hop resolution — is really an explanation of how those two planes stay in sync: the control plane decides, the data plane executes, and the router\'s entire performance profile depends on keeping that split intact. If you already know IP addressing/subnetting and roughly how the OSI model\'s layers map to real traffic, you have everything you need to follow the rest of this guide.

How Routing Tables Are Built: Connected, Static, and Dynamic Routes

The routing table — formally the RIB — is the router\'s list of known destination prefixes and how to reach each one. Routes enter it from three sources:

• Connected routes: subnets directly attached to an interface that is up/up. These get the lowest administrative distance because the router has direct, first-hand knowledge of them.
• Static routes: manually configured by an administrator (e.g. ip route 10.1.2.0 255.255.255.0 10.1.1.2). Predictable, but they don\'t react to a link failure — if the path breaks, the static route stays in the table pointing at a dead end unless it\'s tied to a reachability check.
• Dynamic routing protocols: learned via OSPF, BGP, RIP, EIGRP, or others, which exchange reachability information with neighboring routers and adapt automatically when the topology changes.

A subtlety worth having straight early: the RIB can legitimately hold more than one route to the exact same prefix (say, both a static route and an OSPF route to 10.1.2.0/24). Only one of them gets installed as the active, forwarding-eligible route. That decision — not longest prefix match, which is a different mechanism covered later — is what administrative distance and metric are for.

Route Selection: Administrative Distance, Metric, and Tie-Breakers

When two or more sources advertise a route to the same prefix, the router has to pick one. It works through three criteria in order:

1. Lowest administrative distance (AD) — a per-source trust score. Cisco IOS\'s defaults are the ones every vendor\'s documentation gets compared against:

A route with a lower AD always wins regardless of metric — a static route (AD 1) beats an OSPF route (AD 110) to the identical prefix even if OSPF\'s path is objectively shorter, per Cisco\'s administrative distance documentation. This trips people up in labs constantly: they add a static route to test something, forget to remove it, and can\'t understand why OSPF\'s supposedly-better path is being ignored.

1. Lowest metric within the same protocol — if two routes to the same prefix come from the same source (two OSPF neighbors, say), the router compares metric: hop count for RIP, cost for OSPF, composite bandwidth/delay for EIGRP, or path attributes for BGP.
2. Protocol-specific tie-breakers — if AD and metric are still equal, the router falls back on per-protocol rules (e.g. router ID, or equal-cost multipathing if the platform supports it for that protocol).

Default Route: The Catch-All for Everything Else

A default route (0.0.0.0/0) is the fallback used when no more specific prefix matches the destination. It sits at the network edge pointing at an ISP, or inside a small network pointing at a single upstream gateway. Structurally it\'s just another routing table entry — it participates in longest prefix match like anything else, but because /0 is the least specific mask possible, it only wins when nothing more specific matches. That\'s also why a missing or misconfigured default route is the classic cause of "everything internal works, but the internet is down": internal /24s still match their specific routes, only unknown destinations have nowhere to go.

RIB vs FIB: Why Routers Keep Two Separate Tables

The RIB and FIB solve different problems, which is why collapsing them into "the routing table" as a single concept eventually causes confusion:

In practice this separation is what lets a router keep forwarding traffic at full speed while the control plane is busy reconverging after a link flap — the FIB doesn\'t have to wait on every routing protocol recalculation, only on the moment a new best path is actually installed.

Next Hop Resolution: From a FIB Entry to a MAC Address

The next hop is the immediate router or gateway IP a packet is handed to on its way toward the final destination. The FIB lookup tells the router the egress interface and the next-hop IP — but to actually put a frame on the wire, the router needs a Layer 2 address. That\'s next-hop resolution: ARP for IPv4, NDP for IPv6.

Worked example: Router A has a FIB entry for 10.1.2.0/24 via next hop 10.1.1.2 out Gig0/0. Before it can transmit on that Ethernet segment, it checks its ARP table:

# show arp (example)\n10.1.1.2   00:11:22:33:44:55   Gig0/0

If there\'s no entry, the router broadcasts an ARP request on that segment, caches the reply, and only then forwards the packet. This resolution step is local-link only — it never crosses a router boundary, which is exactly why "next hop unreachable" (a next hop that isn\'t actually on a directly connected subnet) is a routing table configuration error rather than something ARP can fix. NAT and port rewriting on edge devices change the L3/L4 headers in flight, but the L2 requirement doesn\'t go away: the next hop still has to resolve to a real neighbor on the local segment.

Longest Prefix Match: How Routers Pick the Most Specific Route

Longest prefix match (LPM) is the algorithm a router\'s data plane uses to pick a route from the FIB when a destination address matches more than one entry. It always selects the entry with the longest subnet mask — the most specific match — not the one with the best administrative distance or metric. Per Juniper\'s documentation on the longest-match routing rule, this is the algorithm IP routers use specifically to determine the egress interface and next-hop address once multiple candidate routes are on the table.

This is worth separating clearly from the AD/metric selection covered earlier: AD and metric decide which single route wins when several sources advertise the identical prefix. LPM decides which route wins when different-length prefixes each independently match the same destination address — a different problem, resolved by a different mechanism, at a different point in the packet\'s journey (RIB build time vs. FIB lookup time).

Worked example. Assume this FIB:

Destination: 192.168.1.130 (binary 11000000.10101000.00000001.10000010). All three prefixes match — the address falls inside each range — but the router picks 192.168.1.128/25 via R3, because 25 matching bits beats 24, which beats 16. If two matching routes happened to share the exact same prefix length, LPM can\'t break the tie; that\'s when the router falls back to whichever route was already installed by the AD/metric process for that specific prefix.

Static vs Dynamic Routing: RIP, OSPF, and BGP Compared

Static routing means an administrator hand-configures every route. It\'s predictable and has zero protocol overhead, but it doesn\'t adapt: if a link goes down, traffic keeps getting routed toward it until someone intervenes (or a route is tied to IP SLA/BFD tracking). Dynamic routing protocols learn and update routes automatically as the topology changes, at the cost of control-plane overhead and a learning curve:

A practical starting point for a small lab: get connected and static routes working first, add OSPF between two or three routers, and only bring in BGP once you\'re comfortable reasoning about AD, metric, and policy separately — BGP\'s behavior stops making sense if those three are still blurred together.

Packet Forwarding Steps: From Ingress to Egress

1. Ingress: a packet arrives; the router validates the header and applies any configured ACL or QoS policy.
2. FIB lookup: the data plane applies longest prefix match against the FIB to find the best matching destination prefix.
3. Next hop identification: the router reads the next-hop IP from the matched FIB entry and resolves it to a MAC address (ARP/NDP) if it isn\'t already cached.
4. Header rewrite: decrement the TTL/hop limit, recompute checksums as needed, apply NAT if configured, and encapsulate the packet for the egress medium.
5. Egress: transmit the frame out the selected interface toward the resolved next hop.

Troubleshooting Router Paths: Commands and What to Check

The order that catches most beginner mistakes: confirm the route is actually in the RIB and active, confirm the next hop resolves in ARP, then confirm the interface and any ACL aren\'t silently dropping the traffic. A route that "looks right" in show ip route but never forwards is very often an unresolved or stale ARP entry, not a routing problem at all. For a broader walk-through of this process end to end, see our network troubleshooting basics guide.

Quick Glossary and Cheat Sheet

How routers work comes down to that same flow every time: the control plane learns routes into the RIB, administrative distance and metric settle any conflicts over the same prefix, the result is compiled into the FIB, and the data plane uses longest prefix match plus next-hop resolution to move each packet from ingress to egress. Reading a live routing table and tracing one packet through these steps in a small lab is the fastest way to make it stick.

Ready to see how this same reasoning applies to a site\'s own AI-agent and crawler traffic instead of a lab topology? Get a free AI-visibility consultation from Netalith\'s engineering team.