BGP · IGP Metric · Critère #8

Profil complet

Type code

— aucun

Catégorie

Règle de sélection

Critère

Comparaison

Lowest wins

Source métrique

IGP (OSPF / EIGRP / IS-IS)

Portée

Locale (table de routage)

ℹ️ Le critère #8 n'est pas un attribut transporté dans BGP. Le routeur consulte sa propre table de routage IGP pour connaître le coût d'accès au NEXT_HOP de chaque chemin BGP. Le chemin dont le NEXT_HOP est le moins coûteux est préféré.

Position dans l'algorithme

1Weight

2LOCAL_PREF

3NH=0.0.0.0

4AS-PATH

5Origin

6MED

7eBGP/iBGP

8IGP metric ← ici

9AIGP

10Oldest

11Router-ID

12Cluster-list

13Neighbor IP

Concept — Métrique IGP vers NEXT_HOP

🗺️

Ce que compare le critère #8

Pour chaque chemin BGP encore en lice, le routeur regarde le NEXT_HOP associé, puis consulte sa table de routage pour connaître le coût IGP pour atteindre cette adresse. La route avec le coût le plus bas est sélectionnée.

📊

Valeur "metric" dans show ip bgp

Dans show ip bgp, le champ metric affiché pour les routes iBGP correspond à la métrique IGP vers leur NEXT_HOP. Pour les routes eBGP (NEXT_HOP directement connecté), la métrique est typiquement 0.

🔄

Sensibilité aux changements IGP

Si la topologie IGP change (lien en panne, coût modifié), la métrique vers un NEXT_HOP peut changer. BGP recalcule automatiquement le best path via le mécanisme de Next-Hop Tracking (NHT).

⚙️

Désactivation possible

La commande bgp bestpath igp-metric ignore permet de sauter le critère #8. Les chemins à coût IGP différents sont alors comparés à égalité → possibilité d'ECMP même avec métriques IGP inégales.

Hot Potato vs Cold Potato Routing

🔥 Hot Potato Routing

PrincipeSortir du réseau le plus vite possible

Critère utilisé#8 IGP metric (lowest)

Exit choisiExit le plus proche (IGP metric min)

AvantageRéduit la charge interne

InconvénientChemin AS-to-AS potentiellement sous-optimal

