# Route Selection and Metrics

Most routing incidents are not protocol failures. They are two routes disagreeing and the router choosing the one nobody expected. This note is the tie-breaking logic, written down.

## The universal rule comes first

**Longest prefix match always wins**, before any metric, admin distance or policy.

| Routing table | Destination | Chosen | Why |
|---|---|---|---|
| `0.0.0.0/0 via A` | 203.0.113.7 | A | Only match |
| `203.0.113.0/24 via B` + `0.0.0.0/0 via A` | 203.0.113.7 | B | /24 is more specific |
| `203.0.113.0/24 via B` + `203.0.113.0/25 via C` | 203.0.113.7 | C | /25 wins |
| `203.0.113.0/24 via B` + `203.0.113.0/24 via C` | any | tie-break | Metric and distance decide |

Everything below only applies when two routes have **the same prefix length**.

## Administrative distance

When multiple protocols know the same prefix, the router prefers the most trustworthy source.

| Source | Cisco AD | Meaning |
|---|---|---|
| Connected | 0 | Directly attached |
| Static | 1 | You said so |
| eBGP | 20 | Learned from a peer |
| OSPF | 110 | Interior, link-state |
| IS-IS | 115 | Interior, link-state |
| RIP | 120 | Legacy distance-vector |
| iBGP | 200 | Learned inside your AS |
| Unknown | 255 | Never used |

Linux has an analogous concept — `ip route` metric, plus protocol preference — and FRR reproduces the Cisco table.

The practical consequence: **a static route silently overrides OSPF**, which is either the point or the bug. A leftover static route from a migration is one of the most common causes of "OSPF is up but traffic goes the wrong way".

## Metrics inside a protocol

| Protocol | Metric | Grows with |
|---|---|---|
| OSPF | Cost (reference bandwidth ÷ bandwidth) | Fewer/shower links |
| IS-IS | Wide metric | Interface delay/bandwidth |
| RIP | Hop count (max 15) | Each router |
| eBGP | Attribute ladder, not a metric | Policy |

Metrics are only comparable within one protocol. OSPF cost 20 and RIP hop 2 have no relationship at all, which is why redistribution points need explicit control.

## Equal-cost multipath

Two routes with identical preference and metric are installed together, and traffic is hashed across them by a flow hash (usually 5-tuple). Consequences worth knowing:

- **Per-flow, not per-packet** balancing: one elephant flow uses one link.
- **Asymmetric routing** can appear when the hashes differ in each direction — fine for stateless networks, fatal for stateful firewalls.
- **Hash polarisation** with a small number of flows can leave one link idle.

```bash
ip route show                                    # multiple nexthops
ip route get 203.0.113.10                        # which one this flow uses
show ip route 203.0.113.0                        # "2 paths" in IOS
```

## Policy beats metrics

Route-maps, prefix-lists, local preference, BGP communities and PBR all override the ladder above. That is their purpose, and their danger: policy is invisible in a `traceroute` and usually undocumented.

The rule for keeping a network debuggable: **every policy needs a comment, an owner, and a test that fails when it stops doing what it says.**

## Where it goes wrong

- **Two default routes, no metric.** Traffic takes whichever the router installed last, and failover never happens because both are "up".
- **Static route shadowing a dynamic one.** A `/24` static from a decommissioned link stays in the config for years.
- **Recursive routing.** A static route points at a next hop that is itself reachable through the route being replaced — the route disappears when it is needed.
- **Redistribution without a seed metric.** Routes enter with metric 0 or infinity and get dropped or preferred wrongly.
- **Mutual redistribution loops.** A route learned from BGP goes into OSPF, back into BGP, and around again — usually with an AD change that hides it.
- **Prefix-list typo.** `permit 10.0.0.0/8 le 32` versus `permit 10.0.0.0/8` are very different policies.
- **Assuming symmetric routing.** It is not a property of IP; it is a property of the specific design and often an accident.

## Teaching hook

**The sorting-rules analogy.** Post arrives; the most specific address wins first; only when two letters are addressed identically does the "who do I trust more" rule apply. Nothing about distance or preference can override a more precise address.

Exercise: build a six-row routing table on paper and ask which path each of eight destinations takes. Half the class will apply the metric first; that is the lesson.

## Related Notes

- [[Routing/Routing-Fundamentals.md]] — where these routes come from
- [[Routing/OSPF-Fundamentals.md]] — cost in practice
- [[Routing/BGP-And-Internet-Routing.md]] — the BGP attribute ladder
- [[Network-Services/NAT-And-PAT.md]] — where asymmetric routing becomes visible