BGP · Neighbor IP · Critère #13

Position dans l'algorithme

1Weight

2LOCAL_PREF

3NH=0.0.0.0

4AS-PATH

5Origin

6MED

7eBGP>iBGP

8IGP metric

9AIGP

10Oldest

11Router-ID

12Cluster-list

13Neighbor IP

Le critère #13 est le dernier recours : il n'est atteint que si les 12 critères précédents sont tous égaux. C'est le seul critère garantissant toujours un résultat unique, car deux sessions BGP ne peuvent avoir la même adresse peer.

Règle de comparaison

🔢

Adresse IP du peer (neighbor address)

L'adresse comparée est l'adresse du peer BGP (celle configurée dans neighbor X.X.X.X), pas son Router-ID ni son ORIGINATOR_ID. C'est l'adresse source des messages BGP reçus.

🏆

Lowest wins

La comparaison est numérique sur 32 bits (IPv4) : l'adresse la plus faible numériquement est préférée. Pour IPv6, la comparaison se fait également numériquement sur 128 bits.

✅

Toujours déterministe

Contrairement au critère #10 (Oldest eBGP), le critère #13 donne toujours le même résultat indépendamment de l'ordre d'arrivée des routes ou du temps de fonctionnement des sessions.

🚪

Porte fermée

Après le critère #13, aucun autre critère n'existe. Un seul chemin est toujours sélectionné. Si multipath est activé, les chemins égaux peuvent être installés ensemble en ECMP (avant le critère #13).

Profil du critère

Position

Critère final — #13/13

Valeur comparée

Adresse IP du neighbor

Résultat

Lowest wins

Déterministe

Oui — toujours

Attribut BGP

Aucun (local)

Configurable

Non

💡

En pratique, atteindre le critère #13 est très rare dans un réseau bien conçu. Si deux chemins arrivent jusqu'au critère #13, cela signifie que les critères #1 à #12 ont tous été égaux — ce qui implique généralement une topologie symétrique parfaite ou une mauvaise politique de routage.

Adresse comparée : neighbor address vs Router-ID

Critère	Valeur comparée	Source	Lowest wins
#11 Router-ID	Router-ID du peer (ou ORIGINATOR_ID si RR présent)	Attribut OPEN / ORIGINATOR_ID	✓
#13 Neighbor IP	Adresse IP du neighbor (neighbor statement)	Configuration locale	✓

⚠️

