BGP Best Path Calculator
Compare two BGP paths through the real tie-break order and see which attribute decides the winner.
About BGP Best Path Calculator
Path selection is a strictly ordered list, not a score. The comparison stops at the first attribute where the two paths differ, which is why a single local-preference change overrides any amount of AS-path prepending applied further down the list. Almost every unexpected BGP path is one attribute set higher in the order than the one being tuned, and knowing which step decided is the difference between a five-minute fix and an afternoon of prepending that changes nothing.
Formulas
BGP Best Path
BGP compares weight (higher), then local preference (higher), locally originated, AS-path length (shorter), origin code (IGP < EGP < incomplete), MED (lower), then eBGP over iBGP, lowest IGP metric, oldest path and lowest router ID.
- weight
- Cisco-proprietary, never advertised, evaluated first
- local preference
- Advertised inside the AS to steer outbound traffic
- MED
- Advertised to a neighbouring AS to steer inbound traffic; only compared between paths from the same AS by default
Short-circuit evaluation
The first attribute that differs decides the path — later steps are never evaluated.
Worked example
With the default values below, BGP Best Path Calculator returns Best Path of Path B. Change any input above and every figure here is recalculated in your browser.
Inputs used
- Path A weightaccepts 0–65,535
- 0
- Path B weightaccepts 0–65,535
- 0
- Path A local preferenceaccepts 0–4,294,967,295
- 100
- Path B local preferenceaccepts 0–4,294,967,295
- 200
- Path A AS-path lengthaccepts 0–64 hops
- 3 hops
- Path B AS-path lengthaccepts 0–64 hops
- 4 hops
- Path A originone of IGP — network statement, EGP, Incomplete — redistributed
- IGP — network statement
- Path B originone of IGP — network statement, EGP, Incomplete — redistributed
- IGP — network statement
- Path A MEDaccepts 0–4,294,967,295
- 50
- Path B MEDaccepts 0–4,294,967,295
- 100
Results
- Best Path
- Path B
- Deciding Attribute
- Local Preference (higher wins)
- Step in the Decision Process
- 2
- Reason
- Path B wins at step 2 on Local Preference (higher wins) — every attribute above it was equal
- Steps Not Reached
- 5 later step(s) were never evaluated
Step by step
- 1Values used
- 2BGP Best Path
- 3Short-circuit evaluation
- 4Best Path= Path B
- 5Deciding Attribute= Local Preference (higher wins)
- 6Step in the Decision Process= 2
- 7Reason= Path B wins at step 2 on Local Preference (higher wins) — every attribute above it was equal
- 8Steps Not Reached= 5 later step(s) were never evaluated
Assumptions and limits
- The result is derived only from the 10 inputs listed above. Anything not among them is not part of the calculation.
- In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
- Figures are rounded for display to whole numbers, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.
How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.
Frequently Asked Questions
How is BGP Best Path calculated?
BGP compares weight (higher), then local preference (higher), locally originated, AS-path length (shorter), origin code (IGP < EGP < incomplete), MED (lower), then eBGP over iBGP, lowest IGP metric, oldest path and lowest router ID. Path selection is a strictly ordered list, not a score. The comparison stops at the first attribute where the two paths differ, which is why a single local-preference change overrides any amount of AS-path prepending applied further down the list.
Why does BGP Best Path matter?
Almost every unexpected BGP path is one attribute set higher in the order than the one being tuned, and knowing which step decided is the difference between a five-minute fix and an afternoon of prepending that changes nothing.
What values do I need to enter?
This calculator takes 10 inputs: Path A weight, Path B weight, Path A local preference, Path B local preference, Path A AS-path length, Path B AS-path length, Path A origin, Path B origin, Path A MED, Path B MED. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.
Why is my AS-path prepend being ignored?
Because local preference is evaluated first. If a route-map sets a higher local preference on the path you are trying to avoid, AS-path length is never reached. Prepending only influences neighbours who have not set local preference themselves.
Why are two MED values not being compared?
By default MED is only compared between paths received from the same neighbouring AS. Comparing across autonomous systems requires the always-compare-med option, and enabling it inconsistently across a domain can cause persistent route oscillation.