A routing table is a set of forwarding claims, not a map of guaranteed reachability
A routing table tells you which destination prefixes a device knows and how it intends to forward traffic toward them. The fastest way to read one is field by field: destination prefix, route source, next hop, outgoing interface, preference or metric information, and status.
When two routes look plausible, calculate which prefixes actually contain the destination before comparing their paths. The AP Networking Routing and Default Gateway Practice Test gives repeated but distinct lookup decisions, followed by source-specific and return-path cases that a table alone cannot resolve.
If a row says 10.40.0.0/16 via 192.0.2.2, you can state that the represented route directs matching traffic toward 192.0.2.2. You cannot yet state that 10.40.0.0/16 is reachable. The next hop may be down, another router may lack a route, a firewall may drop the flow, or the return path may be missing.
This distinction is the foundation for strong routing-table analysis: first identify the local forwarding decision; then identify the next unresolved dependency.
Translate every row into six questions before you decide what it means
| Field | Question it answers | Example | Common overclaim |
|---|---|---|---|
| Destination prefix | Which destination IPs can this route match? | 10.20.30.0/24 | “Every host in that subnet is online.” |
| Route source | Why does this route exist? | Connected, static, dynamic | “Dynamic automatically means better.” |
| Next hop | Which neighboring router is the intended next target? | 192.0.2.2 | “The next hop is definitely reachable.” |
| Outgoing interface | Which local interface should transmit? | Gi0/1 | “The link is healthy.” |
| Preference / metric | How do relevant competing candidates rank? | Platform or protocol values | “The smallest number in the table wins.” |
| Status / age | What does the display reveal about current route state? | Platform-specific | “An older route is wrong.” |
Swipe horizontally to see the full table.
The prefix is a range test, so verify whether the destination actually belongs
A route to 10.20.30.0/24 applies only to addresses inside that /24. A route to 10.20.0.0/16 covers a broader range. Routing tables are not matched by familiar-looking numbers or network names; the destination bits must fall inside the prefix.
For destination 10.20.31.7, 10.20.30.0/24 is not a candidate even though the first two octets are identical. This is where subnetting becomes a routing skill: knowing the actual prefix boundary determines which rows participate in the lookup.
A connected route anchors the table to a local Layer 3 interface
If an operational interface is configured as 10.10.20.1/24, the router can represent 10.10.20.0/24 as directly connected. Traffic for that network does not need another router as the Layer 3 next hop; the device can deliver onto the attached network after local neighbor resolution succeeds.
Connected does not mean “all devices in this subnet are reachable.” A destination host can be offline, in the wrong VLAN, filtered, misaddressed, or unreachable at Layer 2. The route proves the router has a local relationship to the network, not that every endpoint inside it is healthy.
Static describes provenance, not correctness
A static route is deliberately configured. Its origin is easy to explain, but it is not self-validating. An administrator can configure the wrong prefix, the wrong next hop, or a next hop that later becomes unreachable.
When a static route appears in an artifact, ask three separate questions: does its prefix match the failing destination, does it win the lookup, and can the forwarding dependency named by the route actually be used? That keeps configuration intent separate from delivery evidence.
A dynamic route represents routing-process knowledge at a particular moment
Dynamic routing protocols exchange reachability information and calculate paths. A table may identify the source protocol and values used in route selection. During a topology change, the installed route can change as neighbors disappear, links fail, and the network converges on an alternative.
This makes capture time important. A table recorded before a failure and one recorded after convergence can legitimately show different next hops. Do not combine snapshots from different timestamps as though they describe one simultaneous routing state.
For the broader design difference, see Static vs. Dynamic Routing.
Find every matching installed prefix, then choose the most specific one
The /24 wins because it fixes more destination-prefix bits than /16, /8, or /0. This is not a “lowest metric” rule. It is destination specificity.
A reliable method is to write the destination first, mark every matching prefix, compare prefix lengths, and only then read the forwarding instruction attached to the winning row.
A broad route can remain valid while a narrower route overrides one slice of it
Suppose 172.16.0.0/12 points toward a regional core while 172.20.44.0/24 points toward a security appliance. Destination 172.20.44.9 matches both, but the /24 wins. A destination elsewhere inside the /12 that lacks a more-specific route still uses the summary.
This creates a powerful troubleshooting clue: one subnet can fail because of its specific route while nearby destinations covered by the same summary continue working normally.
A metric is not a universal score attached to every route in the table
Routing systems can use route-source preference and protocol-specific metrics when deciding which candidate route to the same destination prefix becomes active. Different protocols can calculate metrics differently, so arbitrary numbers from unrelated protocols should not be treated as one universal ranking system.
For packet forwarding from an installed table, destination specificity still governs the match. If an installed /24 with metric 100 and an installed /16 with metric 10 both match the destination, the /24 applies to addresses inside that /24.
For the deeper route-selection sequence, use How Routers Choose Paths.
“Via 192.0.2.2” creates another routing dependency
A route can identify a next-hop IP instead of a final directly connected destination. The router must determine how to reach that next hop. If the next hop sits on a connected network, local neighbor resolution can provide the Layer 2 delivery information. In other cases, another route lookup may be required to resolve the next hop recursively.
This is why the presence of a row is not enough. A perfectly matched prefix can still fail because its next-hop dependency is unusable, its outgoing interface is down, or the neighbor cannot be resolved.
The exit interface connects Layer 3 route choice to a concrete local forwarding boundary
Some tables show both next hop and outgoing interface; connected routes may emphasize only the interface. The outgoing interface tells you where the device intends to transmit matching traffic.
If that interface is down, assigned to the wrong routing context, unable to reach the expected next hop, or physically disconnected, the forwarding plan cannot operate as intended. Interface health is therefore separate evidence rather than something you should infer merely because the route row exists.
0.0.0.0/0 is a fallback route, not an automatic Internet guarantee
A default route matches every IPv4 destination because it fixes zero destination-prefix bits. It becomes useful only when no more-specific installed route matches. Hosts and edge routers commonly use defaults so they do not need explicit routes for every remote network.
A missing default can produce a distinctive pattern: connected networks and explicitly routed destinations work, while other remote destinations fail. Conversely, a bad more-specific route can break one subnet even when the default route is perfectly usable because the specific route wins first.
See Default Route Explained for more design and failure cases.
One routing table can produce four different forwarding choices
| Destination | Winning prefix | Next hop | Why |
|---|---|---|---|
| 10.20.30.99 | 10.20.30.0/24 | 192.0.2.2 | /24 is the longest match |
| 10.20.40.99 | 10.20.0.0/16 | 192.0.2.3 | Destination does not match the /24 |
| 10.99.1.5 | 10.0.0.0/8 | 192.0.2.4 | Destination does not match /24 or /16 |
| 203.0.113.8 | 0.0.0.0/0 | 192.0.2.1 | No more-specific listed route matches |
Swipe horizontally to see the full table.
A stale specific route can defeat a healthy default route
A router reaches many remote destinations through its default route, but 10.70.40.0/24 fails. The table contains 10.70.40.0/24 via 192.0.2.99, and that next hop is no longer reachable.
The default is not selected for 10.70.40.x because the /24 is more specific. The correct interpretation is not “there is a default, so routing is fine.” The failing subnet has its own winning route, and that route creates the broken dependency.
After repair, verify both 10.70.40.0/24 and a destination that should still use the default. That confirms the specific fix without assuming unrelated forwarding remained intact.
Keep six major uncertainties open even after you identify the winning route
Next-hop health
A next-hop address in the table is not an adjacency test.
Downstream routing
The next router can make a different or failing decision.
Return path
Replies need independent routing back toward the source.
Firewall policy
A valid route can lead directly to a policy drop.
NAT behavior
Translation state can fail independently of route selection.
Application health
Reachable IP endpoints can still have unavailable services.
Routing tables predict local forwarding; traceroute observes responding probe behavior
A routing table is device-local route/forwarding evidence. Traceroute sends probes and reports responding hops based on TTL or Hop Limit behavior and the network's diagnostic-response policy. They complement each other but are not interchangeable.
A traceroute asterisk does not directly mean “this router has no route.” Likewise, a route-table entry does not mean the trace must show a clean path. If the artifacts seem inconsistent, check timestamps, ECMP, policy, interface addressing, and whether the visible traceroute addresses actually represent the path assumptions you made.
Use Traceroute Explained for the path-observation side of the evidence.
A routing table is a snapshot, and convergence can change the correct answer seconds later
Dynamic networks change. Interfaces fail, neighbors disappear, routing protocols withdraw routes, and alternatives can be installed. A table captured at 10:00:01 and another at 10:00:20 may legitimately disagree during convergence.
Preserve timestamps when comparing artifacts. A route disappearing immediately after a link failure may be the evidence you need. A new route appearing after convergence may explain restored connectivity. Do not silently merge snapshots into an imaginary table that never existed at one time.
24 routing-table interpretation flashcards
Practice route fields, connected/static/dynamic provenance, longest-prefix matching, metrics, next-hop resolution, defaults, artifact boundaries, and troubleshooting decisions.
Use the table to narrow the failure, not to end the investigation prematurely
Start with the exact failing destination. Determine which route should win and identify its next hop or interface. Then test the dependency named by that route. If the next hop is usable, move downstream instead of repeatedly rereading the same local table.
If many destinations work but one prefix fails, inspect the specific route for that prefix. If all unknown remote destinations fail while connected and specifically routed networks work, inspect the default route. If the table changed around the failure time, compare route provenance and interface state.
The goal is a boundary statement such as: “The local router selects the expected /24 and reaches its next hop; the next unresolved boundary is downstream forwarding.” That is much more useful than “routing looks okay.”
No matching route and no default is a different failure from a broken next hop
If the destination matches no installed prefix and no default route exists, the router has no forwarding entry to use. That is different from a case where the correct prefix is present but points toward an unreachable next hop.
The repair path differs too. In the first case, investigate why required routing information is missing: configuration, interface state, dynamic route learning, filtering of routing information, or another control-plane dependency. In the second, the route exists and the failure lies in its forwarding dependency.
Keeping “no route” separate from “route present but unusable” prevents unnecessary edits to the wrong part of the network.
Route-source preference belongs to candidate selection, not ordinary longest-prefix lookup
A routing device can learn the same prefix from more than one source. The platform may use an administrative preference or distance concept, followed by routing-protocol rules and metrics, to decide which candidates become active.
If the artifact already shows the installed routing table, your packet-forwarding task is usually to choose the longest matching installed prefix. If the prompt instead shows multiple candidate routes to the same prefix, then route-source preference and metric information become part of the selection problem.
This distinction is essential because it keeps students from applying administrative distance to unrelated prefixes or applying longest-prefix logic before the table-selection stage is complete.
Annotate the table instead of trying to solve it mentally
Write the destination beside the artifact. Mark each matching prefix. Cross out nonmatches. Circle the longest prefix. Then copy the next hop or outgoing interface from that row. If the prompt supplies multiple candidates to the same prefix, apply the stated preference and metric context at the route-selection stage.
Finally, phrase the conclusion narrowly: “This router selects X via Y.” If the question asks whether communication succeeds, look for next-hop, downstream, return-path, firewall, NAT, or service evidence before extending the claim.
Change the destination and watch the winning row change
Take one four-route table and test a destination inside the /24, one inside the /16 but outside the /24, one inside only the /8, and one outside all three. Then deliberately break the next hop for only the /24. You now have a strong troubleshooting contrast: broad routing works, but the most-specific route for one destination range leads to failure.
That single exercise connects subnet boundaries, longest-prefix matching, default fallback, next-hop dependency, and evidence limits without reducing the topic to isolated definitions.
Move from table reading into route selection and path evidence
Read the evidence. Make a decision. Check your reasoning.
Use these connected resources to move from an explanation to a real networking decision.