BGP best-path decision

BGP does not choose a route by counting ASNs and stopping. It builds a list of candidates, applies policy and protocol attributes, and keeps comparing until one criterion separates the paths. The order matters: a route with a lower MED can still lose to a route with a higher LOCAL_PREF, and a route from an eBGP peer can still lose to a locally originated route.

This lesson turns the decision into an eleven-step operating sequence. The list is a practical way to explain a VyOS or FRR result. FRR can apply additional multipath, already-selected, cluster, and peer-address details after the core comparison, so the final answer is always verified from the live output rather than inferred from a memorized diagram.

Candidate paths before criteria

For a destination, FRR considers paths that are valid for the local address family and policy context. A path can be rejected before the decision begins because its AS_PATH contains the local ASN, its next hop is unusable, or inbound policy denies it. The Loc-RIB is therefore not a raw copy of every advertisement.

flowchart TB
  P["Several BGP paths"] --> V["Validate loops, AFI, and policy"]
  V --> W["1. Highest weight"]
  W --> L["2. Highest LOCAL_PREF"]
  L --> O["3. Locally originated"]
  O --> A["4. Shortest AS_PATH"]
  A --> G["5. Lowest ORIGIN"]
  G --> M["6. Lowest MED where comparable"]
  M --> E["7. eBGP over iBGP"]
  E --> C["8. Lowest IGP cost"]
  C --> H["9. Deterministic external preference"]
  H --> R["10. Lowest router ID"]
  R --> N["11. Lowest peer address as last resort"]
  N --> B["Selected best path"]

The diagram is a decision tree, not a promise that every router prints every intermediate value. A policy action that changes a higher criterion can make lower criteria irrelevant for a particular pair of paths.

The eleven steps

1. Prefer the highest weight

Weight is a local value associated with a neighbor or route policy. It is evaluated before other BGP attributes and is not transmitted to another router. A high LOCAL_PREF received from a neighbor cannot beat a locally assigned higher weight on the comparing router.

Configure a peer weight on VyOS 1.5 LTS:

configure
set protocols bgp neighbor 192.0.2.2 address-family ipv4-unicast weight 200
commit
save

Use weight for a deliberate local preference, such as a test peer or a last-resort override. Do not scatter high weights across every neighbor; the result becomes difficult to explain.

2. Prefer the highest LOCAL_PREF

LOCAL_PREF is the primary exit-selection signal inside an AS. It is well suited to expressing a policy such as “use ISP-A for all customer traffic unless a route is marked otherwise.” The attribute is not normally advertised between autonomous systems.

A route-map can set LOCAL_PREF on an inbound policy:

configure
set policy route-map PREFER-ISP-A rule 10 set local-preference 200
commit
save

The exact route-map name and sequence are part of the configuration contract. Validate the rendered map and the received path together.

3. Prefer a locally originated route

A route originated locally through a network statement, aggregate, or redistribution is generally preferred over a received path when the earlier criteria tie. This protects intentional local originations from a remote path that happens to have a shorter AS_PATH.

A locally originated route is not automatically safe. It can still be the wrong announcement if the prefix is missing from the RIB, a route map denies it, or an upstream filter rejects it.

4. Prefer the shortest AS_PATH

When the earlier criteria do not separate the candidates, BGP counts the relevant AS_PATH segments and prefers the shorter path. Prepending operates here. AS_PATH is a policy history, so a path with fewer hops can still represent a worse exit according to the business policy.

5. Prefer the lowest ORIGIN

ORIGIN is ranked as IGP, EGP, and incomplete. An IGP origin is preferred to an EGP origin, and an EGP origin is preferred to an incomplete origin. It is a coarse attribute, not a replacement for LOCAL_PREF. Network statements normally create an IGP-origin route; redistributed routes commonly carry incomplete origin unless policy changes it.

6. Prefer the lowest MED where comparable

MED, or Multi-Exit Discriminator, is primarily an inbound signal from a neighboring AS indicating a preferred ingress point. FRR normally compares MED only when the neighboring AS is the same. Comparing MED across unrelated neighboring ASNs can create confusing results and oscillation.

