Route Preference, Metric, and the Split Between RIB and FIB

A router typically learns several routes to the same prefix from different sources. A directly connected network, a static route an operator typed, a route from an interior protocol, and a route from an exterior protocol can all describe the same destination, and each arrives with its own notion of cost. Selecting one of them requires two distinct comparisons, and conflating the two is a persistent source of misconfiguration.

Two numbers with different meanings

The first number is a preference attached to the source of the route. Cisco documentation calls it administrative distance; other implementations call it preference, and the values differ between vendors. Its purpose is to rank protocols against each other, not to compare paths within a protocol. A directly connected route wins over a static route, which wins over an interior gateway protocol route, which wins over an exterior protocol route. The ordering reflects trust: a route that comes from an interface’s own configuration is more credible than one learned from a neighbour, which is more credible than one learned from another autonomous system.

The second number is a metric, and its meaning is defined by the protocol that produced it. An interior protocol’s metric measures cost within one network, so comparing an OSPF cost to a BGP metric is meaningless; the units are unrelated. The preference comparison happens first and eliminates every route whose source is less preferred. Only then are metrics compared, and only among routes from the same source.

The separation is necessary because the two comparisons answer different questions. Preference asks which protocol should be believed. Metric asks which path that protocol thinks is better. A router that compared a static route’s metric against an OSPF cost would be comparing an operator’s arbitrary choice against a computed sum of link costs.

Preference   Source                      Metric
0            connected                   0
1            static                      0
20           external BGP                as-path length
110          OSPF                        10^8 / bandwidth
115          IS-IS                       interface cost
120          RIP                         hop count

The exact numbers are vendor conventions and vary; the ordering is what matters and is stable across implementations. The BGP entry is a reminder that an exterior protocol’s metric is a path length in autonomous systems, not a link cost, and that it is compared only against other BGP routes.

Ties, and the routes that stay in the table

When two routes have the same preference and the same metric, most implementations keep both and use one. Keeping both matters because the second is a standby: if the first path’s next hop becomes unreachable, the second is already computed and installed without waiting for a protocol convergence. This is the origin of equal-cost multipath, where the router distributes packets across both next hops rather than choosing one.

The distribution is per-flow rather than per-packet, because per-packet distribution across paths of different latency reorders packets and breaks transport performance. The flow hash is computed from the header fields that identify a flow, typically the address pair and sometimes the port pair or the protocol. The choice of fields is a trade: including ports spreads more flows and gives better balance, while omitting them keeps a flow on one path even when a middlebox rewrites ports, which matters for tunnels and for NAT.

A tie that is not broken by metric is a real state, not an error. The router’s forwarding table stores a set of next hops for the prefix, and the hash selects one at forwarding time. Adding a third path changes the hash mapping for existing flows, which is why a route addition can cause a brief reordering even though no path failed.

What the RIB holds that the FIB cannot

The routing information base is the control plane’s complete picture: every route from every source, with its preference, metric, and attributes, including the ones that lost the selection. The forwarding information base is what the hardware can use: for each prefix, one or more next hops and an outgoing interface, in a form the lookup engine can search.

The two differ in three ways. The RIB keeps rejected routes, because a rejected route becomes the replacement when the winner withdraws. The FIB does not, because a route that is not selected should never be used to forward a packet. The RIB keeps protocol attributes that have no forwarding meaning, such as the autonomous system path or the route’s age. The FIB keeps only what the next-hop rewrite needs. And the RIB is updated at the speed of protocol convergence, while the FIB is updated at the speed the hardware allows, which on a distributed router with line cards can be much slower.

The consequence is that the FIB can lag the RIB, and during the lag the router forwards on an older table. This is not a bug but a design constraint: the two are separate because they have different update costs. A router that installed every RIB change immediately would spend its time rewriting hardware, and a route flap would produce a burst of installs. Implementations batch changes and install them at a bounded rate, which means the forwarding plane can lag the control plane’s view until the next batch is installed.

Convergence, and what happens before it completes

When a link fails, the protocol that was using it must detect the failure, recompute, and advertise the change. Until every router on the path has done so, some routers forward on stale information and some on new, and the mismatch produces either a loop or a black hole.

A loop occurs when router A believes the destination is through B and B believes it is through A. Packets circulate until the hop limit expires, and the ICMP errors that result are the only signal. That signal, and the conditions under which a router is permitted to emit it, is described in ICMP errors as a feedback channel. A black hole occurs when a router has removed the route and no replacement exists yet, so packets are discarded immediately. The two failures have different signatures: a loop consumes capacity for the duration of the hop limit, while a black hole produces immediate errors at one point.

Interior protocols reduce the window by flooding the change and recomputing quickly, and by the ordering rule that a router installs a new route before removing the old one where the topology allows. Exterior protocols are slower because the change must propagate across administrative boundaries, and the propagation is deliberately damped to prevent a flapping route from destabilising every router that hears it. That damping means a route that withdraws and returns within the damping window stays suppressed, so the path remains unavailable after it has recovered, which is a real cost paid for stability.

Recursion, next-hop reachability, and the order of installation

A route’s next hop must itself be reachable, and reachability is determined by the RIB, not by the FIB. This creates an ordering problem: a route cannot be installed until the route that reaches its next hop is installed, and a change to the latter invalidates the former.

Implementations resolve this by computing next-hop reachability as a graph over the RIB and installing routes in dependency order. A next hop that resolves through a route that has just been withdrawn becomes unreachable, and every route that depended on it must be withdrawn too. The propagation is a closure operation, and its cost is proportional to the number of routes sharing the next hop, which on a transit router can be the entire table.

The practical failure mode is a next-hop that resolves through a route learned from the same protocol that depends on it. Two routers each learning the other’s address through the protocol they are running creates a circular dependency that resolves only if one of them has an independent route to the other, which is why interior protocols are configured with an explicit seed route or with the interface’s connected network as the anchor.

Why the split exists at all

The RIB and FIB could be one structure. Keeping them separate buys three things: a place to keep losing routes, a buffer between protocol churn and hardware update cost, and a boundary that lets the forwarding plane be implemented in a different place from the control plane.

The last is the one that shapes modern routers. The control plane is a general-purpose processor with memory and a full protocol stack; the forwarding plane is a pipeline or a set of lookup engines with no ability to run a protocol. The FIB is the interface between them, and its format is designed for lookup rather than for update, which is why installing a route can be far more expensive than looking one up. That asymmetry, described in longest-prefix match and forwarding structures, is the reason the interface exists in the form it does.

A final consequence is observability. A route can be present in the RIB and absent from the FIB, and the two states mean different things: the first says the control plane believes the path exists, the second says the hardware is not yet forwarding on it. Diagnosing a forwarding problem requires checking both, and a tool that reports only one of them will describe a consistent state that the packet path does not exhibit.