How Routers Really Decide Where Packets Go
A router does not “pick the best route” in one single step. It first has to learn or configure routes, decide which candidates belong in the routing table, and then perform a forwarding lookup for each destination. Mixing those stages together is the source of many routing misconceptions.
For CCNA 200-301, the durable model is to separate route installation from packet forwarding. Administrative distance and protocol metrics help build the routing table. Longest-prefix match determines which installed route matches a packet most specifically. The next hop and outgoing interface then tell the router how to move the frame toward that destination.
Once those layers are separated, a routing table stops looking like a wall of codes and becomes a record of decisions the control plane has already made.
Routes arrive from different sources
A router can know about a network because the network is directly connected, because an administrator configured a static route, or because a dynamic routing protocol learned it from another router. Those sources are not automatically equal.
Directly connected networks appear when an interface with an appropriate IP address is operational. Static routes are explicit administrative instructions. Dynamic protocols such as OSPF exchange information and calculate paths according to their own rules.
The routing process has to decide which candidate information should be installed. That selection happens before any particular packet arrives.
This separation becomes even more important at the CCNP Enterprise level, where redistribution and multiple routing protocols can produce several candidates for the same prefix.
Administrative distance compares different route sources
When routes to the same destination prefix come from different routing sources, Cisco uses administrative distance as a local measure of source preference. Lower values are preferred. Connected routes have a lower default distance than static routes, and common dynamic protocols have their own defaults.
Administrative distance does not compare a /24 with a /25 as if they were two versions of the same route. Different prefix lengths describe different destinations, so both can be installed at the same time.
That distinction matters because an engineer may see an OSPF /24 and a static /16 in the same table and ask which one “wins.” At installation time they are not competing for the same prefix. At forwarding time, a packet can match both—and the more specific prefix can then win through longest-prefix match.
Metrics compare paths inside a routing protocol
A routing protocol can learn multiple paths to the same prefix from the same source. It uses its metric to rank those paths. OSPF uses cost. Other protocols use other calculations.
Metrics are not universally comparable across routing protocols. An OSPF cost of 20 is not inherently “better” than some metric from another protocol. Administrative distance decides between route sources; the protocol’s own metric chooses within that source.
If multiple paths from the same protocol have equal usable metrics and the platform supports them, the router may install multiple equal-cost next hops and load-share traffic.
Longest-prefix match decides which installed route forwards the packet
After the routing table is built, the router performs a lookup using the destination IP address. If several installed routes match, the route with the longest prefix is preferred because it describes the smallest, most specific address range.
Suppose the table contains 10.0.0.0/8, 10.20.0.0/16, and 10.20.30.0/24. A packet for 10.20.30.50 matches all three, but /24 is the longest prefix. A packet for 10.20.99.10 matches /8 and /16, so /16 wins. A packet for 10.99.1.1 matches only /8.
This is where strong IPv4 subnetting skills pay off. You cannot read route specificity confidently if prefix boundaries still feel like memorized tables.
The default route is simply the least-specific match
The IPv4 default route, 0.0.0.0/0, matches every IPv4 destination because it fixes zero network bits. That makes it useful as a path of last resort when no more specific route matches.
“Last resort” does not mean the router waits until every protocol has failed. It means any installed route with a longer matching prefix outranks the /0 during lookup.
This model explains why a default route can coexist with thousands of specific routes. It is not competing with them on administrative distance unless the router is choosing among multiple candidates for the same /0 prefix. It is simply less specific at forwarding time.
Recursive lookup resolves a next hop into something the router can actually send to
A route may point to a next-hop IP address rather than directly to an outgoing interface. The router then needs to know how to reach that next hop. That can require another routing-table lookup.
The result eventually resolves to an adjacency on an attached network. At that point, the router can use Layer 2 information—such as ARP for IPv4 Ethernet—to build the frame for the next hop.
This is why a route can appear correct but still fail to forward if the next hop is unreachable, the outgoing interface is down, or Layer 2 adjacency resolution fails. The routing table is necessary evidence, but it is not proof that a packet successfully left the box.
The RIB and the forwarding table serve related but different jobs
Engineers often speak casually about “the routing table,” but high-performance platforms separate the routing information base from a forwarding information base used for packet switching. Cisco Express Forwarding builds structures that support fast lookups and adjacency handling.
You do not need to become a silicon architect to troubleshoot routing, but the distinction explains why control-plane information and actual forwarding state can be inspected separately on advanced systems.
The 350-401 ENCOR path expands this idea into enterprise forwarding, route behavior, and infrastructure troubleshooting. The mental model still begins with the same question: what did the control plane learn, what did it install, and what will the forwarding plane do with this destination?
Summarization adds another layer to route selection. A router may advertise one broad prefix instead of many component routes. The summary reduces table size and routing updates, but it also changes what downstream routers know. If the summarizing router loses one component subnet while continuing to advertise the summary, traffic can still be attracted toward a destination that is no longer reachable behind it unless the design accounts for that possibility.
Floating static routes show how administrative distance can be used intentionally. An engineer can configure a static route with a higher distance than the preferred dynamic route so it remains out of the table under normal conditions and becomes eligible if the dynamic route disappears. The technique is useful only when the backup next hop really provides independent reachability; otherwise the network gains a route entry without gaining resilience.
Policy-based routing and software-defined overlays can influence forwarding beyond a simple destination lookup, but those mechanisms are easier to understand after the normal routing pipeline is solid. Start with ordinary destination-based forwarding, then treat policy exceptions as explicit departures from that baseline rather than using them to explain every packet from the beginning.
Read a routing table in a fixed order
When diagnosing a destination, start with the destination address and identify every matching prefix in the table. Choose the longest match. Then read how that route was learned, the administrative distance and metric if shown, the next hop, and the outgoing interface.
Next verify that the next hop is resolvable and the interface is operational. If the route came from a dynamic protocol, ask whether the route is stable and whether an unexpected source is preferred. If no specific route exists, determine whether a default should apply.
This sequence prevents common detours such as comparing metrics between unrelated protocols or changing administrative distance when the real problem is a more-specific route.
Routing problems become simpler when you name the decision stage
If the wrong route is installed, investigate route sources, administrative distance, protocol metrics, filtering, and configuration. If the correct routes are installed but the wrong one is used for a destination, verify prefix math and longest-prefix match. If the correct route is selected but traffic still fails, continue into next-hop resolution, Layer 2, ACLs, NAT, or downstream routing.
That troubleshooting structure is one reason routing knowledge transfers from CCNA into more advanced work such as ENARSI. The network can become much larger, but routers still need to learn reachability, select usable routes, and forward toward the most specific matching destination.
The same logic helps during change reviews. Before adding a static route or changing a protocol preference, predict which prefixes will enter the table and which destinations will match them. Then verify after the change. If you cannot state which forwarding decisions are supposed to change, the configuration is not yet well understood. Routing becomes safer when every control-plane change is tied to an expected packet-flow outcome.
It also helps to distinguish a route that exists from a route that is usable. A static route may be configured while its next hop cannot be resolved. A dynamic protocol may advertise a prefix that never becomes the preferred route. A directly connected network can disappear when its interface goes down. These are different control-plane conditions even if the symptom is simply that a destination no longer responds. When you compare the running configuration, protocol database, routing table, and forwarding information, ask which stage first stopped agreeing with the intended design. That question is far more precise than asking why the router ‘ignored’ a route. Routers do not ignore arbitrary information; they apply eligibility, preference, specificity, and resolution rules in a repeatable sequence.
This model also explains why traceroute is useful but incomplete. It shows the Layer 3 hops that answer along a path, not the full logic each router used to select that path. When traceroute changes unexpectedly, return to the tables at the divergence point and identify the prefix and next hop that made the new forwarding decision.
A router’s decision is not magic and it is not a single ranking formula. Build the table first. Match the destination second. Resolve the next hop third. Once those stages are separate in your head, routing output becomes far easier to trust and troubleshoot.