How BGP Chooses Between Competing Routes

A border router on a moderately connected network will often hold several valid routes to the same destination prefix, learned from different peers with different attributes. Only one can be installed in the forwarding table, so BGP applies a fixed sequence of comparisons and stops at the first attribute where the candidates differ. That first difference decides everything; nothing below it is even examined.

This ordering is what makes BGP troubleshooting counter-intuitive. Engineers frequently prepend AS numbers to make a path look worse, then find traffic unchanged, because a local preference policy three steps earlier had already settled the outcome. This calculator makes that visible: it runs both candidate paths through all twelve steps, names the exact attribute that decided the winner, and shows which later attributes were never consulted.

The Attributes in Order of Precedence

Weight comes first and is Cisco-proprietary. It never leaves the router that sets it, which makes it ideal for a local override and useless for AS-wide policy. Local preference is second and is the standard tool for that wider job, since it propagates to every iBGP peer and steers the entire autonomous system toward a chosen exit. Both prefer higher values, which trips up engineers used to metrics where lower wins.

Locally originated routes win third, then the shortest AS_PATH, then the lowest origin code where IGP beats EGP beats Incomplete. MED sits sixth and is the most misunderstood: it is only compared between paths from the same neighbouring AS, because a value set by one provider means nothing next to a value set by another. Below MED come the preference for eBGP over iBGP, the lowest IGP metric to the next hop, the oldest path, the lowest router ID, the shortest cluster list, and finally the lowest neighbour address as an absolute last resort.

Reading the Composite Score

The percentage scores shown here compress twelve ordered comparisons into a single number. Each step carries a weight of two raised to the power of its distance from the end of the list, so winning any step is worth more than winning every less significant step combined. That construction guarantees the numeric ordering matches the router's lexicographic decision exactly — the higher score always belongs to the path the router installs.

The margin between the two scores tells you how robust the decision is. A wide margin means the winner prevailed on an early, high-weight attribute and small configuration changes will not flip it. A narrow margin means the paths tied through most of the process and the outcome hinged on something incidental, such as router ID or session age — the kind of decision that can reverse unexpectedly after a maintenance window. BGP itself computes no such score; it is a readability aid layered over the standard process.

Multipath, Stability, and Practical Policy

When two paths tie all the way through the IGP metric, BGP can install both and load share across them, but the conditions are stricter than most operators expect. The AS_PATH must be identical by default, not merely equal in length, which rules out balancing across two different upstream providers until the as-path multipath-relax option is enabled. The maximum-paths setting then caps how many entries are actually programmed.

Two steps exist purely for stability rather than optimality. Preferring the oldest eBGP path avoids churn when sessions bounce, at the cost of making selection depend on startup order rather than configuration — which is why some operators disable it with bgp bestpath compare-routerid to keep behaviour reproducible. Deterministic MED similarly ensures that the comparison order of received updates cannot change the result. For policy that behaves predictably, set local preference for inbound traffic engineering, use AS_PATH prepending and MED for outbound influence with the understanding that neighbours may ignore both, and verify the outcome rather than assuming it.