Ne pas confondre Neighbor IP (adresse peer BGP, critère #13) et Router-ID (identifiant BGP du routeur, critère #11). Un routeur peut avoir un Router-ID 1.1.1.1 mais être peered via l'adresse 10.0.0.2 — c'est 10.0.0.2 qui compte pour le critère #13.

Exemples de comparaisons IPv4

Peer A

10.0.0.1

Peer B

10.0.0.2

→ Peer A gagne (10.0.0.1 < 10.0.0.2)

Peer A

172.16.1.1

Peer B

10.255.255.1

→ Peer B gagne (10.x.x.x < 172.x.x.x numériquement)

Peer A

192.168.0.1

Peer B

1.1.1.1

→ Peer B gagne (1.1.1.1 < 192.168.0.1 numériquement)

Comparaison numérique IPv4 — comment ça marche

! ─── Conversion en décimal 32 bits ─────────────────────────────────────
!
! 10.0.0.1   → 0x0A 00 00 01 → 167,772,161
! 10.0.0.2   → 0x0A 00 00 02 → 167,772,162
! 172.16.1.1 → 0xAC 10 01 01 → 2,886,729,985
!
! Règle : l'adresse avec la valeur décimale la plus faible gagne.
! En pratique : comparer octet par octet de gauche à droite,
!   s'arrêter au premier octet différent.
!
! Exemple :
!   192.168.10.1  vs  192.168.10.2
!   1er octet : 192 = 192 → continuer
!   2ème octet: 168 = 168 → continuer
!   3ème octet:  10 = 10  → continuer
!   4ème octet:   1 < 2   → 192.168.10.1 gagne ✅

Cas IPv6

! ─── Neighbor IP en IPv6 ────────────────────────────────────────────────
!
! La même logique s'applique : comparaison numérique sur 128 bits.
! La plus petite adresse IPv6 numériquement gagne.
!
! Exemple :
!   Peer A : 2001:db8::1   → numériquement plus petite
!   Peer B : 2001:db8::2   → numériquement plus grande
!   → Peer A gagne
!
! Note : les adresses IPv6 link-local (fe80::/10) peuvent être utilisées
! comme adresses de peer BGP avec "neighbor fe80::X link-local"

router bgp 65000
 neighbor 2001:db8::1 remote-as 65000
 neighbor 2001:db8::1 update-source Loopback0

Identifier la neighbor address dans show ip bgp

! ─── Lire la neighbor address dans la table BGP ─────────────────────────
R1# show ip bgp 10.10.10.0/24

BGP routing table entry for 10.10.10.0/24, version 8
Paths: (2 available, best #1, table default)
  65100
    10.0.0.1 from 10.0.0.1 (1.1.1.1)       ← neighbor address = 10.0.0.1
      Origin IGP, valid, internal, best
      rx pathid: 0, tx pathid: 0x0

  65100
    10.0.0.1 from 10.0.0.2 (2.2.2.2)       ← neighbor address = 10.0.0.2
      Origin IGP, valid, internal
      rx pathid: 0, tx pathid: 0
!
! Critère #13 : 10.0.0.1 < 10.0.0.2 → chemin via 10.0.0.1 sélectionné ✅

Multipath : avant le critère #13

Lorsque maximum-paths est configuré, BGP peut installer plusieurs chemins en ECMP dans la RIB avant d'atteindre le critère #13. Si deux chemins sont égaux jusqu'au critère #12, ils sont tous deux installés (ECMP) — le critère #13 sert uniquement à désigner le chemin best pour l'annonce aux peers.

⚖️

ECMP iBGP

Chemins iBGP égaux (même IGP metric, même AS-PATH...). Activé par maximum-paths ibgp N. Les chemins sont installés ensemble. Un seul est désigné "best" (critère #13 si nécessaire) pour l'annonce.

🔀

ECMP eBGP

Chemins eBGP égaux vers le même préfixe. Activé par maximum-paths N. Peut nécessiter bgp bestpath as-path multipath-relax si les AS-PATHs diffèrent.

🎯

Best path pour l'annonce

Même avec ECMP actif, BGP désigne un seul chemin "best" qu'il annonce aux peers. C'est ce chemin best qui est déterminé par les 13 critères (dont #13 en dernier recours).

Interaction multipath / critère #13

! ─── Scénario : 2 chemins iBGP égaux jusqu'au critère #12 ───────────────
router bgp 65000
 maximum-paths ibgp 2               ! autorise 2 chemins en ECMP
 bgp bestpath as-path multipath-relax  ! si AS-PATHs légèrement différents

! Résultat :
!   - Les 2 chemins sont installés en ECMP dans la FIB (load-sharing)
!   - Le chemin avec la plus petite neighbor IP est désigné "best"
!     et annoncé aux peers BGP
!
! Vérification :
show ip bgp 10.10.10.0/24
!   Paths: (2 available, best #1, table default)
!           ↑ 2 chemins installés = ECMP actif

show ip route 10.10.10.0
!   B     10.10.10.0/24 [200/0]
!            via 10.0.0.1, ...   ← chemin best (neighbor IP la plus basse)
!            via 10.0.0.2, ...   ← chemin ECMP (installé mais pas "best")

ℹ️

Le critère #13 ne s'applique qu'au moment de désigner le chemin "best" parmi les chemins ECMP. Le load-balancing dans la FIB est indépendant : tous les chemins ECMP sont utilisés pour le forwarding, quel que soit lequel est "best".

Scénario complet — critère #13 comme tie-breaker final

Topologie : AS 65000 AS 65100 ┌──────────────────────────────┐ ┌────────────────┐ │ │ eBGP │ │ │ R1 ── RR ──────────────────►│◄──────►│ CE1 │ │ │ │ │ (annonce │ │ └────────────────► │◄──────► │ 10.10.10.0) │ │ R2 │ │ │ └──────────────────────────────┘ └────────────────┘ R1 reçoit 10.10.10.0/24 via deux sessions iBGP : Chemin A : via RR, neighbor address = 10.0.1.1 Chemin B : via R2, neighbor address = 10.0.1.2 Critères #1 à #12 : tous identiques

R1# show ip bgp 10.10.10.0/24

BGP routing table entry for 10.10.10.0/24, version 5
Paths: (2 available, best #1, table default)
  Not advertised to any peer

  Refresh Epoch 3
  65100
    172.16.100.1 from 10.0.1.1 (1.1.1.1)    ← neighbor addr = 10.0.1.1
      Origin IGP, metric 0, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0
      ↑ 10.0.1.1 < 10.0.1.2 → critère #13 → GAGNE ✅

  Refresh Epoch 3
  65100
    172.16.100.1 from 10.0.1.2 (2.2.2.2)    ← neighbor addr = 10.0.1.2
      Origin IGP, metric 0, localpref 100, valid, internal
      rx pathid: 0, tx pathid: 0
      ↑ 10.0.1.2 > 10.0.1.1 → PERD ❌

Récapitulatif de la sélection

Critère	Chemin A (10.0.1.1)	Chemin B (10.0.1.2)	Résultat
#1 Weight	0	0	Égalité
#2 LOCAL_PREF	100	100	Égalité
#3–#6	Identiques		Égalité
#7 eBGP/iBGP	iBGP	iBGP	Égalité
#8 IGP metric	10	10	Égalité
#9–#12	Identiques		Égalité
#13 Neighbor IP	10.0.1.1	10.0.1.2	Chemin A gagne

Vérifier quelle neighbor address a été utilisée

R1# show ip bgp 10.10.10.0 | include from
    172.16.100.1 from 10.0.1.1 (1.1.1.1)   ← format: NEXT_HOP from NEIGHBOR_IP (ROUTER_ID)
    172.16.100.1 from 10.0.1.2 (2.2.2.2)

! La valeur entre "from" et "(" est la neighbor IP (critère #13)
! La valeur entre "(" et ")" est le Router-ID (critère #11)

Tableau récapitulatif des 13 critères

#	Critère	Valeur préférée	Portée	Configurable
1	Weight	Highest	Local (Cisco)	✓
2	LOCAL_PREF	Highest	iBGP AS	✓
3	Locally Originated (NH=0.0.0.0)	Préféré	Local	—
4	AS-PATH length	Shortest	Universel	✓
5	Origin (IGP > EGP > ?)	IGP	Universel	✓
6	MED	Lowest	Entre AS voisins	✓
7	eBGP > iBGP	eBGP	Local	—
8	IGP metric vers NEXT_HOP	Lowest	Local	—
9	AIGP (RFC 7311)	Lowest	Inter-AS	✓
10	Oldest eBGP path	Plus ancienne	Local · eBGP only	—
11	Router-ID (ou ORIGINATOR_ID)	Lowest	Local	—
12	Cluster-list length	Shortest	Local · RR only	—
13	Neighbor IP	Lowest	Local	—

Commandes qui modifient l'ordre des critères

! ─── bgp bestpath compare-routerid ──────────────────────────────────────
! Saute le critère #10 (Oldest eBGP) → passe directement au #11 (Router-ID)
! Rend la sélection déterministe pour les routes eBGP
router bgp 65000
 bgp bestpath compare-routerid

! ─── bgp bestpath as-path ignore ────────────────────────────────────────
! Ignore le critère #4 (AS-PATH length)
router bgp 65000
 bgp bestpath as-path ignore

! ─── bgp bestpath med missing-as-worst ──────────────────────────────────
! Traite un MED absent comme 4294967295 (pire valeur)
router bgp 65000
 bgp bestpath med missing-as-worst

! ─── bgp bestpath igp-metric ignore ─────────────────────────────────────
! Ignore le critère #8 (IGP metric vers NEXT_HOP)
router bgp 65000
 bgp bestpath igp-metric ignore

Préalable : NEXT_HOP reachable

⚠️

Avant même d'entrer dans l'algorithme des 13 critères, une route BGP doit avoir son NEXT_HOP résolvable dans la RIB. Si le NEXT_HOP est inaccessible, la route est marquée invalide (i) et exclue de la sélection.

! Vérifier les routes invalides (NEXT_HOP non résolvable) :
show ip bgp | include ^i                    ! routes invalides
show ip bgp X.X.X.X/Y | include inaccessible   ! NEXT_HOP inaccessible

Piège 1 — Confondre Neighbor IP et Router-ID

⚠️

Erreur fréquente : croire que le critère #13 compare le Router-ID du peer. Non — il compare l'adresse IP de la session BGP (la valeur dans neighbor X remote-as Y). Un routeur peut avoir Router-ID 1.1.1.1 mais être peered via 10.0.0.5. C'est 10.0.0.5 qui est comparé au critère #13.

! show ip bgp format : from NEIGHBOR_IP (ROUTER_ID)
!                                ↑           ↑
!                           critère #13  critère #11
show ip bgp 10.10.10.0/24
!   from 10.0.0.5 (1.1.1.1)   ← critère #13 = 10.0.0.5
!                                 critère #11 = 1.1.1.1

Piège 2 — Croire que le critère #13 est rarement utile

ℹ️

En exam CCIE, des scénarios construisent exprès une égalité sur les critères #1–#12 pour tester si le candidat sait que c'est l'adresse IP du neighbor (et non le Router-ID ou le MED) qui décide en dernier recours. Apprendre la différence entre #11, #12 et #13.

Piège 3 — Après le critère #13, il n'y a pas de critère #14

💡

Le critère #13 est toujours déterministe car deux sessions BGP ne peuvent jamais avoir la même adresse peer. Après ce critère, un et un seul chemin est sélectionné. Il n'existe pas de critère #14 dans l'algorithme BGP standard Cisco IOS.

Piège 4 — Multipath installe avant le critère #13

⚠️

Si maximum-paths est configuré et que deux chemins sont égaux jusqu'au critère #12, ils sont tous deux installés en ECMP avant que le critère #13 ne soit évalué pour désigner le "best". Le critère #13 ne supprime pas les chemins ECMP — il choisit simplement lequel est announcé aux peers.

Piège 5 — Impact du critère #13 sur l'annonce aux peers

! ─── Seul le chemin "best" est annoncé aux peers iBGP ───────────────────
!
! Même en ECMP (maximum-paths 2), BGP n'annonce qu'UN seul chemin.
! C'est le chemin avec la plus petite neighbor IP (critère #13) qui
! est sélectionné comme "best" et donc annoncé.
!
! Conséquence en topologie asymétrique :
!   Si R1 a neighbor IP 10.0.0.1 (via RR1) et 10.0.0.2 (via RR2),
!   R1 annonce toujours la route reçue de 10.0.0.1 (RR1).
!   Les peers de R1 ne voient jamais le chemin via RR2 comme "best".
!
! Solution : s'assurer que la politique de routage (LOCAL_PREF, MED,
! AS-PATH) différencie les chemins AVANT d'atteindre le critère #13.

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

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

L'adresse IP du neighbor (adresse de la session BGP configurée avec neighbor X remote-as Y). La plus petite adresse IP numériquement gagne. Ce n'est pas le Router-ID du peer (comparé au critère #11).

→ Neighbor address, pas Router-ID — lowest wins

Pourquoi le critère #13 est-il toujours déterministe ?

Parce que deux sessions BGP ne peuvent jamais avoir la même adresse peer sur un même routeur. Contrairement au critère #10 (Oldest eBGP, qui dépend de l'ordre d'arrivée), le critère #13 donne toujours le même résultat indépendamment du temps ou de l'ordre des événements.

→ Adresses IP uniques → résultat toujours identique

Comment lire la neighbor IP et le Router-ID dans show ip bgp X.X.X.X/Y ?

Format : from NEIGHBOR_IP (ROUTER_ID). La valeur entre from et la parenthèse est la neighbor IP (critère #13). La valeur entre parenthèses est le Router-ID du peer (critère #11). Exemple : from 10.0.0.5 (1.1.1.1) → critère #13 = 10.0.0.5, critère #11 = 1.1.1.1.

→ from 10.0.0.5 (1.1.1.1) : NIP=10.0.0.5 / RID=1.1.1.1

Existe-t-il un critère #14 dans l'algorithme BGP ?

Non. Le critère #13 (Neighbor IP) est le dernier. Après ce critère, un et un seul chemin est nécessairement sélectionné car les adresses IP de session sont uniques. Il n'existe pas de critère au-delà dans l'algorithme BGP standard Cisco IOS.

→ #13 = dernier critère, toujours conclusif

Quelle est la mnémotechnique des 13 critères BGP ?

W·L·L·A·O·M·E·I·A·O·R·C·N : Weight → LOCAL_PREF → Locally originated → AS-PATH → Origin → MED → eBGP>iBGP → IGP metric → AIGP → Oldest eBGP → Router-ID → Cluster-list → Neighbor IP.

→ We Love Local AS Origins, Many Engineers Install At Our Router Clusters Now

Si maximum-paths 2 est configuré et deux chemins sont égaux jusqu'au critère #12, que se passe-t-il au critère #13 ?

Les deux chemins sont déjà installés en ECMP dans la FIB (load-balancing actif). Le critère #13 sert uniquement à désigner lequel des deux est le chemin best annoncé aux peers BGP. Celui avec la plus petite neighbor IP est "best" — mais les deux restent actifs pour le forwarding.

→ ECMP installé avant #13 · #13 choisit le "best" pour l'annonce

Quelle commande rend la sélection BGP déterministe en sautant le critère #10 ?

bgp bestpath compare-routerid sous router bgp. Elle supprime le critère #10 (Oldest eBGP path, non-déterministe) et passe directement au critère #11 (Router-ID, déterministe). Fortement recommandée en environnement multi-homed ou multi-border-router.

→ compare-routerid : saute #10, va à #11 directement

Deux routeurs reçoivent le même préfixe. R1 compare neighbor IP 10.0.0.1 vs 192.168.1.1. Lequel gagne ?

10.0.0.1 gagne. La comparaison est numérique 32 bits : 10.0.0.1 = 167,772,161 et 192.168.1.1 = 3,232,235,777. La valeur 10.0.0.1 est numériquement inférieure malgré l'adresse visuellement "petite" de 192.168.x.x.

→ Comparaison numérique 32 bits — 10.x.x.x < 192.x.x.x

Neighbor IP — Lowest wins

Adresse IP du peer (neighbor address)

Lowest wins

Toujours déterministe

Porte fermée

ECMP iBGP

ECMP eBGP

Best path pour l'annonce

🎯 Algorithme BGP Best Path — Complet