BGP Best Path Selection

The ordered decision process every router runs to pick one winning route — the single most important thing to understand when debugging why traffic takes the path it does. Pit two routes against each other on Weight, LOCAL_PREF, AS_PATH length and MED, and watch exactly which step decides the winner. The trap: the steps are ranked, not summed. Validated against FRRouting bgpd/bgp_route.c (bgp_path_info_cmp).

Launch Simulator →

What you'll explore

  1. 01

    Step 1 — Weight

    Cisco-proprietary, and FRR implements it as the very first comparison: highest weight wins. Weight is local to this one router — it is never encoded in any BGP attribute and never propagates to a peer. That is exactly why it surprises people: a weight set on one box changes that box's decision and no one else's.

  2. 02

    Step 2 — LOCAL_PREF

    Higher LOCAL_PREF wins, and it is the primary knob for steering outbound traffic across an AS. Unlike weight, LOCAL_PREF rides inside UPDATEs to every iBGP peer, so the whole AS agrees on the preferred exit. A decisive LOCAL_PREF difference ends the process here — AS_PATH length is never even consulted.

  3. 03

    Step 4 — AS_PATH Length

    Only reached when weight, LOCAL_PREF, local-origin and AIGP are all equal. Fewer AS hops wins (FRR counts hops via aspath_count_hops). This is the step most engineers think of as 'how BGP picks routes' — but it sits fourth, below two attributes that routinely override it.

  4. 04

    Step 6 — MED

    Lower MED wins — but only when the two routes were received from the same neighboring AS (FRR gates this on aspath_cmp_left / internal_as_route unless 'always-compare-med' is set). MED is a hint you hand a neighbor about which of your entry points to prefer; comparing it across different ASes is meaningless, so by default BGP refuses to.

  5. 05

    Step 8 — IGP Metric & Tie-Breakers

    If ORIGIN (Step 5) and peer type (Step 7: eBGP beats iBGP) don't settle it, the lower IGP metric to the next hop wins — 'hot-potato' routing. Still tied? FRR falls to the hard tie-breakers: prefer the oldest external path (to damp route-flap), then the lowest Router-ID, then the lowest neighbor address. These make the outcome deterministic but config-sensitive.

Validated against FRRouting frr-10.6.1 — bgpd/bgp_route.c and friends. Every simulated behavior cites a real source function, and a server-side correlation engine computes how each layer's state cascades into the next. See the methodology →

This module is part of zerohop Pro — it unlocks alongside the full kata library, progress tracking, and weak-area analysis.

Launch Simulator →