Topic 4.4 is not route vocabulary—it is reconstructing a router's decision from evidence
A route table is a decision artifact. To read it well, separate several questions that are often collapsed into one: Which prefixes match the destination? Which match is most specific? If there are competing candidates for that prefix, which route source and metric rules apply? Is the selected next hop actually usable? Does observed traffic follow the path you predicted?
This separation prevents a common error: spotting a low metric, a default route, or a familiar next hop and declaring it the winner before determining which destination prefix actually applies.
A strong answer states the decision boundary precisely. “The router has a route” is weaker than “10.50.20.99 matches /8, /16, /24, and /0; the installed /24 is the longest match, so its forwarding instruction is selected.”
Read destination, provenance, next hop, interface, and selection information as separate fields
A destination prefix describes the addresses to which an entry can apply. A next hop names a neighboring Layer 3 forwarding dependency. An outgoing interface identifies where the router intends to transmit. A route code or source can identify whether the information is connected, static, or dynamically learned. Metric or preference fields help explain selection only in their proper context.
| Field | Question it answers | What it does not prove |
|---|---|---|
| Prefix | Which destinations can match? | That the path works |
| Next hop | Which neighbor is the forwarding dependency? | That the neighbor is reachable |
| Interface | Where should transmission leave? | That downstream forwarding succeeds |
| Route source | Where did routing knowledge come from? | That it should beat a more-specific prefix |
| Metric/preference | How are relevant candidates compared? | Universal end-to-end quality |
Swipe horizontally to see the full table.
Use a fixed analysis order so prefix specificity and path preference never get mixed together
This sequence is more valuable than memorizing isolated definitions because it can be applied to unfamiliar route-table artifacts.
Specificity answers “which destination route?” before metric answers “which candidate path?”
The /24 wins because it describes the smallest, most-specific destination set. It is not “faster” than /16 and the number 24 is not a routing metric. Prefix length and metric answer different questions.
Change the destination to 10.50.80.10 and the /24 no longer matches; /16 becomes the most-specific match. Change it to 10.70.1.1 and /8 wins. A destination outside 10.0.0.0/8 falls to the default if no other specific route exists.
Why prefix length changes the match without measuring performance
A prefix fixes a number of leading address bits. A /24 fixes more destination bits than a /16, so it describes a narrower set of addresses. Longest-prefix matching therefore chooses precision, not speed.
This distinction matters when a prompt places a very low metric beside a broad route and a higher-looking value beside a more-specific route. Do not let the visually attractive metric distract you from the destination lookup.
Connected routing knowledge depends on local Layer 3 interface state
If an operational router interface is configured as 172.20.40.1/24, the device can represent 172.20.40.0/24 as directly connected. It does not need another router as the Layer 3 next hop for hosts on that network.
Connected does not mean every endpoint is reachable. A host can be offline, in the wrong VLAN, filtered, or misaddressed. The route proves a local network relationship, not endpoint health.
If the Layer 3 interface goes down, the connected route can disappear, which may also affect dynamic advertisements or static next-hop dependencies that relied on that interface.
Static describes provenance, not correctness or liveness
A static route is deliberately configured. It can be ideal for a stable edge or explicit path, but configuration intent is not self-validating. The prefix can be wrong, the next hop can be obsolete, or downstream reachability can fail.
When a static route appears, ask three questions independently: Does it match the destination? Does it win the lookup? Can its forwarding dependency actually be used? For a deeper comparison, see Static vs Dynamic Routing.
A dynamically learned route is a time-sensitive statement about control-plane knowledge
Dynamic routing processes exchange or derive reachability and select paths according to protocol and platform rules. When topology changes, a learned route can disappear, change next hop, or be replaced by an alternate after convergence.
Capture time therefore matters. A table from 13:59 and another from 14:02 may both be accurate if a link failed at 14:00. Do not combine different snapshots as though they describe one simultaneous routing state.
Competing sources for an otherwise comparable prefix require a source-selection rule
A device can know the same prefix from connected state, static configuration, or one or more routing processes. Platforms commonly have a preference mechanism—often called administrative distance or route preference—to decide which source is favored when appropriate candidates compete.
Exact values can be platform-specific. More importantly, this is not a replacement for longest-prefix matching. A preferred source for a /16 does not magically make that /16 more specific than an installed /24.
A routing metric is meaningful only inside the mechanism that calculated it
Protocols can evaluate paths using hop count, bandwidth-derived cost, delay-related information, or other attributes. The metric helps the routing process compare eligible paths according to that protocol's rules.
Do not treat all metric values as one universal scoreboard. “20 is lower than 50” is not sufficient reasoning if the numbers come from unrelated mechanisms. First identify the route source and the selection rule the artifact actually supports.
Multiple valid next hops can exist without creating a routing error
Some devices can install or use multiple equal-cost paths. Traffic distribution can depend on platform behavior and may preserve individual flows on one path while other flows use another.
Two legitimate traces taking different routes therefore do not prove a loop. A loop requires evidence of repeated forwarding behavior or another mechanism that sends packets around a cycle. Equal-cost alternatives are multiple ways forward.
The default is a fallback, not an emergency second choice after a specific route fails
A default IPv4 route, 0.0.0.0/0, matches every IPv4 destination but is less specific than any longer matching prefix. It is commonly useful at an edge with one general upstream direction.
If a selected /24 points to an unusable next hop, a router does not normally say “that failed, so I will try /0” merely because the default is healthy. The more-specific route must be removed, become ineligible, or otherwise cease to control the lookup according to the routing design.
A broken specific route explains why general Internet access can work while one network fails
The successful Internet control proves the default path can work for at least that tested destination. It does not prove 10.90.30.25 uses the default. The /24 captures that destination first. Test 192.0.2.99 and inspect why the specific route exists.
A route-table row can be correct syntactically while forwarding still stops at the next hop
After selecting the winning route, identify what must be true for forwarding to continue. A next-hop address may require a connected path and local neighbor resolution. An outgoing interface must be operational. The next router must then have its own usable route.
This is why route-table presence is bounded evidence. It proves local forwarding knowledge in the captured state; it does not prove every downstream device agrees.
The routing table predicts a local decision; traceroute samples responding behavior along a path
A local routing table tells you what the local router intends to do for a destination. Traceroute can expose routers that return TTL/Hop-Limit-expiration diagnostics as probes progress.
Hop 3 did not answer the probes, but later hops did. Therefore the asterisks do not prove forwarding stopped at hop 3. Compare traceroute with route and reachability evidence rather than treating silence as a dead router.
Proving the forward path does not prove the return path
A client-to-server trace can follow routers A→B→C while replies return C→D→A. That asymmetry can be normal. It becomes important when a stateful firewall, policy boundary, or missing reverse route affects only one direction.
If server-side evidence proves requests arrive but the client receives no response, stop repeatedly changing the already-proven forward route. Inspect server response, return routing, and policy on the reverse direction.
Both can cause timeouts, but their path evidence is different
A routing loop repeatedly forwards packets among routers until IPv4 TTL or IPv6 Hop Limit reaches zero. A blackhole drops traffic or forwards it into a path from which useful delivery does not continue.
Traceroute may reveal repeated hop patterns for some loops, but diagnostic filtering can complicate the picture. The stronger method is to combine route tables from the involved devices with path observations and identify the contradictory forwarding decisions.
A path change after failure can be correct behavior, not instability
In a redundant dynamic design, a primary link failure can cause the preferred route to disappear and an alternate route to be installed. The interval required to detect the change, exchange/update routing information, calculate alternatives, and update forwarding state is part of convergence.
A before/after traceroute can legitimately show different hops. If service recovers through the designed alternate, the path change is evidence of adaptation. If routes oscillate repeatedly without a stable event, investigate link flapping, neighbor instability, or changing routing information.
Do the lookup before touching the metrics
All three prefixes match, but /24 is longest. No metric comparison between the /12 and /24 is needed to decide which destination entry applies. For 172.22.5.5, /24 does not match and /12 wins. For 8.8.8.8, only the default matches.
Same prefix candidates require a different question than different prefix lengths
Suppose an artifact shows two eligible candidates for 10.60.0.0/16 from the same routing process with different path metrics. Now specificity does not separate them because the destination prefix is identical. Apply the protocol's stated path-selection rule.
If the same /16 instead arrives from different route sources, route-source preference may determine which candidate is installed before protocol metric is relevant. The exact artifact should tell you which comparison you are being asked to make.
Server receipt moves the evidence boundary to the return side
A client at 10.10.8.25 sends a request to a server. Router tables show a valid forward route, and a server packet capture records the request arriving. The client times out.
The capture is powerful evidence: the forward path succeeded for that request. The next high-information checks are whether the server generated a response, whether its default gateway/route can return to 10.10.8.0/24, and whether reverse-path policy allows the response. Reconfiguring the client's proven forward route is now a low-value move.
Match the routing symptom to the artifact that can reduce uncertainty fastest
| Observation | What it supports | What remains open | High-value next evidence |
|---|---|---|---|
| Route installed | Local forwarding knowledge exists | Next-hop/downstream success | Next-hop state/test |
| One prefix fails, Internet works | Failure is selective | Specific route/policy/path | Exact destination lookup |
| Traceroute has one silent hop, later hops answer | Forwarding progressed beyond silence | Why hop suppressed response | Destination result + route evidence |
| Request reaches server | Forward delivery occurred | Response and reverse path | Server response + return route |
| Route changes after link failure | Routing state adapted | Whether service recovered as designed | Timestamped route/path tests |
Swipe horizontally to see the full matrix.
Use a control destination to distinguish broad routing failure from prefix-specific failure
If 10.90.30.25 fails, test another destination that should use the same broad upstream path but not the suspect /24. A successful control narrows the fault: local IP, gateway, and at least part of upstream forwarding may be working while the specific route remains suspect.
Controls are especially useful after changes. Verify the intended destination improved without silently diverting unrelated traffic.
24 Topic 4.4 routing metrics and paths flashcards
Use these as decision cards, not vocabulary cards. Predict the answer, reveal it, then state what evidence would prove the claim in a real route-table scenario.
A routing change is not verified when the command is accepted—it is verified when forwarding behavior matches the requirement
After adding or changing a route, confirm active routing state, the winning lookup for the target, next-hop usability, target reachability, and an unrelated control path. If the purpose is resilience, trigger the relevant failure in a controlled environment and prove that the alternate path becomes usable.
Record before/after artifacts when possible. A route-table delta plus path test explains the mechanism far better than “it works now.”
Write one compact chain: destination → prefix → selection → dependency → evidence
For a routing artifact, begin with the exact destination. Mark every matching prefix. Select the longest. If multiple relevant candidates remain, apply the supplied source and metric rules. State the chosen next hop or interface. Then identify one test that could disprove the predicted forwarding behavior.
This produces evidence-based reasoning instead of route-table pattern matching. It also keeps you from overclaiming: a selected route predicts the local forwarding decision; it does not prove the application, remote host, firewall, or return path.
Routing metrics become more useful when connected to CLI, monitoring, and reliability evidence
Topic 4.4 sits naturally between Topic 4.3 Network CLI Tools and Topic 4.5 Network Monitoring and Defense. CLI tools expose route/path behavior; monitoring adds timestamps and change history; reliability asks whether alternate paths recover service.
Continue into Topic 4.6 Network Reliability and Growth to connect path selection to redundancy and scaling.