BGP Decision Process

Three phases

The Decision Process runs in three sequential phases. Each phase is a separate process that blocks the next.

Phase 1: Degree of preference

Runs when Adj-RIB-In changes for a peer. Calculates a degree of preference for each route received from that peer.

The calculation is a local policy decision. A typical implementation uses LOCAL_PREF as the primary indicator — routes received from EBGP peers get a LOCAL_PREF assigned by inbound policy; routes received from IBGP peers carry LOCAL_PREF from the originating AS speaker.

Phase 1 marks each route in Adj-RIB-In with its computed preference value. Routes marked as ineligible (policy rejection) are excluded from Phase 2.

Phase 2: Route selection

Invoked after Phase 1 completes. Considers all eligible routes across all Adj-RIBs-In for a given destination prefix.

Eligibility

Before tie-breaking, routes are excluded if:

• NEXT_HOP is unresolvable (no valid route in the routing table to reach it)
• AS_PATH contains the local AS number (loop detection)

Tie-breaking algorithm

Applied in strict order. Each step removes routes from consideration until one remains.

Step details

Step 1 — LOCAL_PREF (highest wins)

The degree of preference from Phase 1. This is the primary policy lever. Routes from different peers with different LOCAL_PREF values are resolved here without reaching subsequent steps.

Step 2 — AS_PATH length (shortest wins)

Count the number of AS numbers in the full AS_PATH. An AS_SET counts as 1 regardless of member count. Shorter paths are preferred.

Step 3 — ORIGIN (lowest wins)

IGP (0) beats EGP (1) beats INCOMPLETE (2). Rarely a differentiator in modern networks since EGP origin is effectively extinct.

Step 4 — MULTI_EXIT_DISC (lowest wins, same neighbor AS only)

MED is compared only between routes learned from the same neighbor AS. Routes without MED are treated as MED=0 (lowest possible). The neighbor AS is determined from AS_PATH — for IBGP-learned routes, it is the AS from which the IBGP peer originally received the route.

Step 5 — EBGP over IBGP

If at least one remaining candidate was learned from EBGP, all IBGP-learned routes are removed. EBGP routes represent external connectivity; preferring them reduces internal transit.

Step 6 — IGP metric to NEXT_HOP (lowest wins)

Hot-potato routing. The router calculates the interior cost to reach each route’s NEXT_HOP via the IGP routing table and prefers the closest exit point. If cost cannot be determined, routes are treated as equal.

Step 7 — Lowest BGP Identifier

Among remaining routes, prefer the one advertised by the peer with the numerically lowest BGP Identifier (Router ID). This is a stable tiebreaker that ensures deterministic selection within an AS.

Step 8 — Lowest peer address

Final tiebreaker. If routes come from the same BGP speaker (multiple connections), prefer the route received from the session with the lowest peer IP address.

Phase 3: Route dissemination

Invoked after Phase 2, or when:

• Routes to local destinations change
• Locally originated routes change
• A new peer session reaches Established

Phase 3 populates Adj-RIBs-Out according to outbound policy:

IBGP route reflection

A route learned from IBGP is not re-advertised to another IBGP peer by default (split-horizon within IBGP). Route reflectors (RFC 4456) override this rule for their clients.

EBGP advertisement rules

A route learned from EBGP is advertised to all peers (IBGP and EBGP) subject to policy. When advertising to EBGP, the speaker prepends its ASN to AS_PATH and typically sets NEXT_HOP to self.

Route resolvability

A route is resolvable if:

1. The routing table contains at least one route to the NEXT_HOP address that is not recursively resolved through the BGP route itself
2. The resolution does not create mutual recursion (routes resolving through each other)

Unresolvable routes remain in Adj-RIB-In (may become resolvable later) but are excluded from Loc-RIB and the forwarding table.

Overlapping routes

When the Loc-RIB contains overlapping routes (e.g., 10.0.0.0/8 and 10.1.0.0/16), both are installed. The forwarding table uses longest-prefix match. This allows aggregation without losing reachability to more-specific destinations.

Operational notes

• MED comparison across different neighbor ASes (“always-compare-med”) is a common vendor extension not in RFC 4271. Enabling it changes convergence behavior.
• Deterministic MED (sorting routes by neighbor AS before comparison) is another extension that produces more predictable results at the cost of less optimal selection.
• Re-running Phase 2 occurs whenever IGP cost to a NEXT_HOP changes — this is the mechanism behind hot-potato routing shifts.