Use MED deliberately at a dual-homing boundary and document whether the local design enables deterministic comparison. Do not use MED to override a higher-priority local policy.

7. Prefer eBGP over iBGP

When the previous criteria tie, an external path is normally preferred over an internal path. This rule is why a route received from a provider is often chosen over an iBGP copy of the same route that arrived through a longer internal path.

The relationship is based on the configured neighbor and negotiated ASN. A misclassified session can make this comparison meaningless.

8. Prefer the lowest IGP cost to NEXT_HOP

The router evaluates the cost to reach the BGP next hop. This is one place where the IGP and BGP topologies must agree. A path can have a good LOCAL_PREF and a short AS_PATH yet lose because the next hop is two expensive IGP hops away.

Changing an IGP metric is a routing change. Validate both the BGP candidate and the underlying route before assuming that BGP ignored a better provider.

9. Use deterministic external preference

FRR can consider whether an eBGP path was already selected and can use deterministic options to make repeated decisions more stable. The specific behavior depends on the FRR mode and settings, so do not describe a tie as a universal BGP rule. A changed MED, a route refresh, or a new update can otherwise cause avoidable oscillation.

10. Prefer the lowest router ID

If the paths still tie, FRR compares the router ID associated with the path. A route learned through route reflection can use ORIGINATOR_ID instead of the peer router ID. Stable router IDs make this tie-breaker easier to reason about.

Set a deliberate BGP router ID:

configure
set protocols bgp parameters router-id 192.0.2.1
commit
save

Router ID is not the same as an ASN, loopback address, or OSPF router ID, although an address may be reused by convention.

11. Use the lowest peer address

The transport-layer peer address is the final common tie-breaker in the practical sequence. FRR also has cluster-list and other implementation details that can appear in a complete explanation. When the live output reaches this stage, the operator should record all candidate attributes instead of changing them blindly.

Configuration evidence

A small example uses a peer-group policy to make the decision observable:

configure
set protocols bgp system-as 65000
set protocols bgp address-family ipv4-unicast network 198.51.100.0/24
set protocols bgp neighbor 192.0.2.2 remote-as 65100
set protocols bgp neighbor 192.0.2.2 address-family ipv4-unicast weight 100
commit
save

Then inspect the exact prefix and path:

show bgp ipv4 unicast 198.51.100.0/24
show bgp neighbor 192.0.2.2
show ip route 198.51.100.0/24

The first view should show the candidates and their attributes. The second shows the peer relationship and policy. The third proves which candidate became the forwarding path.

How it fails

• The operator changes AS_PATH length but leaves a higher LOCAL_PREF on the other path, so traffic does not move.
• A router is configured with a new BGP router ID, and the new ID wins an otherwise equal path unexpectedly.
• MED is compared across different neighboring ASNs, creating an unintestable preference cycle.
• A loopback source changes the IGP cost to NEXT_HOP even though the provider policy is unchanged.
• A peer-group setting applies to one member differently because a per-neighbor parameter overrides the group value.
• Multipath is enabled for eBGP, but the selected paths have different next hops or do not satisfy the configured equality rules.

Rollback

Keep the previous route map, weight, and maximum-paths configuration together. A bad weight can be removed directly:

configure
delete protocols bgp neighbor 192.0.2.2 address-family ipv4-unicast weight
commit
save

For a global router-ID change, record the old value and restore it only after checking every iBGP neighbor. Use rollback N for a multi-commit policy change. Re-run the prefix and FIB checks after the rollback because the winning path can be selected in a different direction.

Cross-course references

XXVI-VyOS-BGPAttributes develops the individual attributes in detail. XXVII-VyOS-BGPRoutePolicy is the natural next step for route maps and policy validation. XXXI-VyOS-BGPTroubleshoot applies the decision tree to missing or unexpected paths. XXVIII-VyOS-BGPPrefixFilters defines the boundary that prevents an invalid candidate from entering the decision in the first place. The Linux course covers the IGP cost and kernel route beneath the selected BGP path.

Quiz