Comportement par défaut✅ Oui (critère #8 actif)

❄️ Cold Potato Routing

PrincipeGarder le trafic dans le réseau le plus longtemps

Critère utilisé#2 LOCAL_PREF (highest)

Exit choisiExit le plus proche de la destination

AvantageMeilleur chemin end-to-end

InconvénientTrafic interne plus long à transiter

Comportement par défaut❌ Nécessite policy LP

💡 En pratique, le critère #8 implémente nativement le hot potato routing. Pour faire du cold potato, il faut agir sur LOCAL_PREF (critère #2) depuis les border routers, avant que le critère #8 soit atteint.

Processus de résolution du NEXT_HOP

① BGP reçoit une route UPDATE NEXT_HOP = 203.0.113.1 (peer eBGP) ou 10.0.0.2 (peer iBGP)

↓

② Vérification de validité (prérequis) Le NEXT_HOP est-il atteignable ? (route dans la table de routage). Si non → route invalide, jamais installée ni comparée.

↓

③ Lookup récursif dans la RIB IOS cherche la route vers le NEXT_HOP → peut être une route directement connectée, statique, ou apprise via IGP (OSPF, EIGRP, IS-IS).

↓

          ④ Extraction de la métrique IGP → critère #8
          La métrique de la route IGP résolvant le NEXT_HOP est utilisée pour le critère #8. Plus cette valeur est basse, plus le chemin est préféré.
        

Exemples de résolution — topologie dual border router

  AS 65001
  ┌─────────────────────────────────────────────┐
  │                                             │
  │  R3 (RR) ──────── R1 (border-W)             │
  │   │          cost=10      │ eBGP            │
  │   │                  203.0.113.1 (ISP-A)    │
  │   │                                         │
  │  R4 ──────────── R2 (border-E)              │
  │          cost=50      │ eBGP                │
  │                  203.0.113.2 (ISP-A aussi)  │
  │                                             │
  │  R3 reçoit les deux routes via iBGP depuis  │
  │  R1 (NH=203.0.113.1) et R2 (NH=203.0.113.2) │
  └─────────────────────────────────────────────┘

Chemin A (via R1) NH = 203.0.113.1 → Route IGP vers 203.0.113.1 : cost 10

Chemin B (via R2) NH = 203.0.113.2 → Route IGP vers 203.0.113.2 : cost 50

Résultat #8 Chemin A sélectionné (cost 10 < 50)

Types de résolution et leur métrique

Type de route résolvant le NH	Métrique utilisée en #8	Cas typique
Directement connectée	0	eBGP peer sur lien direct
Route statique	0 (ou AD statique)	NH statique vers peer eBGP
OSPF (intra-area)	Coût OSPF cumulé	iBGP peer loopback via OSPF
OSPF (inter-area)	Coût OSPF total	Topologie multi-area
EIGRP	Métrique composite EIGRP	Réseau EIGRP interne
IS-IS	Métrique IS-IS	Réseau opérateur SP
Non résolvable	Route invalide	NH unreachable → rejetée

Lookup récursif — cas pratique

! NH iBGP = 10.255.0.2 (loopback R1)
! Vérification dans la table de routage de R3

R3# show ip route 10.255.0.2
Routing entry for 10.255.0.0/24
  Known via "ospf 1", distance 110, metric 10, type intra area
  Last update from 10.0.13.1 on GigabitEthernet0/0, 00:05:12 ago
  Routing Descriptor Blocks:
  * 10.0.13.1, from 10.255.0.1, 00:05:12 ago, via GigabitEthernet0/0
      Route metric is 10, traffic share count is 1

! BGP utilisera metric=10 pour le critère #8 sur ce chemin
! Si un autre chemin a NH résolvable avec metric=5 → ce chemin perd en #8

R3# show ip bgp 172.16.0.0/24
  ...
  10.255.0.2 (metric 10) from 10.255.0.2 (10.255.0.2)
      valid, internal

Topologie de référence

  AS 65001
  ┌────────────────────────────────────────────────────────┐
  │                                                        │
  │         ┌──── R1 (border-W) ────┐ eBGP → ISP (65100) │
  │         │    Loopback: 1.1.1.1  │                     │
  │  OSPF   │    cost W→R3 = 10     │                     │
  │         │                       │                     │
  │  R3 ────┤                       │                     │
  │ (RR)    │    Loopback: 2.2.2.2  │                     │
  │         └──── R2 (border-E) ────┘ eBGP → ISP (65100) │
  │              cost E→R3 = 50                           │
  │                                                        │
  │  Préfixe : 172.16.0.0/16 annoncé par les 2 ISP        │
  │  R1 NH = 203.0.113.1, R2 NH = 203.0.113.2             │
  │  Sur R3 : IGP metric vers 1.1.1.1 = 10                │
  │           IGP metric vers 2.2.2.2 = 50                │
  └────────────────────────────────────────────────────────┘

show ip bgp sur R3 — critère #8 en action

R3# show ip bgp 172.16.0.0/16
BGP routing table entry for 172.16.0.0/16, version 8
Paths: (2 available, best #1, table Default-IP-Routing-Table)
  Advertised to update-groups:
     1
  65100
    203.0.113.1 (metric 10) from 1.1.1.1 (1.1.1.1)   ← via R1
      Origin IGP, metric 0, localpref 100, valid, internal, best
      ↑ metric=10 (IGP cost vers NH 1.1.1.1) — critère #8 : 10 < 50 → best ✅
  65100
    203.0.113.2 (metric 50) from 2.2.2.2 (2.2.2.2)   ← via R2
      Origin IGP, metric 0, localpref 100, valid, internal
      ↑ metric=50 (IGP cost vers NH 2.2.2.2) — critère #8 : 50 > 10 → perd ❌

Analyse critère par critère sur R3

Critère	Chemin via R1	Chemin via R2	Résultat
#1 Weight	0	0	Égal — suivant
#2 LOCAL_PREF	100	100	Égal — suivant
#3 NH=0.0.0.0	Non	Non	Égal — suivant
#4 AS-PATH	1 hop (65100)	1 hop (65100)	Égal — suivant
#5 Origin	IGP (i)	IGP (i)	Égal — suivant
#6 MED	0	0	Égal — suivant
#7 eBGP/iBGP	internal	internal	Égal — suivant
#8 IGP metric	10	50	✅ R1 gagne (10 < 50)

Avec bgp bestpath igp-metric ignore

R3(config-router)# bgp bestpath igp-metric ignore

R3# show ip bgp 172.16.0.0/16
BGP routing table entry for 172.16.0.0/16
Paths: (2 available, best #1, table Default-IP-Routing-Table)
  65100
    203.0.113.1 (metric 10) from 1.1.1.1 (1.1.1.1)
      Origin IGP, localpref 100, valid, internal, best   ← #9+ départage
  65100
    203.0.113.2 (metric 50) from 2.2.2.2 (2.2.2.2)
      Origin IGP, localpref 100, valid, internal
! Critère #8 ignoré → les deux chemins sont "égaux" jusqu'à #9+
! Si maximum-paths ibgp 2 configuré : ECMP possible malgré metric différente

BGP Next-Hop Tracking (NHT)

ℹ️ Le BGP Next-Hop Tracking surveille en continu la résolvabilité et la métrique IGP de chaque NEXT_HOP BGP. Quand l'IGP signale un changement (lien down, coût modifié), BGP déclenche un recalcul du best path. Ce mécanisme est activé par défaut sur IOS.

⚡

Événements déclencheurs

NH devient inaccessible (route disparaît)
NH redevient accessible (route réapparaît)
Métrique IGP vers NH change (→ critère #8)
Prochain saut IGP change (next-hop change)

🕐

Délai de réaction (dampening)

Par défaut, BGP attend 5 secondes après un événement IGP avant de recalculer le best path. Ce délai évite les oscillations en cas de flapping IGP.

bgp nexthop trigger delay <0-100>

0 = réaction immédiate (non recommandé)

Configuration et vérification

! NHT est activé par défaut. Personnalisation :
router bgp 65001
  bgp nexthop trigger delay 10      ! Attendre 10s après changement IGP
  bgp nexthop trigger enable         ! Activer (par défaut)

! Désactiver NHT (déconseillé en production) :
router bgp 65001
  no bgp nexthop trigger enable

! Ignorer le critère #8 (métriques IGP ne comptent plus) :
router bgp 65001
  bgp bestpath igp-metric ignore

Commandes de vérification NHT

! Voir l'état de tous les next-hops BGP
R3# show ip bgp nexthops

BGP nexthop path by IGP metric table
Nexthop      Resolved  Metric  Last RIB Change  Priority
1.1.1.1      yes       10      00:01:05         0
2.2.2.2      yes       50      00:01:05         0
203.0.113.1  yes       0       00:00:30         0

! Voir les détails d'un next-hop spécifique
R3# show ip bgp nexthops 1.1.1.1

! Voir la configuration NHT
R3# show ip bgp summary
! Chercher : "BGP scan interval" et "BGP table version"

! Debug NHT (attention : très verbeux en production)
R3# debug ip bgp nexthop
R3# debug ip bgp 1.1.1.1 events

Interaction NHT et convergence BGP

Événement	Action NHT	Impact BGP
Lien IGP tombe (NH inaccessible)	NH marqué invalide après délai NHT	Route BGP invalidée, retirée de la table
Lien IGP remonte (NH accessible)	NH marqué valide après délai NHT	Route BGP réactivée, best path recalculé
Coût OSPF modifié (ex: 10→5)	Métrique mise à jour après délai NHT	Best path peut changer si critère #8 s'applique
Route IGP remplacée par statique	NH toujours résolvable, métrique=0	Chemin peut gagner en #8 (metric 0 < OSPF cost)

Principe du multipath BGP

ℹ️ Par défaut, BGP installe un seul best path dans la RIB. La commande maximum-paths permet d'installer plusieurs chemins en ECMP. Pour que deux chemins soient éligibles à l'ECMP, ils doivent être identiques sur les critères 1 à 8 (ou les critères différents doivent être explicitement ignorés).

Commandes maximum-paths

router bgp 65001
  ! ECMP entre chemins eBGP (max 32 sur la plupart des plateformes)
  maximum-paths 4

  ! ECMP entre chemins iBGP
  maximum-paths ibgp 4

  ! ECMP eBGP + iBGP combinés (contexte VPN/MPLS)
  maximum-paths eibgp 4

  ! Ignorer la métrique IGP pour permettre ECMP même si coûts différents
  bgp bestpath igp-metric ignore

  ! Relaxer la contrainte AS-PATH pour ECMP multi-ISP (même préfixe, AS-PATH différents)
  bgp bestpath as-path multipath-relax

Conditions ECMP — récapitulatif

Condition	eBGP ECMP	iBGP ECMP
Weight identique	✅ Requis	✅ Requis
LOCAL_PREF identique	✅ Requis	✅ Requis
AS-PATH identique (longueur)	✅ Requis (ou multipath-relax)	✅ Requis
Origin identique	✅ Requis	✅ Requis
MED identique	⚠️ Selon config	⚠️ Selon config
IGP metric identique	→ ou igp-metric ignore	→ ou igp-metric ignore
maximum-paths configuré	✅ Requis (>1)	✅ Requis (ibgp >1)

Scénario ECMP dual-ISP avec multipath-relax

! Scénario : deux ISP différents (AS-PATH différents mais même longueur)
! R3 veut faire ECMP vers 172.16.0.0/16 via R1 (ISP-A 65100) et R2 (ISP-B 65200)

router bgp 65001
  maximum-paths 2
  bgp bestpath as-path multipath-relax    ! AS-PATH différents OK pour ECMP
  bgp bestpath igp-metric ignore          ! Ignorer #8 si métriques IGP différentes

! Vérification ECMP dans la table de routage
R3# show ip route 172.16.0.0
Routing entry for 172.16.0.0/16
  Known via "bgp 65001", distance 200, metric 0
  Tag 65100, type internal
  Last update from 1.1.1.1 00:00:10 ago
  Routing Descriptor Blocks:
  * 203.0.113.1, from 1.1.1.1, 00:00:10 ago
      Route metric is 0, traffic share count is 1
    203.0.113.2, from 2.2.2.2, 00:00:08 ago
      Route metric is 0, traffic share count is 1
! Deux next-hops → ECMP ✅

Vérification multipath dans show ip bgp

R3# show ip bgp 172.16.0.0/16
BGP routing table entry for 172.16.0.0/16
Paths: (2 available, best #1, table Default-IP-Routing-Table)
  Advertised to update-groups: 1
  65100
    203.0.113.1 (metric 10) from 1.1.1.1 (1.1.1.1)
      Origin IGP, localpref 100, valid, internal, multipath, best
  65100
    203.0.113.2 (metric 10) from 2.2.2.2 (2.2.2.2)
      Origin IGP, localpref 100, valid, internal, multipath
! "multipath" indique que les deux chemins sont installés en ECMP

⚡ NH inaccessible = route invalide (jamais critère #8)

Si le NEXT_HOP d'un chemin BGP n'est pas résolvable dans la table de routage, la route est invalide et ne participe pas à la sélection. Le critère #8 ne s'applique même pas. Le prérequis de résolvabilité du NEXT_HOP est évalué avant tout critère.

⚡ Confusion : metric BGP (MED) vs metric IGP (#8)

Dans show ip bgp, le champ metric affiché peut représenter deux choses différentes : la MED (critère #6, attribut BGP reçu du voisin) ou la métrique IGP vers le NEXT_HOP (critère #8, calculée localement). Ne pas confondre.

⚡ bgp bestpath igp-metric ignore sans maximum-paths

Ignorer la métrique IGP sans configurer maximum-paths ne crée pas d'ECMP. Le critère #9+ départagera toujours les chemins. Pour réellement profiter de l'ECMP, il faut combiner igp-metric ignore + maximum-paths ibgp N.

⚡ ECMP asymétrique et load balancing inégal

En ECMP BGP, la répartition du trafic dépend du mécanisme de CEF (per-destination ou per-packet). Par défaut, IOS utilise le hash CEF per-flow (5-tuple). Si les flux sont asymétriques, la charge ne sera pas parfaitement équilibrée même avec ECMP.

⚡ NHT trigger delay trop bas — instabilité

Configurer bgp nexthop trigger delay 0 en production peut causer des oscillations BGP si l'IGP flap. Chaque micro-changement de métrique IGP déclencherait immédiatement un recalcul BGP complet. Garder la valeur par défaut (5s) ou augmenter.

⚡ as-path multipath-relax sans vérification de politique

Activer bgp bestpath as-path multipath-relax peut créer de l'ECMP vers des AS différents avec des politiques de routage différentes. Vérifier que les deux chemins sont vraiment équivalents du point de vue politique avant d'activer.

✅ Bonne pratique — next-hop-self + NHT

Configurer next-hop-self sur les border routers garantit que les NEXT_HOP iBGP sont des loopbacks internes, toujours résolvables via IGP. Cela rend le critère #8 fiable et prévisible, et évite les routes invalides dues à des NH externes non connus de l'IGP interne.

✅ Bonne pratique — monitorer show ip bgp nexthops

En production, surveiller régulièrement show ip bgp nexthops pour détecter les NH non résolus ou avec des métriques anormales. Un NH avec Resolved: no signifie que des routes BGP sont invalides et que le trafic peut être impacté.

Cliquez sur une carte pour révéler la réponse.

Que compare le critère #8 de la sélection BGP ?

Le critère #8 compare la métrique IGP pour atteindre le NEXT_HOP de chaque chemin BGP. Le chemin dont le NEXT_HOP est accessible avec le coût IGP le plus faible (lowest) est préféré.

→ Lookup dans la table de routage locale

Qu'est-ce que le "hot potato routing" et quel critère BGP le reflète ?

Le hot potato routing consiste à sortir le trafic de son réseau le plus rapidement possible, en choisissant l'exit point le plus proche. C'est exactement le comportement du critère #8 : préférer le chemin dont le NEXT_HOP est le moins coûteux en IGP.

→ Opposé : cold potato = LOCAL_PREF (critère #2)

Comment désactiver le critère #8 dans la sélection BGP ?

bgp bestpath igp-metric ignore dans le processus BGP. Les chemins avec des métriques IGP différentes seront alors considérés comme égaux sur ce critère, et le comparateur passera au critère #9 (AIGP).

→ Utile pour activer ECMP malgré des métriques IGP inégales

Quelle commande permet de faire de l'ECMP iBGP ? Quelle condition préalable ?

maximum-paths ibgp N dans le processus BGP. Condition : les chemins doivent être identiques sur les critères 1 à 8 (ou les différences doivent être explicitement ignorées avec igp-metric ignore et/ou as-path multipath-relax).

→ maximum-paths = eBGP ECMP, maximum-paths ibgp = iBGP ECMP

Qu'est-ce que le BGP Next-Hop Tracking (NHT) ?

Mécanisme qui surveille en continu la résolvabilité et la métrique IGP des NEXT_HOPs BGP. Quand l'IGP change (lien tombe, coût modifié), BGP recalcule automatiquement le best path après un délai configurable (bgp nexthop trigger delay, défaut = 5s).

→ show ip bgp nexthops pour vérifier

Quelle est la métrique IGP d'un NEXT_HOP directement connecté (eBGP sur lien direct) ?

0. Un peer eBGP directement connecté a son NEXT_HOP résolvable via une route connected avec coût 0. Cela lui donne l'avantage sur tout chemin iBGP avec un coût OSPF/EIGRP > 0, toutes choses égales par ailleurs sur les critères 1–7.

→ C'est pourquoi eBGP gagne souvent aussi en critère #8

À quoi sert bgp bestpath as-path multipath-relax ?

Permet de faire de l'ECMP entre chemins dont l'AS-PATH est différent (mais de même longueur). Sans cette commande, deux chemins vers le même préfixe mais venant d'AS différents (ex: deux ISP) ne peuvent pas être mis en ECMP même si tous les autres critères sont identiques.

→ Typiquement utilisé en dual-ISP ECMP

Dans show ip bgp, le champ "metric" représente-t-il toujours la métrique IGP ?

Non. Le champ metric dans show ip bgp peut représenter deux choses : la MED (critère #6, valeur reçue dans l'attribut BGP) ou la métrique IGP vers le NEXT_HOP (critère #8, calculée localement). Pour les routes iBGP, c'est généralement la métrique IGP vers le NH.

→ Regarder le contexte : "metric" après le NH = IGP metric

IGP Metric vers NEXT_HOP