A routing table answers one local question: what should this device do next?
A route table is not a map of the entire network. It is the forwarding device's current set of instructions for choosing an outgoing path from this point in the network.
For a destination IP, begin by identifying every route whose prefix contains that destination. Among those matches, the most specific prefix normally wins: the route with the longest prefix length. Only after you understand which routes are truly competing should you interpret route-source preference, administrative preference, metrics, or equal-cost behavior shown by the platform or artifact.
Then identify what the winning entry tells the device to do: deliver directly through a connected interface, forward toward a next-hop address, or use a default fallback. Finally ask whether that next action is actually usable. A route can look syntactically correct while pointing to an unreachable next hop or a down interface.
Specificity beats a broader route—even when the broader route looks easier
Destination 10.20.30.140 matches the /8, /16, /24, /25, and default. The /25 wins because 10.20.30.140 lies inside 10.20.30.128/25 and /25 is the longest matching prefix. Destination 10.20.30.77 does not lie inside the upper-half /25, so the /24 becomes its longest match. Destination 10.20.40.10 misses the /24 and /25 but matches the /16.
This single table demonstrates why route reading requires both subnet boundaries and comparison. A very low metric on the /8 would not make it beat a matching /24 or /25. Metrics do not erase prefix specificity.
Analyze any routing-table artifact in six passes
Do not reason from a vague phrase such as “the remote LAN.” Use the actual destination IP.
Include connected, static, learned, host, summary, and default entries that genuinely contain the destination.
A /32 beats /25; /25 beats /24; /24 beats /16; all specific matches beat /0.
If competing candidates are for the same prefix, then source preference, administrative values, metrics, or platform rules may matter.
Identify outgoing interface, direct delivery, and/or next hop.
Can the device reach the next hop? Is the interface usable? Does the return path exist? What evidence would disprove your path prediction?
“Directly connected” changes the next-hop question
For destination 172.16.8.55, the connected /24 is more specific than the static /16 and default. The router sends toward that connected network through Gi0/1 rather than handing the packet to the 10.0.0.2 next hop.
On Ethernet, “directly connected” does not mean the device somehow knows the destination's Layer 2 address without work. It means no additional routed next hop is required for that IP prefix; the device can use the local-link neighbor-resolution process appropriate to the network.
This distinction matters in troubleshooting. If the route is correct and connected but the interface is down, VLAN attachment is wrong, or neighbor resolution fails, adding another static route may not repair the actual problem.
24 routing-table analysis flashcards
These cards mix quick prefix decisions with artifact interpretation. Filter the deck to isolate longest-prefix matching, next-hop logic, metrics, return paths, or troubleshooting.
A default route can hide a missing internal route by forwarding traffic somewhere
For 10.30.5.9, no displayed 10.30.5.0/24, 10.30.0.0/16, or other specific matching route exists. The default therefore wins. If 10.30.5.0/24 is supposed to be an internal network reachable through another internal router, the table can send that traffic toward the wrong edge.
This produces an important troubleshooting distinction: “a matching route exists” is not the same as “the intended route exists.” The default matches every IPv4 destination, so it can make a missing-specific-route problem less visually obvious.
When a known internal network unexpectedly follows the default, ask which more-specific route should have captured it and why that route is absent, inactive, misconfigured, or no longer learned.
A destination route is useless if its next forwarding step cannot be reached
The first line appears to provide a route for 192.168.80.0/24. But the displayed connected network is 10.20.40.0/24, not 10.20.30.0/24. Unless another route not shown provides a path to 10.20.30.2, the next hop itself may be unreachable.
That makes route analysis a two-stage problem: choose the destination route, then validate its forwarding action. Depending on the platform, recursive route lookup, adjacency information, interface state, or next-hop resolution may determine whether the route is usable.
In an exam artifact, do not invent missing information. State the conditional clearly: the static route names 10.20.30.2, but the shown table does not establish reachability to that next hop. Additional route/interface evidence is required.
Know when a metric matters—and when it absolutely does not
| Situation | First question | Does metric decide immediately? |
|---|---|---|
| Matching /24 and /16 | Which prefix is longer? | No. /24 wins on specificity. |
| Two candidates for the same /24 | Are route-source/preference rules relevant? | Possibly, after the platform's source-selection rules. |
| Two comparable paths from the same routing process | What metric/cost does the artifact provide? | Often yes, according to that protocol/platform. |
| Default and any matching specific route | Does the specific prefix contain the destination? | No. The specific route beats /0. |
Swipe horizontally to see the full table.
Administrative distance, preference, and metric terminology varies by platform. The safe reasoning order is to use the fields actually shown and avoid pretending that one vendor's display rules apply universally. The Routing Metrics Explained page develops that distinction.
The prefix length can make a route capture too much—or almost nothing
A route intended for 10.40.20.0/24 but entered as 10.40.0.0/16 covers 256 times as many /24-sized address blocks. It can capture destinations that were supposed to follow other routes. The next hop may be perfectly reachable, yet the route is still wrong because its match set is too broad.
The opposite error can be just as selective. A mistaken host route such as 10.40.20.77/32 overrides a correct 10.40.20.0/24 only for .77. Other hosts in the /24 can work normally, making the failure look like a server-specific problem. Longest-prefix matching explains the selectivity.
This is why routing troubleshooting should compare the failed destination with a nearby working control. If 10.40.20.76 works and .77 fails, inspect whether an unusually specific route, policy, or host-specific condition changes the path for .77.
A correct forward route can deliver a request into a one-way conversation
Client 10.20.4.10 sends to server 10.60.8.20. Router A can forward toward Router B, and Router B has the server network connected. That proves a plausible forward path. It does not prove that Router B knows how to send a reply toward 10.20.4.10.
For bidirectional application communication, analyze the return destination separately. The reply's destination is now 10.20.4.10. Ask which route Router B would select for that address. A suitable default might solve it, but if no such route is shown, the artifact does not establish a return path.
This is one of the most important limits of a single routing table: it describes one device's decisions. End-to-end connectivity can require multiple forwarding decisions in both directions.
Work a five-destination table without changing any configuration
10.20.30.140
Matches /8, /16, /24, /25, /0. Winner: /25 via 172.16.0.4 on eth2.
10.20.30.77
Matches /8, /16, /24, /0 but not upper-half /25. Winner: /24 via 172.16.0.3.
10.20.40.10
Matches /8, /16, /0. Winner: /16 via 172.16.0.2.
10.99.1.5
Matches /8 and /0. Winner: /8 via 172.16.0.1.
192.168.50.44
Matches connected /24 and /0. Winner: connected /24 through eth3.
203.0.113.9
No specific entry matches. Winner: default via 192.0.2.1.
Now turn each answer into a complete statement: name the matching routes, the winning prefix, the forwarding action, and one piece of evidence needed to establish that the next step is actually usable. That last sentence prevents route analysis from becoming a purely mathematical exercise.
What the routing table proves—and what it leaves unresolved
It can prove locally
Which displayed prefixes match, which is most specific, which next hop/interface is selected, whether an intended route is missing from the artifact, and whether a suspicious host or summary route changes the local decision.
It cannot prove alone
That the next router forwards correctly, a firewall permits the flow, the destination service is listening, the return path exists, or the application succeeds end to end.
Use other evidence only when the question extends beyond the local decision. Traceroute can add path observations; CLI Output Practice helps combine commands; neighboring routing tables can reveal the next forwarding decision; and service tests can establish whether transport/application dependencies work.
Write route answers as a causal chain, not a route name
Instead of answering “use the /24,” explain: “10.40.20.77 matches 10.40.0.0/16, 10.40.20.0/24, and 0.0.0.0/0. The /24 is the longest matching prefix, so the router forwards toward its listed next hop. The /16 metric is irrelevant to this comparison because it is less specific.” That answer exposes the reasoning and makes distractors easier to reject.
For a fault, extend the chain: “The intended 10.30.5.0/24 entry is absent, so 10.30.5.9 falls to the default route toward the edge. Verify whether the /24 should be learned or statically configured, restore the intended route, then confirm the selected next hop and return path.”
Notice what is not included: random route additions, DNS changes, switch replacement, or claims about downstream devices not shown in the evidence. Strong artifact analysis is disciplined about both what the table supports and what it does not.
Route tables become more revealing when the obvious answer is not the whole answer
Summary route side effect
A broad summary can legitimately represent many networks, but it can also attract traffic for a subnet that is not actually reachable behind the summarizing router. When the table contains a summary, ask whether the failed destination is truly part of the reachable design, not merely whether its bits match the prefix.
Stale-looking information
An artifact may show a route that no longer reflects the physical or logical topology described elsewhere in the scenario. Treat conflicts between the table and current interface/path evidence as something to investigate. A displayed route is evidence of the device's state, not proof that the state is correct.
Asymmetric path
The forward and return packets do not have to traverse identical routers. Asymmetry is not automatically a fault. The important question is whether each direction has a valid permitted path and whether any stateful device on those paths requires traffic to be observed in a particular way.
A useful exam response distinguishes route selection from route correctness. You may be able to prove exactly which entry wins while simultaneously concluding that the winning entry sends traffic somewhere unintended. Longest-prefix matching predicts what the device will do; network design evidence tells you whether that behavior is desirable.
For example, a mistaken 10.50.0.0/16 static route may correctly win over a 10.0.0.0/8 summary for destination 10.50.8.20. The router is following its table correctly even though the table is configured incorrectly. Troubleshooting must preserve that distinction or the technician may waste time looking for a failure in the forwarding algorithm.
Use paired destinations to expose exactly where a route changes
One of the fastest ways to understand a complicated table is to choose two destinations that differ only at an important prefix boundary. With a route for 10.20.30.128/25 layered over 10.20.30.0/24, compare 10.20.30.127 and 10.20.30.128. The first cannot match the upper-half /25; the second can. If the entries point to different next hops, those two addresses should produce different local forwarding decisions.
This technique is valuable because it converts abstract CIDR notation into a controlled experiment. Instead of testing random hosts, select addresses immediately on opposite sides of the boundary. If observed forwarding disagrees with the table you were given, look for information not yet accounted for: a more-specific route, policy-based routing, a different table/VRF, stale output, or an artifact captured from the wrong device.
You can use the same method with a /16 and /24. Pick one destination inside the /24 and another that remains inside the /16 but falls outside the /24. The pair forces the route-selection difference to become visible. This is subnetting used as an artifact-analysis tool rather than as isolated arithmetic.