VyOSXXVII · BGP Best PathBest path
IGP cost tiebreak — when AS Path and other attributes tie, lowest IGP cost to next-hop wins
What you'll learn
- Explain why step 8 uses the IGP cost to the next-hop as the tiebreaker
- Trace the IGP cost from the local router to a BGP next-hop
- Recognise when iBGP paths will lose at step 8 to eBGP paths
- Influence the best-path selection by tuning the IGP cost to the next-hop
- Recognise the production failure modes where you need to force the IGP path
Prerequisites
Verified against VyOS 1.5.x LTS (circinus) · VyOS 1.4.x (sagitta) — legacy · FRRouting 10.x (VyOS 1.5) · Linux kernel 6.6 LTS (VyOS 1.5 base) · strongSwan 5.9.x (IPsec) · WireGuard 1.0.x (kernel module + userspace tooling) · 2026-08-15
Step 8 of the BGP best-path algorithm is the IGP cost to the next-hop. When steps 1-7 are tied (Weight, Local Preference, Locally Originated, AS Path, Origin, MED, eBGP over iBGP), the algorithm picks the path whose next-hop is reachable via the lowest IGP metric. This is the operator’s tiebreaker for paths that are otherwise equivalent.
The IGP cost is a property of the IGP topology, not the BGP configuration. The operator who wants to influence step 8 must change the IGP (OSPF cost, IS-IS metric) — not the BGP configuration. This is the boundary between the two routing layers: BGP makes the policy decisions, the IGP measures the cost to the egress.
Why step 8 is the IGP cost
The reasoning for the IGP cost tiebreaker is operational: when two paths are otherwise equivalent, the operator prefers the path that is closer (lower IGP cost) to the local router. The closer path has fewer hops to traverse within the local AS, which usually means lower latency and lower risk of intra-AS failure.
The IGP cost is also the operator’s last-resort tiebreaker. The settings the operator controls (Weight, Local Preference, MED, AS Path) are evaluated first. The IGP cost is what the operator implicitly controls by the design of the IGP topology — which is usually the result of capacity planning, not route selection.
flowchart TD
subgraph "Local AS"
R1["R1<br/>(local router)"]
R2["R2<br/>(iBGP peer)<br/>IGP cost to R1: 50"]
R3["R3<br/>(iBGP peer)<br/>IGP cost to R1: 10"]
end
subgraph "Upstream A"
UA["Peer A<br/>198.51.100.1"]
end
subgraph "Upstream B"
UB["Peer B<br/>192.0.2.2"]
end
R2 -->|"iBGP session"| UA
R3 -->|"iBGP session"| UB
R1 -->|"iBGP sessions to R2 and R3"| R2
R1 -->|"iBGP sessions to R2 and R3"| R3
The diagram shows the local AS with two iBGP peers (R2 and R3). R1 receives routes from both via iBGP. The route from R2 has next-hop 198.51.100.1 (peer A’s IP); the route from R3 has next-hop 192.0.2.2 (peer B’s IP). The IGP cost from R1 to R2 is 50 (R1 → R4 → R2, with OSPF costs 10 + 40). The IGP cost from R1 to R3 is 10 (direct OSPF adjacency).
If both routes are otherwise equivalent (same Weight, Local Preference, AS Path, Origin, MED, both are eBGP-learned via R2 and R3 iBGP), step 8 picks the path with the lowest IGP cost to the next-hop. The next-hop for R2’s path is 198.51.100.1; the IGP cost to R2 is 50 (R1 has to traverse R4 to reach R2, then R2 traverses R2-A to reach A). The next-hop for R3’s path is 192.0.2.2; the IGP cost to R3 is 10 (direct adjacency). The path through R3 wins at step 8.
The two IGP cost subtleties
The IGP cost to the next-hop is not always the cost to the iBGP peer. The next-hop is the IP address the BGP route uses to reach the destination — for an eBGP-learned route, the next-hop is the eBGP peer’s IP. For an iBGP-learned route, the next-hop is whatever the original eBGP peer set (because iBGP does not modify the next-hop).
The two subtleties:
1. The next-hop is the IP, not the router. The BGP route’s next-hop is the IP address, not the router that advertised it. The IGP cost is the cost to reach that IP, not the cost to reach the advertising router. For iBGP-learned routes, the next-hop is the original eBGP peer’s IP; the IGP cost goes from the local router through the IGP topology to the iBGP peer that has the eBGP session, then through the iBGP peer’s local network to the eBGP peer’s IP.
2. The IGP cost is recursive. The next-hop IP must itself be reachable in the IGP. The IGP cost is the metric in the routing table entry for the next-hop IP. If the next-hop is reachable via multiple IGP paths, the cost is the metric of the installed route (the one the FIB has chosen).
The operator who sees a “step 8 winner” must trace the IGP path from the local router to the next-hop, not just to the iBGP peer.
How to trace the IGP cost to the next-hop
The operator who wants to know the step 8 decision for a prefix first identifies the next-hop from show ip bgp, then looks up the IGP cost to that next-hop:
vyos@vyos:~$ show ip bgp 198.51.100.0/24
Paths: (2 available, best #1)
Path 1: 192.0.2.2 from 192.0.2.2 (10.255.0.1)
Origin IGP, metric 0, localpref 100, weight 0, external
Path 2: 198.51.100.1 from 10.0.0.5 (10.255.0.5)
Origin IGP, metric 0, localpref 100, weight 0, internal
Two paths. Path 1 has next-hop 192.0.2.2 (eBGP). Path 2 has next-hop 198.51.100.1 (iBGP, learned from 10.0.0.5). The IGP cost from the local router to 192.0.2.2 is the cost to the directly-connected link. The IGP cost to 198.51.100.1 is the cost to reach 10.0.0.5 (the iBGP peer) plus the cost from 10.0.0.5 to 198.51.100.1.
vyos@vyos:~$ show ip route 192.0.2.2
Routing entry for 192.0.2.0/24
Known via "bgp", distance 20, metric 0
* 192.0.2.2, via eth0
vyos@vyos:~$ show ip route 198.51.100.1
Routing entry for 198.51.100.1/32
Known via "ospf", distance 110, metric 25
* 10.0.0.5, via eth1
The cost to 192.0.2.2 is direct (cost 0 via eth0). The cost to 198.51.100.1 is 25 via 10.0.0.5 (the iBGP peer). Path 1 wins at step 8 because its next-hop has lower IGP cost.
For more detail, the operator uses ip route get:
vyos@vyos:~$ ip route get 198.51.100.1
198.51.100.1 via 10.0.0.5 dev eth1 src 10.0.0.1 uid 0 cache
The kernel’s routing table shows the path. The cost is implicit in the route’s metric.
Influencing step 8 by tuning the IGP cost
The operator who wants to influence step 8 without changing the BGP configuration changes the IGP cost. The canonical OSPF cost tuning:
# Increase the OSPF cost on the link to 10.0.0.5 (the iBGP peer with next-hop 198.51.100.1)
set protocols ospf interface eth1 cost '200'
# Or set the cost at the interface level
set interfaces ethernet eth1 ip ospf cost '200'
The OSPF cost increase makes the IGP path to 10.0.0.5 more expensive. The iBGP-learned path with next-hop 198.51.100.1 has a higher IGP cost. Path 1 (eBGP, direct next-hop) wins more often at step 8.
The operator who wants to influence step 8 in the opposite direction decreases the OSPF cost on the iBGP link:
set interfaces ethernet eth1 ip ospf cost '5'
The OSPF cost decrease makes the IGP path to 10.0.0.5 cheaper. The iBGP path wins at step 8 when the other path is otherwise tied.
The trade-off: changing the IGP cost affects every BGP path that uses the same next-hop. The operator who tunes the IGP cost for one BGP prefix may affect the best-path selection for many other prefixes.
The eBGP vs iBGP path at step 7 vs step 8
Step 7 prefers eBGP paths over iBGP paths. Step 8 prefers the lowest IGP cost. The two steps interact when both an eBGP path and an iBGP path are candidates for the same prefix.
A typical scenario: the local AS has two border routers. Border router R1 has an eBGP session with upstream A. Border router R2 has an eBGP session with upstream B. R1 and R2 have an iBGP session with the local router R3. R3 receives the prefix from:
- R1 via iBGP (the route is internal because R1-R3 is iBGP).
- R2 via iBGP (the route is internal because R2-R3 is iBGP).
Both routes are iBGP at R3. Step 7 ties. Step 8 looks at the IGP cost to the next-hop.
The next-hop for R1’s route is upstream A’s IP (say 192.0.2.2). The next-hop for R2’s route is upstream B’s IP (say 198.51.100.1). The IGP cost to R1 is the cost from R3 to R1. The IGP cost to R2 is the cost from R3 to R2. The algorithm picks the path with the lower IGP cost to the next-hop.
If R1 is two hops away (cost 20) and R2 is four hops away (cost 40), the path through R1 wins at step 8. The operator who wants to influence this decision can change the OSPF cost on the link to R2.
The “always-compare-med” interaction with step 8
The bgp always-compare-med knob extends the MED comparison to cross-AS paths. With the knob enabled, the algorithm may compare MED across paths that would otherwise step 8 to the IGP cost tiebreaker. The operator who configures always-compare-med sees different step 8 winners when the MED is comparable.
The interaction is rarely seen in production. The operator who sees step 8 winners changing after enabling always-compare-med is observing the extended comparison.
How the result is validated
show ip bgp <prefix>
show ip route <next-hop>
show ip ospf neighbor
show ip ospf interface
ip route get <next-hop>
The first command shows the > winner. The second shows the IGP cost to the next-hop. The third and fourth show the OSPF topology and the link costs. The fifth shows the kernel’s view of the path.
For deep debugging:
vtysh -c 'show ip ospf topology'
vtysh -c 'show ip bgp <prefix>'
The first shows the OSPF topology with the link costs. The second shows the BGP table with the next-hop field.
How it fails
The production failure modes the engineer must recognise:
- The next-hop is unreachable in the IGP. The iBGP peer advertises a route with a next-hop that is not reachable in the local IGP. The BGP route is
valid(it has a valid AS Path) but cannot be installed in the routing table because the next-hop is unreachable. The fix is to add the next-hop’s prefix to the IGP (e.g., advertise the iBGP peer’s loopback via OSPF). - The next-hop is reachable via a high IGP cost. The iBGP peer’s route wins at step 2 (Local Preference, AS Path) but loses at step 8 to a different path with a lower IGP cost. The operator expected the iBGP path to win. The fix is to tune the IGP cost on the link to the iBGP peer.
- The next-hop changes after a topology change. The local router’s path to the next-hop changes (e.g., a link fails). The best-path selection changes. The operator sees a different
>winner. The fix is to investigate the topology change; the BGP configuration is unchanged. - The IGP cost is asymmetric. The IGP path from R1 to R2 is cost 20, but the IGP path from R2 to R1 is cost 50 (because of asymmetric OSPF cost tuning). The best-path decision on R1 and R2 may differ. The fix is to make the IGP costs symmetric (or to use
deterministic-medto make the comparison deterministic). - The next-hop is a /32 not advertised in the IGP. The iBGP peer advertises a route with a /32 next-hop, but the /32 is not in the IGP. The BGP route is
inaccessible(the next-hop is unreachable). The fix is to advertise the iBGP peer’s loopback as a /32 in the IGP.
Step 8 vs step 9 — the IGP cost vs the router-id
Step 8 (IGP cost) and step 9 (router-id) are adjacent in the algorithm. When step 8 ties, the algorithm falls to step 9. The rule:
- For eBGP paths, step 9 picks the oldest path (the one that has been in the BGP table the longest).
- For iBGP paths, step 9 picks the path with the lowest router-id.
The operator who sees a step 9 winner must look at the path’s age (for eBGP) or the router-id of the iBGP peer (for iBGP). The router-id is shown in the from <router-id> field of show ip bgp.
The operator who configures the same router-id on two iBGP peers (a configuration error) sees a step 9 tiebreaker that cannot produce a single winner. The algorithm falls through to step 10 (lowest router-id of the RR client) and step 11 (lowest neighbour IP). The route-map with the lowest IP wins.
Rollback
IGP cost changes are configuration changes on the IGP side. The standard rollback path applies:
comparebeforecommitto see the OSPF cost change.commit-confirm <timeout>for any remote change.rollback N; commit; saveto revert to the previous configuration.load /config/archive/<known-good-file>; commit; saveto revert to a specific snapshot.
The operator who changes the OSPF cost on a production link must also know how to roll back the change. The standard rollback is rollback 1; commit; save — the previous configuration had the default OSPF cost, so the rollback restores the default.
Production discipline
Cross-course references
The Linux course’s XIX-Linux-NetFoundations covers the kernel FIB. The OPNsense course’s XXX-OPNsense-DynamicRouting covers the same FRR BGP-over-OSPF stack on the firewall side. The BGP lessons vyos-xxvi-05-community (the next-hop attribute and the iBGP requirement) and vyos-xxvii-01-best-path-algorithm (the eleven-step algorithm) cover the broader context. The OSPF lessons vyos-xix-06-ospf-cost-tuning and vyos-xviii-06-spf-and-cost cover the IGP cost mechanics. The lesson vyos-xxvii-06-best-path-troubleshoot walks the debugging of wrong-path-wins failures.
Quiz
Knowledge check · 4 questions
Q1. Two candidate paths for a prefix tie at steps 1-7. Path 1 has next-hop 192.0.2.2 (direct, IGP cost 0). Path 2 has next-hop 198.51.100.1 (via iBGP peer 10.0.0.5, IGP cost 25). Which path wins at step 8?
Q2. The IGP cost to the next-hop is the cost to the iBGP peer that advertised the route, not the cost to the next-hop IP itself.
Q3. An operator has two iBGP peers (R2 and R3) advertising the same prefix. The two paths tie at steps 1-7. The path through R3 wins at step 8 because the IGP cost to its next-hop is lower. The operator wants the path through R2 to win. What is the right way to influence step 8?
The two paths are equivalent at steps 1-7. The path through R3 has a lower IGP cost to its next-hop (the eBGP peer's IP). The operator wants to make the path through R2 win at step 8.
Q4. An operator configures iBGP with two peers. The iBGP peer's loopback is not advertised in the OSPF. The BGP routes are in the BGP table but not in the routing table. The operator sees `inaccessible` next-hops in `show ip bgp`. What is the fix?
The iBGP peer advertises routes with a next-hop that is the eBGP peer's IP. The eBGP peer's IP is reachable via the iBGP peer's loopback (10.0.0.5). The 10.0.0.5 address is not in OSPF. The BGP routes cannot be installed in the routing table because the next-hop is unreachable in the IGP.
Passing score: 75%. Answers are checked in this browser.