BGP · eBGP > iBGP · Critère #7

Profil complet

Type code

— aucun

Catégorie

Règle de sélection

Critère

Vecteur

Non transporté dans UPDATE

Modifiable

❌ Pas directement

Résultat

eBGP gagne sur iBGP

ℹ️ Ce critère n'est pas un attribut BGP. Il ne circule pas dans les messages UPDATE. C'est une règle locale au routeur : si deux chemins sont identiques sur les critères 1 à 6, le chemin appris d'un peer eBGP (AS différent) est préféré à celui appris d'un peer iBGP (même AS).

Algorithme de sélection — position du critère #7

1Weight (Cisco local)

2LOCAL_PREF

3NH=0.0.0.0

4AS-PATH

5Origin

6MED

7eBGP > iBGP ← ici

8IGP metric

9AIGP

10Oldest

11Router-ID

12Cluster-list

13Neighbor IP

Pourquoi eBGP est-il préféré ?

🌍

Logique topologique

Une route apprise via eBGP vient d'un AS externe. Elle est supposée plus proche de la destination dans l'espace inter-AS. Un chemin iBGP est une route réfléchie à l'intérieur de l'AS, donc potentiellement moins direct.

⚖️

Administrative Distance

eBGP AD = 20, iBGP AD = 200. L'AD ne fait pas partie de l'algorithme de sélection BGP interne, mais elle reflète la même philosophie : une route eBGP est jugée plus fiable qu'une route iBGP.

🔒

Immuable par attribut

Ce critère ne peut pas être modifié par un attribut BGP. La seule façon de renverser la décision est d'agir sur un critère supérieur (1–6) : Weight plus élevé, LOCAL_PREF plus élevé, AS-PATH plus court, meilleur Origin, ou MED plus bas sur le chemin iBGP.

📋

Condition d'application

S'applique uniquement si le routeur dispose de plusieurs chemins valides vers le même préfixe, dont au moins un eBGP et au moins un iBGP, et si tous les critères 1 à 6 sont strictement égaux.

Différences fondamentales eBGP vs iBGP

Caractéristique	eBGP	iBGP
AS des peers	AS différents	Même AS
Administrative Distance	20	200
TTL par défaut	1 (lien direct)	255 (pas de limite)
NEXT_HOP	Modifié → IP du peer eBGP	Préservé (pas changé)
LOCAL_PREF	Non envoyé vers eBGP peers	Envoyé vers iBGP peers
MED	Envoyé vers eBGP peers	Reçu des eBGP, propagé en iBGP
AS-PATH	AS local ajouté (prepend)	AS local NON ajouté
Split horizon iBGP	N/A	Route iBGP NON re-annoncée à iBGP
Full mesh requis	N/A	Oui (ou RR / Confédération)
Critère #7	✅ Gagne sur iBGP	❌ Perd face à eBGP

🌍 Session eBGP

PeersAS différents

TTL par défaut1

AD20

NEXT_HOPChangé → IP peer eBGP

AS-PATH prependOui (AS local ajouté)

LOCAL_PREF reçuNon (filtré)

MED reçuOui

Route reflétée vers iBGPOui

🏠 Session iBGP

PeersMême AS

TTL par défaut255

AD200

NEXT_HOPPréservé (souvent inaccessible !)

AS-PATH prependNon (AS local non ajouté)

LOCAL_PREF envoyéOui

Split horizonOui (route iBGP non re-annoncée)

Full mesh ou RRRequis

Commandes et configurations clés

ebgp-multihop — eBGP sur loopbacks (TTL > 1)

! Par défaut TTL=1 : seul un peer directement connecté peut établir eBGP
! Pour eBGP entre loopbacks (recommandé en production) :
router bgp 65001
  neighbor 10.255.1.2 remote-as 65002
  neighbor 10.255.1.2 ebgp-multihop 2    ! TTL=2
  neighbor 10.255.1.2 update-source Loopback0

next-hop-self — Résoudre le problème NEXT_HOP iBGP

