Separate route installation from packet forwarding
“How does the router choose a path?” actually contains two related decisions. First, the router may have to choose which candidate routes become active or installed. Second, when a packet arrives, the forwarding lookup chooses the most-specific installed destination prefix that matches that packet.
This distinction prevents one of the most common mistakes: seeing a low metric and assuming it beats a more-specific prefix. A route metric helps choose among routes in the appropriate route-selection context; longest-prefix matching decides which installed destination range applies to a packet.
For an artifact question, first identify whether you are looking at candidate route selection or an already-built routing/forwarding table. The evidence determines which rule belongs first.
The most-specific matching installed prefix wins the destination lookup
A prefix with more fixed network bits describes a narrower destination range. If a destination matches both 10.0.0.0/8 and 10.20.30.0/24, the /24 is more specific and wins. A default route, 0.0.0.0/0, matches every IPv4 destination but is the least specific.
Do not compare the next-hop distance before deciding which prefix applies. The /24 wins because of destination specificity, not because next hop C is physically closer.
Summary routes and narrow exceptions can coexist without contradiction
Longest-prefix matching makes hierarchical routing practical. A router can hold a broad route for a large address block while installing a narrower route for one subnet that must travel somewhere else.
For example, 172.16.0.0/12 might point toward a regional core while 172.20.44.0/24 points toward a special site. Packets for 172.20.44.9 match both, but the /24 exception wins. Packets for 172.21.8.9 that do not match a narrower exception use the /12.
This is why “the summary route includes that address” does not mean the summary will necessarily be used.
Connected, static, and dynamically learned routes can compete before forwarding begins
Routers can know routes because an interface is directly connected, an administrator configured a static route, or a routing protocol learned a path. When multiple route sources offer a route to the same destination prefix, the platform needs rules for deciding which candidate becomes active.
Many platforms use a route-source preference concept often called administrative distance or administrative preference. The exact values and terminology are implementation-specific, so use the values a prompt provides rather than memorizing one vendor's table as a universal law.
Once the relevant routes are installed, packet forwarding still uses destination-prefix matching. Source preference does not make a /16 override an installed /24 for a destination that matches both.
Metrics rank paths within their routing context—not every route in the table
Routing protocols calculate path desirability using their own models. A metric might reflect hop count, bandwidth-related cost, delay, or a composite calculation. A lower value often means “better” within a given protocol, but metric 20 from one protocol is not automatically comparable with metric 30 from another.
The safe reasoning order is: are these routes for the same prefix? Are they competing within the same route-selection context? What preference rule chooses the source? If the same protocol has multiple paths to that prefix, what does its metric say? Only then decide which candidates are installed or preferred.
Walk a destination through the table instead of choosing the smallest number
| Prefix | Next hop | Metric shown | Matches 192.168.44.70? |
|---|---|---|---|
| 192.168.0.0/16 | 10.0.0.1 | 5 | Yes |
| 192.168.44.0/24 | 10.0.0.2 | 80 | Yes |
| 192.168.44.64/27 | 10.0.0.3 | 200 | Yes |
| 0.0.0.0/0 | 10.0.0.254 | 1 | Yes |
Swipe horizontally to see the full table.
Destination 192.168.44.70 lies inside 192.168.44.64/27, so that /27 is the most-specific matching installed prefix. The displayed metric 200 does not cause the /16 or default route to win the forwarding lookup.
A selected route can require another lookup before a frame can leave the router
A route may identify a next-hop IP rather than a directly connected outgoing neighbor. The router then needs to determine how to reach that next hop. This can involve another routing-table lookup—recursive resolution—until the forwarding process identifies an outgoing interface and reachable local next-hop context.
Therefore a matching route is not proof of successful delivery. If the next hop cannot be resolved, the outgoing interface is down, or Layer 2 adjacency fails, forwarding can still break after route selection.
Directly connected routes anchor next-hop reachability
When a router interface is configured and operational for a network, that directly connected network can appear as a connected route. Connected reachability matters because static and dynamic routes often point toward next-hop addresses that must ultimately be reachable through an attached network or another resolvable route.
If a route points to 10.1.1.2 as next hop, ask how the router reaches 10.1.1.2. If the expected interface/network is down or absent, the route may not be usable even though a stale or provided artifact appears to name the next hop.
The default route is a fallback, not the router's first choice
0.0.0.0/0 is often described as “send unknown destinations this way.” More precisely, it is an installed route with prefix length zero. Because every IPv4 destination matches zero fixed network bits, it is considered only when no more-specific installed prefix wins.
If a specific route exists but points toward a broken path, the router does not generally ignore that more-specific match and use the default merely because the default would work better. Longest-prefix lookup still chooses the more-specific installed route unless routing state changes.
More than one path can be correct when equal-cost routes are installed
With Equal-Cost Multipath (ECMP), multiple eligible routes to the same prefix can be installed and used. Implementations often distribute traffic using a hash based on flow fields rather than sending every packet alternately.
This matters for troubleshooting. If one ECMP path is impaired while another works, some flows may succeed while others fail depending on the hashing behavior. A single successful test does not necessarily prove every equal-cost path is healthy.
Compare multiple flows or relevant device counters when the scenario provides ECMP evidence, and avoid assuming that two equal routes imply a deterministic single next hop.
Routing decisions change over time after a failure
Dynamic routing is not instantaneous. When a link or neighbor fails, devices detect the change, update routing information, calculate alternatives, and propagate new state according to the protocol and design. During that convergence interval, traffic can be dropped, looped, or sent toward stale information.
Time-correlated artifacts are therefore valuable. A routing table captured before a failure, immediately after it, and after convergence can tell different stories. Do not combine them as though they describe one simultaneous state.
A router can make a valid-looking forwarding choice that leads to discarded traffic
A black hole occurs when traffic is forwarded toward a path where it is ultimately discarded or cannot progress. The sending router may have a perfectly valid matching route; the failure can exist farther downstream.
This is why routing-table analysis and path testing answer different questions. The local table tells you what this router intends to do. Traceroute, interface counters, neighboring router tables, and return-path evidence can help determine what happens after the packet leaves.
A loop is different from “no route” because routers keep forwarding the packet
In a routing loop, routers repeatedly send traffic among themselves instead of progressing toward the destination. The IP TTL/Hop Limit prevents indefinite circulation by decreasing at each routed hop until the packet expires.
A traceroute that repeatedly exposes the same small set of routers can support a loop hypothesis, but the strongest diagnosis combines path behavior with routing state on the involved devices. A single timeout is not enough to declare a loop.
Successful outbound routing does not prove the reply can get back
Routing is independently calculated in each direction. Router A's best path toward a server does not force the server-side network to use the same routers in reverse. Asymmetric routing is common and can be completely valid.
But stateful devices complicate the picture. Firewalls and NAT systems may maintain state that expects both directions of a flow to cross the same logical boundary. A reply that takes another path can bypass required state and be dropped even though every router involved has a route.
When a request appears to leave correctly but no reply returns, inspect return routing and stateful-policy dependencies instead of assuming the forward route was wrong.
Do not use path-probe output as a substitute for forwarding-table evidence
Routing table
Shows prefixes, next hops/interfaces, and route information on the inspected device. It supports a prediction about that device's forwarding choice.
Traceroute
Shows responding hop behavior for probes sent toward a destination. Missing replies do not directly reveal a router's table.
If the table predicts next hop B but a trace appears to travel through another visible path, investigate whether the artifacts were captured at the same time, whether ECMP/policy exists, whether the trace's responding addresses represent the interfaces you assumed, and whether routing changed between captures.
24 router path-selection flashcards
Practice longest-prefix matching, route-source selection, metrics, next-hop resolution, ECMP, convergence, black holes, loops, return paths, and evidence boundaries.
A tiny default-route metric does not beat a matching /24
Both prefixes match, but /24 is longer than /0. If both are installed, forwarding uses the /24. Choosing the default because “1 is lower than 90” applies metric reasoning at the wrong stage.
Only after choosing the /24 should you ask whether 10.1.1.2 is reachable and whether downstream/return routing supports end-to-end delivery.
A more-specific route can intentionally send one subnet away from a summary path
The destination matches all three. The /24 wins and sends the packet toward C. That does not mean the /8 or /16 routes are wrong; they continue to serve destinations not covered by a more-specific exception.
A correct forward route can coexist with a broken return path
Client network 10.10.10.0/24 sends toward a server network 10.50.50.0/24. The client-side router has a correct /24 route to the server, and packet capture shows requests arriving at the server. The server's default gateway, however, has no route back to 10.10.10.0/24 and forwards the reply toward an unrelated upstream default.
The forward route was not the failure. The decisive evidence is that requests arrive while replies follow the wrong return routing. The repair belongs on the return-path routing design, not in the client-side longest-prefix decision.
Verify route installation, next-hop usability, forwarding behavior, and return traffic separately
After a routing change, first confirm the intended route is installed with the expected prefix and next hop/interface. Then confirm the next-hop dependency is usable. Test the original destination requirement and, where evidence permits, inspect the downstream and return path.
If the change introduced a more-specific route, also test destinations that should continue using the broader summary or default. If ECMP is involved, test enough flows to avoid declaring success from one hash-selected path.
A routing fix is strongest when it restores the failed traffic without stealing unrelated prefixes or creating a new asymmetric stateful-policy problem.
Use a fixed logical order, but let the artifact tell you which stage is being tested
For packet forwarding from an installed table: write the destination IP, list matching prefixes, choose the longest prefix, identify the next hop/outgoing interface, and keep reachability as a separate question. If the prompt instead presents multiple candidate routes to the same prefix from different sources, apply the stated route-source preference and metric rules first.
Do not claim “the packet arrives” merely because you found a route. Say “this router selects route X toward next hop Y.” End-to-end delivery requires additional evidence.
Turn route tables into predictions, then test those predictions against path evidence
Take a destination and mark every matching prefix. Predict the winning route before looking at an answer. Then state the next-hop dependency and one artifact that would test whether forwarding progresses. Add a second destination that falls outside the most-specific prefix to prove you understand the summary/default fallback.
Continue with Routing Table Analysis Practice for route artifacts and Traceroute Explained for observed path behavior.
Destination-prefix lookup is the baseline model, but a prompt may explicitly introduce policy
Ordinary route-table exercises are solved with destination-prefix logic, but real networks can apply policy that considers additional information before or alongside normal forwarding. If an artifact explicitly shows policy-based routing, a VRF, source-specific rule, or another policy mechanism, do not pretend the ordinary destination-only table is the whole decision.
The important exam habit is to use only the mechanisms supported by the prompt. Do not invent policy routing to explain an ordinary route table, and do not ignore an explicit policy artifact when one is provided. State which decision layer you are analyzing: route candidate selection, destination-prefix lookup, or a separately documented policy that changes the forwarding context.
This boundary prevents two opposite errors: overcomplicating simple longest-prefix questions and oversimplifying a scenario that deliberately supplies policy evidence.
The route code or source can explain why an entry exists and how stable it may be
Routing-table artifacts often identify where an entry came from: connected interface state, static configuration, or a dynamic routing process. That provenance matters during troubleshooting. A static route may persist until configuration changes, while a dynamically learned route can disappear or change as neighbors, topology, or protocol calculations change.
Do not infer more than the code provides. Knowing that a route is static does not prove its next hop is reachable. Knowing that a route is dynamically learned does not prove the destination is healthy. Provenance explains the origin of the routing information; next-hop state and end-to-end tests answer different questions.
When comparing before-and-after tables, provenance can also expose the mechanism of change: a connected route disappearing with an interface failure is different from a dynamic alternative being installed after convergence.