The BGP Best-Path Order and Why Its Steps Are Ordered That Way

BGP is a path-vector protocol: it advertises reachability for a prefix along with the sequence of autonomous systems a route traversed. A router may hold several routes for the same prefix, one from each neighbour that offered it, and it must choose one to advertise onward. The choice is a lexicographic comparison over a fixed list of attributes, and the order of that list is the most consequential design decision in interdomain routing.

Only the best route is advertised

A BGP speaker does not propagate every route it knows. For each prefix it selects one best route and advertises that to its peers, subject to export policy. The consequence is that a router’s view of the internet is not the set of all paths; it is the set of paths its neighbours chose to advertise, which are themselves the best paths those neighbours selected. The selection process at each hop therefore shapes what every downstream router can see.

The narrowing has a real cost. If the globally best path to a prefix is through autonomous system X, but a router’s neighbour in Y selected a different path because of a local policy, the router never learns about X’s path. Local decisions compound into global outcomes, and the compounding is why a policy change in one network can shift traffic across an ocean. It is also why the protocol can converge to a state that no single participant would have chosen.

The comparison sequence

The steps below are applied in order, and the first step that distinguishes two routes decides. The ordering is standard across implementations, though some steps are vendor extensions and some can be disabled by configuration.

The first comparison is a locally defined weight, which exists only on the router that assigns it and is never propagated. It is a per-device override used by operators to force a choice on one router, and it sits first because a value set by hand on that device is meant to outrank anything learned from a neighbour.

The second is local preference. This attribute is propagated within an autonomous system but not across its boundary, which is what makes it the primary instrument for outbound traffic engineering. A network sets a high local preference on routes learned from the provider it prefers to send traffic through, and every router inside the network makes the same choice because they all receive the attribute. Because it is not exported, the preference has no effect on how other networks reach the same prefix.

The third is whether the route was originated locally, by a network statement, an aggregate, or a redistribution. A locally originated route is preferred over one learned from a peer, which is a statement that the operator’s own configuration outranks what neighbours say.

The fourth is the length of the autonomous system path. Shorter wins. The count is of the autonomous system numbers in the path sequence, so a path through three systems beats one through four. Two details matter: an AS_SET, which is an unordered collection used in aggregation, counts as a single system regardless of how many it contains, and confederation segments are handled differently from ordinary sequences, as RFC 5065 describes, so a path through confederation member systems does not count each member.

1. highest weight                          (local to the router)
2. highest local preference                (local to the AS)
3. locally originated
4. shortest AS_PATH
5. lowest origin type                      IGP < EGP < incomplete
6. lowest MED                              (compared only within one neighbour AS)
7. eBGP over iBGP
8. lowest IGP metric to the next hop
9. oldest route for eBGP
10. lowest router ID
11. shortest cluster list
12. lowest neighbour address

The fifth step is a legacy artefact. The origin attribute records how the prefix entered BGP: as an interior protocol route, as an exterior protocol route, or by redistribution, marked incomplete. The ordering prefers the first and least prefers the last, on the theory that a route derived from an interior protocol’s own table is better understood. In practice the attribute is rarely set deliberately and the step seldom decides anything.

MED and the boundary it cannot cross

The multi-exit discriminator is the attribute that expresses “prefer this entry point into my network”. A network with two connections to the same provider can attach different MED values to the same prefix on each connection, and the provider’s routers will prefer the lower value when choosing among routes received from that one network.

The restriction is what makes MED different from local preference. MED is compared only among routes received from the same neighbouring autonomous system. A route from a different neighbour is not compared on MED at all, because the values are not on a common scale; each network sets its own. Implementations therefore defer the MED comparison until after the AS path comparison, and apply it only within a group of routes that share the first autonomous system in their path.

The second restriction is propagation. A MED received from one peer is not advertised to another peer in the general case, so a network’s preference reaches one hop and stops. This is deliberate: if MED propagated, a network’s internal preference would influence path selection arbitrarily far away, and the attribute would become a global ranking rather than a local hint.

A missing MED is treated as zero by most implementations, which makes an absent value the most preferred. That default is dangerous when one neighbour sends MED and another does not, since the absent value wins by accident. Operators work around it by configuring a default MED on the routers that would otherwise send nothing, or by selecting the variant of the comparison that ranks a missing MED as worse than any value present.

The step that creates hot-potato routing

After MED, the comparison prefers an external route over an internal one, and then compares the interior metric to the next hop. That step is where a network decides which of its own exit points to use for traffic destined elsewhere, and the decision is made on the cost of reaching the exit, not on the cost of the path beyond it.

The resulting behaviour is called hot-potato routing: a network hands traffic off to a neighbour at the closest exit, even if a farther exit would have a shorter path to the destination. The alternative, cold-potato routing, would keep traffic inside the network longer to hand it off at a point that is closer to the destination. The trade is between the network’s own cost and the end-to-end path length, and each network optimizes its own, which means the composite path is the result of many independent local minimizations rather than a global one.

The IGP metric comparison is also where a subtle failure lives. The metric is to the next hop, and the next hop’s reachability is determined by the interior protocol, as described in route preference and the split between RIB and FIB. If the interior protocol has not converged after a change, the metric comparison uses stale values, and the selected exit can be one whose path is no longer the shortest.

The final tiebreaks and determinism

The remaining steps exist to make the choice deterministic when everything else is equal. The oldest external route wins, which rewards stability: a route that has been present longer is less likely to be part of a flap. The router ID is a tiebreak that depends on the router’s own configuration, so it is stable per device. The cluster list length matters only in a route-reflector topology, where RFC 4456 allows a route to be reflected and the cluster list records the reflection path. The neighbour address is the last resort.

Determinism matters because every router must make the same choice for the same set of inputs, or the protocol will not converge. Two routers that compare the same routes and reach different conclusions will each advertise a different best path, and their peers will see oscillation. The tiebreak steps are therefore not arbitrary; they are the part of the algorithm that guarantees a total order over the inputs.

The guarantee is weaker than it looks. The inputs are not the same everywhere: local preference is local, weight is per-router, and the interior metric depends on the topology each router sees. Two routers in the same network can legitimately choose different exits for the same prefix, and they do, which is the mechanism behind the exit selection described above.

What the order does not consider

The list contains no measure of latency, loss, or available capacity. A path is chosen on administrative attributes and hop counts, and a shorter path can be slower than a longer one. The protocol’s designers accepted that because the attributes are the ones a network can state and verify, and because a path that is administratively preferred is usually the one the operator intended, regardless of its performance.

The list also does not consider the return path. A route selected for outbound traffic has no relationship to the route the destination will use for replies, so asymmetric paths are normal at this scale, and any stateful device at the boundary must be prepared for them, as policy routing with multiple tables describes for the local case.

The last omission is the most consequential in practice. A router selects the best path for a prefix and discards the rest from what it advertises, so the alternatives are invisible to its peers. When the best path fails, the withdrawal propagates and every router must reconverge on whatever alternative it still holds, which may be a path it would never have chosen. The convergence is not a reoptimization; it is a recovery to a state that the earlier selection had hidden.