! Problème : iBGP préserve le NEXT_HOP du peer eBGP (ex: 203.0.113.1)
! Les routeurs internes ne connaissent pas cette adresse → route invalide
! Solution : le border router annonce son propre IP comme NEXT_HOP
router bgp 65001
  neighbor 192.168.1.2 remote-as 65001   ! iBGP peer
  neighbor 192.168.1.2 next-hop-self            ! Force NH = propre IP

iBGP full mesh — Requis par le split horizon

! iBGP split horizon : une route apprise via iBGP N'EST PAS re-annoncée
! à un autre iBGP peer. Solution : full mesh (n*(n-1)/2 sessions)
! ou Route Reflector / Confédération (voir onglet Confédération)
router bgp 65001
  ! Full mesh R1-R2-R3 (3 routeurs = 3 sessions)
  neighbor 10.0.0.2 remote-as 65001
  neighbor 10.0.0.3 remote-as 65001

NEXT_HOP : comportement par type de session

Scénario	NEXT_HOP annoncé	Problème potentiel	Solution
eBGP → eBGP peer	IP propre (interface eBGP)	—	—
eBGP reçu → re-annoncé iBGP	IP du peer eBGP externe	NH inaccessible pour routeurs internes	`next-hop-self` ou IGP redistrib.
iBGP → iBGP peer	Préservé (NH original)	Même NH potentiellement inaccessible	`next-hop-self` sur border router
Route Reflector → client	Préservé (NH original)	NH externe non connu des clients	`next-hop-self` sur RR

Topologie de référence

   AS 65100 (ISP-A)          AS 65001 (nous)            AS 65200 (ISP-B)
   ┌──────────┐      eBGP    ┌────────────────┐   eBGP   ┌──────────┐
   │  R-ISP-A │─────────────►│ R1 (border-1)  │          │  R-ISP-B │
   │10.1.1.1  │              │ 10.1.1.2       │          │10.2.1.1  │
   └──────────┘              │                │◄─────────│          │
                             └────────┬───────┘          └──────────┘
                                      │ iBGP                  │ eBGP
                             ┌────────▼───────┐               │
                             │ R2 (border-2)  │◄──────────────┘
                             │ 10.2.1.2       │
                             └────────────────┘

   Préfixe annoncé : 172.16.0.0/24 (depuis AS 65100 ET AS 65200)
   R1 : reçoit via eBGP (AS 65100)
   R2 : reçoit via eBGP (AS 65200) + via iBGP depuis R1

show ip bgp sur R2

