NEXT_HOP est l'attribut BGP qui indique l'adresse IP du routeur vers lequel envoyer le trafic pour atteindre le préfixe annoncé. C'est un préalable absolu : avant même d'évaluer les critères de sélection du meilleur chemin, BGP vérifie que le NEXT_HOP est joignable. Un NEXT_HOP injoignable rend la route invalide — elle n'entre pas dans l'algorithme de sélection.
next-hop-self sur le routeur de bordure.Une adresse NEXT_HOP de 0.0.0.0 signifie que la route a été originée localement par ce routeur, via network, aggregate-address, ou redistribute. Elle est toujours considérée comme valid.
# show ip bgp — route locale vs route apprise Network Next Hop Metric LocPrf Weight Path *> 10.0.0.0/8 0.0.0.0 0 32768 i ← originée localement (network) *> 172.16.0.0/12 192.0.2.1 0 100 0 65100 i ← apprise via eBGP * 172.16.0.0/12 203.0.113.5 0 100 0 65200 i ← invalid si 203.0.113.5 injoignable
| Valeur NEXT_HOP | Signification | Valid ? |
|---|---|---|
0.0.0.0 |
Route originée localement | Toujours valid |
192.0.2.1 (dans IGP) |
NEXT_HOP joignable via IGP ou statique | Valid ✓ |
203.0.113.5 (absent de la RIB) |
NEXT_HOP injoignable | Invalid ✗ — non installée |
10.0.0.1 (peer eBGP, non dans IGP) |
Problème iBGP classique — next-hop-self manquant | Invalid sur routeurs iBGP ✗ |
Lorsqu'un routeur envoie une route à un peer eBGP, il met le NEXT_HOP à sa propre adresse IP sur l'interface vers ce peer (l'adresse source de la session eBGP).
Lorsqu'un routeur de bordure (ASBR) reçoit une route via eBGP et la propage à ses peers iBGP, il conserve le NEXT_HOP eBGP d'origine — il ne met pas sa propre adresse. Les peers iBGP reçoivent donc le NEXT_HOP du peer eBGP externe.
Problème résultant
Les routeurs iBGP internes doivent avoir une route IGP vers le NEXT_HOP eBGP (ex: 10.0.12.1). Si ce subnet n'est pas redistribué dans l'IGP → route invalide sur tous les iBGP.
Solution
Redistribuer les subnets eBGP dans l'IGP, OU configurer next-hop-self sur l'ASBR pour remplacer le NH par sa propre adresse loopback.
Un routeur qui propage une route reçue via iBGP à un autre peer iBGP ne modifie pas le NEXT_HOP. Il reste celui fixé lors de la première propagation (règle 2). Cette règle est cohérente avec la rule split-horizon iBGP.
Quand un routeur de sortie propage une route iBGP vers un peer eBGP, il met sa propre adresse comme NEXT_HOP (adresse de l'interface vers le peer eBGP), comme en règle 1.
| Sens de propagation | NEXT_HOP mis à | Modifiable ? |
|---|---|---|
| Envoi eBGP sortant | Propre adresse IP (interface vers le peer) | Via route-map set ip next-hop |
| Propagation iBGP (reçu depuis eBGP) | NH eBGP d'origine — inchangé | Via next-hop-self |
| Propagation iBGP → iBGP | Inchangé | Via next-hop-self sur chaque hop |
| Route originée localement | 0.0.0.0 |
Non applicable |
Sans next-hop-self, un routeur iBGP qui reçoit une route eBGP voit le NEXT_HOP comme l'adresse du peer eBGP externe. Si ce subnet eBGP n'est pas annoncé dans l'IGP interne, tous les routeurs iBGP marquent cette route comme invalide.
Sans next-hop-self
R2# show ip bgp 192.168.0.0
NEXT_HOP: 10.0.12.1
inaccessible — route INVALID
(10.0.12.1 absent de l'IGP)
Avec next-hop-self sur ASBR
R2# show ip bgp 192.168.0.0
NEXT_HOP: 2.2.2.2 (loopback ASBR)
accessible via IGP — route VALID
! R-ASBR (AS200) — peer iBGP internes R2 et R3 router bgp 200 ! Session eBGP vers AS100 (inchangée) neighbor 10.0.12.1 remote-as 100 ! Sessions iBGP — next-hop-self pour forcer NH = loopback ASBR neighbor 2.2.2.2 remote-as 200 neighbor 2.2.2.2 update-source Loopback0 neighbor 2.2.2.2 next-hop-self neighbor 3.3.3.3 remote-as 200 neighbor 3.3.3.3 update-source Loopback0 neighbor 3.3.3.3 next-hop-self ! Vérification — NH modifié dans les UPDATEs envoyés show ip bgp neighbors 2.2.2.2 advertised-routes ! → NEXT_HOP doit afficher l'adresse loopback de l'ASBR
Par défaut, next-hop-self ne s'applique qu'aux routes reçues via eBGP. Les routes déjà apprises via iBGP et réfléchies par un Route Reflector conservent leur NEXT_HOP original. Pour forcer le NH même sur les routes iBGP réfléchies, utiliser next-hop-self all.
! Route Reflector — forcer next-hop-self sur TOUTES les routes (eBGP + iBGP réfléchies) router bgp 200 neighbor CLIENT-GROUP next-hop-self all ! "next-hop-self" seul = routes eBGP uniquement ! "next-hop-self all" = routes eBGP + routes iBGP réfléchies
next-hop-self all est particulièrement utile dans les topologies Hub-and-Spoke iBGP ou quand le Route Reflector est sur le chemin de données et doit être le NEXT_HOP pour tous ses clients.| Situation | next-hop-self requis ? | Raison |
|---|---|---|
| ASBR redistribuant routes eBGP vers iBGP full-mesh | Oui — recommandé | NH eBGP non annoncé dans l'IGP → invalide sur iBGP |
| Route Reflector réfléchissant routes eBGP | Oui — next-hop-self all |
Clients RR ne voient pas le NH eBGP distant |
| MPLS L3VPN — PE vers CE | Généralement non nécessaire | NH résolu via MPLS/LDP, pas via IGP classique |
| eBGP direct entre deux AS voisins | Non nécessaire | NH est l'adresse du peer direct — toujours joignable |
| eBGP multi-hop (loopback peering) | Selon topologie | NH peut être une loopback non annoncée dans IGP du pair |
Par défaut, lors d'un envoi eBGP, le routeur toujours remplace le NEXT_HOP par sa propre adresse (règle 1). La commande next-hop-unchanged supprime ce comportement et laisse le NEXT_HOP original intact lors de l'envoi eBGP.
Comportement eBGP par défaut
R-PE envoie à eBGP peer → remplace NH par sa propre adresse.
Avec next-hop-unchanged
R-PE envoie à eBGP peer → NH d'origine préservé.
Dans certaines architectures MPLS, le NH transporté dans les routes VPNv4 doit rester celui du PE d'ingress (ou du CE source) pour que le forwarding MPLS fonctionne correctement à travers le core. next-hop-unchanged empêche le PE d'egress de remplacer ce NH.
Dans une confédération BGP, les sous-AS échangent des routes en eBGP interne. Pour éviter que chaque sous-AS remplace le NH à chaque frontière interne, next-hop-unchanged permet de propager le NH original du CE source jusqu'au PE d'egress sans modification.
Les route servers des IXP utilisent next-hop-unchanged pour que les membres de l'IXP reçoivent le NH du pair réel (et non du route server). Cela permet le forwarding direct entre membres sans passer par le route server.
! Route Server à un IXP — propager le NH du peer réel router bgp 65000 neighbor MEMBER-GROUP peer-group neighbor MEMBER-GROUP next-hop-unchanged ! PE MPLS — préserver NH lors d'envoi VPNv4 entre PE router bgp 100 address-family vpnv4 neighbor PE2-LOOPBACK next-hop-unchanged neighbor PE2-LOOPBACK activate
| Commande | Effet sur le NEXT_HOP | Direction | Use case |
|---|---|---|---|
next-hop-self |
Remplace le NH par l'adresse locale | Outbound iBGP | ASBR, Route Reflector — rendre NH joignable côté iBGP |
next-hop-self all |
Remplace NH même pour routes iBGP réfléchies | Outbound iBGP (RR) | Route Reflector agissant aussi comme NH |
next-hop-unchanged |
Préserve le NH original (ne pas remplacer) | Outbound eBGP | IXP route servers, MPLS L3VPN, confédérations |
BGP maintient la validité des routes en vérifiant périodiquement que les NEXT_HOPs sont toujours joignables dans la RIB. Ce processus s'appelle le BGP Scanner. Par défaut, il tourne toutes les 60 secondes — ce qui signifie qu'une route peut rester installée jusqu'à 60 s après la perte du NH.
Depuis IOS-XE, BGP peut réagir immédiatement aux changements de la RIB (ajout/suppression d'une route vers un NH) sans attendre le prochain cycle du scanner. C'est le BGP Next-hop Address Tracking, activé par défaut sur IOS-XE.
! IOS-XE — NH tracking activé par défaut ! Délai de réaction configurable (défaut = 5 secondes) router bgp 200 bgp nexthop trigger delay 5 ! délai en secondes avant réaction (défaut : 5) bgp nexthop trigger enable ! activer si non actif par défaut ! Désactiver le scanner périodique si tracking événementiel actif no bgp scan-time ! IOS classique bgp scan-time 15 ! ou réduire à 15 s (min = 5 s) ! Vérification du tracking show ip bgp nexthop ! liste tous les NH et leur statut show ip bgp nexthop detail ! détail + timer de revalidation
# show ip bgp nexthop BGP nexthop path by IP address, as known to: base Address RIB-State NH-State Resolved via Metric Last update 10.0.12.1 reachable valid connected 0 00:02:13 10.0.23.1 reachable valid ospf 20 00:01:45 192.0.2.100 not found invalid -- -- 00:00:08 ← NH injoignable ! # Colonnes importantes : # RIB-State : "reachable" = NH présent dans la RIB # NH-State : "valid" = routes utilisant ce NH sont valides # Resolved via: via quelle source de routage le NH est atteint
| Mécanisme | Déclenchement | Délai réaction | Config |
|---|---|---|---|
| BGP Scanner | Périodique (timer) | Jusqu'à 60 s | bgp scan-time <5-60> · défaut 60 s |
| NH Tracking | Événementiel (changement RIB) | 5 s par défaut | bgp nexthop trigger delay <sec> · IOS-XE |
bgp scan-time 15).⚠️ Piège 1 — Un ASBR modifie le NEXT_HOP lors de la propagation iBGP
Faux par défaut. L'ASBR conserve le NEXT_HOP eBGP d'origine lors de la propagation iBGP (règle 2). C'est précisément le problème que résout next-hop-self. Sans cette commande, les routeurs iBGP internes reçoivent un NH qu'ils ne peuvent pas résoudre.
⚠️ Piège 2 — next-hop-self s'applique aussi aux routes reçues en iBGP et réfléchies
Faux avec la commande basique. next-hop-self seul ne touche que les routes reçues via eBGP. Pour forcer le NH même sur les routes iBGP réfléchies par un Route Reflector, il faut next-hop-self all.
⚠️ Piège 3 — next-hop-unchanged s'utilise sur les sessions iBGP
Faux. next-hop-unchanged s'utilise sur les sessions eBGP pour empêcher le remplacement par défaut du NH lors d'un envoi eBGP. Sur iBGP, le NH n'est pas modifié par défaut — la commande n'a donc pas de sens dans ce sens-là.
⚠️ Piège 4 — NEXT_HOP = 0.0.0.0 indique une route invalide
Faux. 0.0.0.0 signifie que la route a été originée localement (via network, aggregate-address ou redistribute). Elle est toujours considérée comme valid — c'est le seul cas où BGP ne vérifie pas la joignabilité du NH.
⚠️ Piège 5 — Le BGP Scanner détecte immédiatement une perte de NH
Faux. Le BGP Scanner est périodique (défaut 60 s). Une route peut rester installée dans la RIB jusqu'à 60 s après la disparition du NH, ce qui représente un black-hole potentiel. Le NH Tracking événementiel (IOS-XE) réduit ce délai à ~5 s.
⚠️ Piège 6 — En IPv6, le NEXT_HOP est transporté dans l'attribut NEXT_HOP type 3
Faux. En IPv6 (MP-BGP), le NEXT_HOP est encodé dans l'attribut MP_REACH_NLRI (type 14), pas dans le NEXT_HOP type 3. L'attribut type 3 est spécifique à IPv4. C'est une distinction fréquemment testée au CCIE.
📌 Point d'attention — Le critère NEXT_HOP est évalué AVANT l'algorithme de sélection
La joignabilité du NEXT_HOP est vérifiée avant même d'entrer dans l'algorithme W·L·L·A·O·M·E·I·A·O·R·C·N. Une route avec un NH injoignable est exclue de tout le processus de sélection — elle n'est pas comparée aux autres chemins.
📌 Point d'attention — next-hop-self modifie les UPDATEs envoyés, pas la table locale
Comme remove-private-as, next-hop-self est un filtre outbound. La table BGP locale de l'ASBR conserve le NH eBGP d'origine. C'est seulement dans les UPDATEs envoyés aux peers iBGP que le NH est remplacé par l'adresse locale.
Cliquez sur une carte pour révéler la réponse.
network, aggregate-address, ou redistribute). Cette valeur est toujours considérée comme valid — BGP ne vérifie pas sa joignabilité.
neighbor X next-hop-self sur l'ASBR pour remplacer le NH par sa propre adresse (loopback).
next-hop-self : remplace le NH uniquement pour les routes apprises via eBGP. next-hop-self all : remplace le NH pour toutes les routes, y compris celles apprises via iBGP (ex: routes réfléchies par un Route Reflector).
bgp nexthop trigger delay 5).
show ip bgp nexthop — liste tous les NH avec leur RIB-State (reachable/not found), NH-State (valid/invalid), et la source de routage via laquelle le NH est résolu.
next-hop-self explicite ou par une route-map set ip next-hop outbound.