Prefix specificity, route-source preference, and metric are not interchangeable
Students often see several numbers in a routing table and assume the smallest number always wins. Routing decisions are more structured. The router first deals with destination specificity, then with competing ways to reach the same prefix, and only then does metric become meaningful within the relevant set.
Use this order when a question gives you several route values
A routing metric is a protocol-specific idea of path cost
A metric is not a universal physical measurement. It is the value a routing protocol or routing process uses to rank candidate paths under its own rules.
Hop count
Some protocols prefer paths with fewer routing hops.
Link cost
Other protocols use configured or calculated link costs, often influenced by bandwidth or design intent.
Composite ideas
Some routing systems can consider multiple properties such as bandwidth, delay, or other configured values.
Metrics matter most clearly when candidate paths describe the same destination prefix
Because the prefix and route source are comparable, metric is now a meaningful discriminator.
A lower metric does not beat a more-specific route
The /24 wins because longest-prefix matching occurs before metric comparison. The /16's lower metric is irrelevant for this destination as long as the /24 route is active.
Administrative preference is about trust in how a route was learned
A router may learn the same prefix from a connected interface, static configuration, or multiple routing protocols. It needs a rule for deciding which source is preferred. Different platforms use different terminology and default values, so AP Networking questions should rely on the preference information provided in the prompt rather than treating one vendor's numeric table as universal.
Same prefix, different route sources
The metric inside the dynamic protocol never gets a chance to compete if the route-source rule already selects the static route for that same prefix.
Same source, same prefix, different metric
Now the metric is directly relevant because the candidate routes are otherwise comparable.
Equal metrics can result in multiple active next hops
Many routers can install multiple equal-cost paths when route source, prefix, and cost tie. Traffic may then be distributed across those next hops.
This is called equal-cost multipath behavior in many environments. It can improve resilience and capacity, but it can also mean different flows take different paths.
Traffic can move even when no physical link fails
Nothing had to go physically down. A metric change alone can alter the preferred path.
A metric problem and a reachability problem are different failure classes
Preference problem
Traffic reaches the destination, but it takes an undesired or expensive path. Metric or routing policy may need adjustment.
Reachability problem
The route is missing, next hop is unreachable, interface is down, or return path is broken. Metric tuning alone may not fix anything.
Before changing metrics, identify why the current path is installed
If the wrong prefix is winning, metric tuning may be irrelevant. If the desired route is absent entirely, changing another route's metric does not magically create the missing route.
What a metric value proves—and what it does not prove
| Artifact | Supports | Still unproven |
|---|---|---|
| OSPF path cost 10 | Protocol-assigned path cost | That the route wins over a more-specific prefix |
| Lower metric than another same-prefix OSPF path | Preference within that comparable OSPF set | End-to-end application success |
| Equal-cost next hops | Multiple equally preferred paths may be installed | Every packet uses both paths equally |
| Metric changed after configuration | Routing preference may shift | That a physical fault caused the shift |
| Preferred route installed | Control-plane selection succeeded | Next-hop and return-path health |
Swipe horizontally to see the full evidence-boundary table.
The best route can be selected correctly and forwarding can still fail
The routing process may choose the intended route based on prefix, preference, and metric. But actual packet forwarding still depends on interface state, next-hop resolution, neighboring devices, security policy, and the return path.
Lower metric path exists, but the next hop is unreachable
The metric comparison correctly chooses the lower-cost path, but forwarding fails at the next-hop boundary. This is why route selection and route usability must stay separate.
More-specific route overrides a “better” metric on a broader route
Metric 1 does not rescue the /8 because the /24 is the more-specific match.
Route source preference beats metric when the sources are different
The dynamic metric of 1 looks attractive, but it is evaluated inside the dynamic protocol's path set. Route-source preference already decided which source wins for the same prefix.
“Metric” means whatever the protocol defines it to mean
| Metric style | What it emphasizes | Student caution |
|---|---|---|
| Hop count | Number of routing hops | Fewer hops do not always mean more bandwidth or lower delay. |
| Link cost | Protocol/configured path cost | Cost may be abstract rather than measured latency. |
| Bandwidth-sensitive | Capacity characteristics | Do not assume the value is raw Mbps. |
| Composite | Multiple path properties | Interpret according to the protocol/prompt. |
Swipe horizontally to compare metric styles.
Change one fact and watch which decision stage changes
Change #1: prefix
Original: two /24 OSPF routes compete by metric. Changed fact: one becomes /25 and matches the destination. Result: prefix specificity decides before metric.
Change #2: route source
Original: two OSPF paths compete by cost. Changed fact: one route is static and the prompt says static is preferred. Result: route-source preference decides first.
Change #3: metric
Original: equal-cost paths both install. Changed fact: one cost rises. Result: only the lower-cost path remains preferred.
Change #4: next hop
Original: lower-cost route forwards successfully. Changed fact: its next hop becomes unreachable. Result: route usability becomes the troubleshooting boundary.
Use the route artifact to identify the right question
| Observation | Likely issue | Best next check |
|---|---|---|
| Wrong prefix chosen | More-specific route exists | Prefix lengths and route table |
| Right prefix, wrong source | Route-source preference | Administrative/preference values |
| Right source, undesired path | Metric/cost selection | Protocol metric values |
| Preferred route selected but traffic fails | Next-hop/data-plane problem | Neighbor/interface/ACL/return path |
| Two equal-cost paths active | ECMP behavior | Forwarding hash/path observations |
Swipe horizontally to see the troubleshooting matrix.
Reject these tempting but incomplete rules
- “Lowest number always wins.”
- “Metric is checked before prefix length.”
- “A static route always wins everywhere.”
- “A lower metric guarantees end-to-end reachability.”
- “Equal metrics mean packets alternate perfectly 50/50.”
- “A path change must mean a physical failure occurred.”
- “Metric values can always be compared across different routing protocols.”
Build answers in this order
Solve a mixed route-selection table without skipping stages
First choose the /24 because it is the longest matching prefix. Then compare the two OSPF /24 paths. They have the same route source and preference, so metric becomes decisive: cost 10 wins over cost 50. The static /8 never competes because it is less specific for this destination.
24 routing-metric digital flashcards
Practice prefix specificity, route-source preference, protocol metric, ECMP, path tuning, evidence boundaries, and troubleshooting logic.