BGP Best Path Calculator
Compare two BGP paths through the real tie-break order and see which attribute decides the winner.
Inputs
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
Values used
Path A weight = 0; Path B weight = 0; Path A local preference = 100; Path B local preference = 200; Path A AS-path length = 3 hops; Path B AS-path length = 4 hops; Path A origin = IGP — network statement; Path B origin = IGP — network statement; Path A MED = 50; Path B MED = 100
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.
Short-circuit evaluation
The first attribute that differs decides the path — later steps are never evaluated.
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
How it works
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.
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.