R2# show ip bgp 172.16.0.0/24
BGP routing table entry for 172.16.0.0/24, version 5
Paths: (2 available, best #2, table Default-IP-Routing-Table)
  Advertised to update-groups:
     1
  65100                              ← chemin 1 : via R1 (iBGP)
    10.1.1.1 (metric 10) from 10.0.0.1 (10.0.0.1)
      Origin IGP, metric 0, localpref 100, valid, internal
      Community: 65001:100
  65200                              ← chemin 2 : via ISP-B (eBGP)
    10.2.1.1 from 10.2.1.1 (10.2.1.1)
      Origin IGP, metric 0, localpref 100, valid, external, best  ← ✅ critère #7

🔍 Les deux chemins ont localpref 100, AS-PATH length = 1, Origin = IGP, MED = 0. Critères 1–6 identiques → critère #7 s'applique. Le chemin external (eBGP) gagne sur internal (iBGP).

Analyse critère par critère

Critère	Chemin iBGP (via R1)	Chemin eBGP (direct)	Résultat
#1 Weight	32768 (défaut)	32768 (défaut)	Égal — suivant
#2 LOCAL_PREF	100	100	Égal — suivant
#3 NH=0.0.0.0	Non (route reçue)	Non (route reçue)	Égal — suivant
#4 AS-PATH	1 hop (65100)	1 hop (65200)	Égal — suivant
#5 Origin	IGP (i)	IGP (i)	Égal — suivant
#6 MED	0	0	Égal — suivant
#7 eBGP/iBGP	internal	external	✅ eBGP gagne

Identification dans show ip bgp

Marqueur	Signification
`>` (chevron en début de ligne)	Best path sélectionné
`valid, external, best`	Route eBGP, sélectionnée
`valid, internal`	Route iBGP, valide mais non sélectionnée
`i` en début de ligne (table summary)	Route iBGP (interne)
`metric X` sur route iBGP	IGP metric vers le NEXT_HOP (critère #8)

⚠️ Le critère #7 n'est pas modifiable par un attribut BGP. Pour favoriser un chemin iBGP sur un chemin eBGP, il faut agir sur un critère supérieur (1–6) avant que le critère #7 soit évalué.

Méthodes pour forcer un chemin iBGP à gagner

1
Weight (critère #1) — Appliquer un Weight plus élevé sur le chemin iBGP. S'applique localement sur le routeur recevant les deux chemins.
neighbor 10.0.0.1 weight 200 ← iBGP peer (défaut=0 pour iBGP reçu)
2
LOCAL_PREF (critère #2) — Augmenter la LOCAL_PREF de la route reçue via iBGP (définie sur le border router eBGP entrant, propagée en iBGP). Portée AS-wide.
route-map RM-PREFER-IBGP permit 10 → set local-preference 200
3
AS-PATH prepend (critère #4) — Allonger l'AS-PATH du chemin eBGP indésirable via set as-path prepend dans une route-map sur le peer eBGP entrant.
4
Origin (critère #5) — Changer l'Origin du chemin iBGP en i (IGP) s'il est actuellement ? ou e. Le chemin iBGP gagnera sur critère #5 avant d'atteindre #7.

Exemple — Forcer iBGP via Weight (local)

! Sur R2, favoriser le chemin reçu via iBGP (depuis R1) sur le chemin eBGP direct
router bgp 65001
  neighbor 10.0.0.1 remote-as 65001           ! iBGP peer R1
  neighbor 10.0.0.1 route-map RM-WEIGHT-HIGH in

route-map RM-WEIGHT-HIGH permit 10
  match ip address prefix-list PL-172-16
  set weight 200         ! Weight 200 > 0 (défaut eBGP) → iBGP gagne en #1

! Vérification
show ip bgp 172.16.0.0/24
!  → weight 200 sur chemin iBGP : "best" apparaît sur ce chemin

Exemple — Forcer iBGP via LOCAL_PREF (portée AS)

! Sur R1 (border eBGP vers ISP-A), dégrader la LOCAL_PREF des routes ISP-A
! R2 recevra LOCAL_PREF=50 pour ces routes → LOCAL_PREF 100 du chemin iBGP gagne

route-map RM-ISP-A-IN permit 10
  set local-preference 50

router bgp 65001
  neighbor 10.1.1.1 route-map RM-ISP-A-IN in   ! eBGP peer ISP-A

Cas d'usage légitimes

🔧 Maintenance eBGP

Pendant une maintenance sur un lien eBGP, élever la LOCAL_PREF du chemin iBGP alternatif pour forcer le trafic à passer par l'autre border router.

🏗️ Route Reflector préféré

Dans une architecture RR, forcer les clients à utiliser un chemin iBGP spécifique via Weight sur le RR, même si un chemin eBGP direct est disponible.

💰 Politique de coût

ISP-A moins cher qu'ISP-B : augmenter LOCAL_PREF des routes reçues de ISP-A afin que tous les routeurs internes préfèrent ce chemin, même s'ils ont un accès eBGP direct à ISP-B.

🚨

Piège CCIE majeur : Dans une confédération BGP, les sessions entre sous-AS (CONFED eBGP) sont traitées comme des sessions iBGP pour le critère #7. Une route reçue d'un sub-AS différent ne gagne pas sur une route iBGP au titre du critère #7.

Confédération BGP — rappel

 AS 65001 (AS public confédéré)
 ┌─────────────────────────────────────────────────┐
 │  Sub-AS 65100          Sub-AS 65200              │
 │  ┌──────────┐  CONFED  ┌──────────┐             │
 │  │  R1      │◄────────►│  R3      │             │
 │  │          │  eBGP    │          │             │
 │  └──────────┘          └──────────┘             │
 │  R1-R2 : iBGP (même sub-AS 65100)               │
 └─────────────────────────────────────────────────┘
 
 Session R1-R3 : CONFED eBGP (sub-AS différents)
 → AS_CONFED_SEQUENCE utilisé dans AS-PATH
 → Traité comme iBGP pour critère #7

Comportement du critère #7 en confédération

Type de session	Traitement critère #7	AS-PATH type
eBGP externe (vers autre AS)	✅ Traité comme eBGP → gagne en #7	AS_SEQUENCE
iBGP (même sub-AS)	❌ Traité comme iBGP → perd en #7	AS_SEQUENCE
CONFED eBGP (sub-AS différent)	⚠️ Traité comme iBGP en #7	AS_CONFED_SEQUENCE

⚠️ Une route reçue via CONFED eBGP (sub-AS 65200 → sub-AS 65100) ne gagnera pas en critère #7 face à une route iBGP du même sub-AS. Il faut agir sur les critères 1–6 (ex: LOCAL_PREF, Weight) pour établir la préférence.

Route Reflector et critère #7

🔄 Route Reflector — comportement

Le RR reflète les routes iBGP vers ses clients. Quand un client RR reçoit une route réfléchie, elle reste une route iBGP pour le critère #7. Si le client a aussi un chemin eBGP direct pour le même préfixe, le chemin eBGP gagne toujours en critère #7.

Attributs ajoutés par le RR :

ORIGINATOR_ID (type 9) — Router-ID de l'annonceur original
CLUSTER_LIST (type 10) — Liste des clusters traversés (anti-boucle)

📋 Critère #12 — Cluster-list

Si deux routes iBGP arrivent au critère #12 (après avoir passé #7, #8, #9, #10, #11 à égalité), la route avec la CLUSTER_LIST la plus courte est préférée. Cela favorise les routes passant par moins de Route Reflectors.

💡Conséquence : un RR bien positionné (entre l'eBGP et les clients) minimise les sauts de cluster et favorise les meilleures routes.

Configuration confédération — rappel

router bgp 65100                         ! Sub-AS local
  bgp confederation identifier 65001   ! AS public confédéré
  bgp confederation peers 65200        ! Autres sub-AS
  neighbor 10.0.0.3 remote-as 65200   ! CONFED eBGP (traité comme iBGP en #7)
  neighbor 10.0.0.2 remote-as 65100   ! iBGP classique (même sub-AS)

⚡ NEXT_HOP iBGP inaccessible

Le NEXT_HOP d'une route iBGP est préservé (IP du peer eBGP externe). Les routeurs internes ne connaissent pas cette adresse → route invalide, jamais installée.

Solution : next-hop-self sur le border router, ou redistribuer la route du peer eBGP dans l'IGP.

⚡ iBGP split horizon — routes non propagées

R1 apprend 172.16.0.0/24 via iBGP depuis R2. R1 ne re-annonce PAS cette route à R3 (autre iBGP peer). R3 ne connaît jamais le préfixe.

Solution : full mesh iBGP, ou déployer un Route Reflector / Confédération.

⚡ Confusion AD et critère #7

L'Administrative Distance (eBGP=20, iBGP=200) n'est pas un critère de l'algorithme de sélection BGP. Elle est utilisée lors de la comparaison inter-protocoles (BGP vs OSPF, etc.). Elle n'intervient jamais entre deux routes BGP.

⚡ ebgp-multihop oublié sur loopback

Session eBGP entre loopbacks (recommandé pour la stabilité) : TTL=1 par défaut → session ne s'établit jamais si les loopbacks ne sont pas directement connectées.

Solution : neighbor X.X.X.X ebgp-multihop 2 + update-source Loopback0.

⚡ CONFED eBGP confondu avec eBGP réel

En confédération, une session vers un sub-AS différent utilise remote-as d'un autre sub-AS → ressemble à eBGP. Mais pour le critère #7, cette session est traitée comme iBGP. La route ne bénéficiera pas de la priorité eBGP en #7.

⚡ Route reflétée écrase le chemin eBGP local

Un client RR avec session eBGP directe reçoit aussi la même route via le RR (iBGP). Il choisit son chemin eBGP direct en #7. OK. Mais si le chemin eBGP tombe, la route réfléchie prend le relais → convergence correcte. Ne pas filtrer les routes iBGP réfléchies inutilement.

✅ Bonne pratique — always use next-hop-self

Sur tous les border routers eBGP qui re-annoncent en iBGP, configurer systématiquement next-hop-self vers les peers iBGP. Cela garantit que le NEXT_HOP est toujours résolvable par les routeurs internes, quelle que soit la topologie IGP.

✅ Bonne pratique — Weight = 0 sur routes iBGP

Le Weight par défaut est 32768 pour les routes localement originées et 0 pour les routes reçues (eBGP et iBGP). Ne pas confondre : une route eBGP reçue a Weight=0 par défaut, pas 32768. Le Weight 32768 ne s'applique qu'aux routes injectées localement (network, redistribute).

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

Quel est le critère #7 de sélection BGP et que compare-t-il ?

Préférence eBGP > iBGP : si deux chemins sont égaux sur les critères 1–6, le chemin appris via une session externe (AS différent) est préféré au chemin appris via une session interne (même AS).

→ Règle de sélection, pas un attribut BGP

Quelle est l'Administrative Distance d'eBGP ? D'iBGP ?

eBGP = 20 · iBGP = 200. L'AD est utilisée pour comparer BGP avec d'autres protocoles de routage, elle n'intervient pas dans l'algorithme de sélection BGP interne.

→ AD ≠ critère de sélection BGP

Comment forcer un chemin iBGP à être préféré à un chemin eBGP ?

Il faut agir sur un critère supérieur (#1–#6) : Weight plus élevé, LOCAL_PREF plus élevé, AS-PATH raccourci (sur l'eBGP), meilleur Origin (i vs e vs ?), ou MED plus bas. Le critère #7 lui-même ne peut pas être modifié.

→ Critère #7 non configurable directement

Pourquoi une route iBGP peut-elle être invalide (non installée) ?

Le NEXT_HOP d'une route iBGP est préservé (IP du peer eBGP externe). Si cette IP n'est pas accessible via l'IGP, la route est invalide. Solution : next-hop-self sur le border router, ou redistribution IGP.

→ NEXT_HOP must be reachable

Qu'est-ce que le split horizon iBGP et comment le contourner ?

Une route apprise via iBGP n'est pas re-annoncée à un autre peer iBGP. Cela empêche les boucles mais nécessite un full mesh (n*(n-1)/2 sessions) ou une solution scale : Route Reflector (ORIGINATOR_ID, CLUSTER_LIST) ou Confédération.

→ iBGP split horizon rule

Dans une confédération, une session CONFED eBGP est-elle traitée comme eBGP pour le critère #7 ?

Non. Les sessions CONFED eBGP (entre sub-AS d'une même confédération) sont traitées comme iBGP pour le critère #7. Elles n'ont donc pas l'avantage eBGP. L'AS_CONFED_SEQUENCE est utilisé dans l'AS-PATH mais retiré en sortie de la confédération.

→ Piège CCIE classique

Quel est le TTL par défaut d'une session eBGP ? Comment le modifier ?

TTL par défaut = 1 (peer directement connecté uniquement). Pour eBGP sur loopbacks : neighbor X ebgp-multihop 2 (ou plus) + neighbor X update-source Loopback0.

→ iBGP TTL = 255 (pas de limite)

Que montrent les marqueurs "external" et "internal" dans show ip bgp ?

valid, external, best → route apprise via eBGP, sélectionnée.
valid, internal → route apprise via iBGP, valide mais non sélectionnée si un chemin eBGP existe.
Le marqueur i en début de ligne dans le summary indique aussi une route iBGP.

→ Identification critère #7 dans la table