Dynamic routing protocols and route selection

Why this matters

This lesson answers the question that sits under every routing problem: when a router knows more than one way to reach a destination, how does it choose?

Route selection has a strict order, and knowing it turns a whole category of exam questions into arithmetic. It is also where a genuinely common misconception lives — that the "best" route is the one with the best metric, which is only true after two other tests have already been applied.

The lesson

OSPF

OSPF (Open Shortest Path First) is the standards-based interior gateway protocol, and a link-state design.

Link-state means each router does not simply take its neighbours' word for distances. It floods information about its own directly-connected links to every router in the area; each router assembles an identical link-state database describing the whole topology; and then each independently runs Dijkstra's shortest path first algorithm against that map to compute its own best routes.

The consequences:

• Fast convergence, because every router already has the map and can recompute immediately rather than waiting for news to propagate hop by hop.
• No routing loops by design, because decisions come from a complete topology rather than from hearsay.
• Higher CPU and memory cost, because maintaining and processing that database is real work.

OSPF's metric is cost, derived from bandwidth — a faster link has lower cost, and the best path is the lowest total cost. It is not hop count, which is the important contrast with older protocols: OSPF will happily choose a three-hop gigabit path over a one-hop 10 Mbps path, and RIP would not.

Areas are how OSPF scales. A large OSPF network is divided into areas, all attached to the backbone, area 0. Flooding is contained within an area, so a topology change in one area does not force every router in the network to recompute. Routers connecting areas are area border routers.

OSPF forms adjacencies with neighbours and exchanges hellos to detect failure. Neighbours must agree on several parameters — area ID, hello and dead intervals, authentication, MTU — and a mismatch in any of them leaves the adjacency stuck rather than throwing an obvious error. "OSPF neighbours will not form" is a diagnostic question with a checklist answer.

Route selection: the order that decides everything

When a router has several candidate routes to a destination, it applies these tests in this order. The first test that distinguishes them wins, and the later tests are never reached.

1. Prefix length — the longest match wins.

This comes first, and it beats everything. If the table holds 10.0.0.0/8 and 10.1.1.0/24, a packet for 10.1.1.5 takes the /24, because it is more specific. It does not matter which protocol learned them or what their metrics are.

This is why a default route (0.0.0.0/0, the least specific route possible) is only used when nothing else matches — it is the shortest prefix in the table.

2. Administrative distance — lowest wins.

Only if two routes have the same prefix length does the router ask which source it trusts more. Administrative distance (AD) is a trustworthiness rating per routing source, and lower is better:

So if OSPF and a static route both offer 192.168.5.0/24, the static route wins — AD 1 beats AD 110 — regardless of how good the OSPF path is. That is a frequent exam question and a frequent real-world surprise: someone adds a static route "temporarily" and it silently overrides the dynamic protocol.

A route with AD 255 is considered unusable and is never installed.

3. Metric — lowest wins.

Only if prefix length and administrative distance tie — which in practice means two routes from the same protocol — does the metric decide. The metric is protocol-specific: OSPF uses cost from bandwidth, EIGRP uses its composite of bandwidth and delay, RIP uses hop count.

Comparing metrics across protocols is meaningless, which is precisely why administrative distance exists.

Longest prefix, then administrative distance, then metric. Committing that sequence to memory answers more questions than any other single fact in this domain.

If routes tie on all three, the router may install both and load-balance across them — equal-cost multipath.

Subinterfaces

A subinterface is a logical division of one physical interface, each with its own IP address and VLAN. They are written as GigabitEthernet0/0.10, where .10 is conventionally the VLAN ID.

Their classic use is router-on-a-stick: inter-VLAN routing over a single trunk link. A router with one physical connection to a switch creates a subinterface per VLAN, each tagged with 802.1Q and each holding the default gateway address for its VLAN. Traffic from VLAN 10 to VLAN 20 travels up the trunk, is routed between subinterfaces, and comes back down.

It works and it is cheap — one cable, one port. The limitation is that all inter-VLAN traffic crosses that one link in both directions, so it becomes a bottleneck. A multilayer switch with SVIs routes in hardware at line rate and is what you deploy at any scale. Router-on-a-stick remains a common exam scenario and a reasonable small-site answer.

PAT

PAT (Port Address Translation) — also called NAT overload — is the form of NAT essentially every network uses.

Where static NAT maps one private address to one public address, PAT maps many private addresses to one public address, distinguishing the conversations by source port.

The router keeps a translation table:

Each outbound connection gets a unique source port on the public address, and replies are matched back to the right internal host by that port. One public address can therefore serve thousands of internal hosts — which is why your household's dozens of devices share one address from your ISP.

Two limits worth knowing:

Inbound connections do not work without help. A packet arriving unsolicited has no entry in the translation table, so the router does not know where to send it. Reaching an internal server from outside needs port forwarding — a static mapping of a public port to an internal address and port.

The port space is finite. About 64,000 ports per public address, less in practice, and applications that open many simultaneous connections consume them quickly. Very large deployments need a pool of public addresses rather than one.