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 #12 n'est atteint que si tous les critères précédents (#1–#11) sont égaux entre deux chemins. Il est exclusif aux environnements Route Reflector : si aucun chemin ne porte de CLUSTER_LIST, ce critère ne départage rien.
Règle de comparaison
Longueur = nombre de sauts RR
La CLUSTER_LIST contient un Cluster-ID (4 octets) par Route Reflector traversé. Le chemin avec le moins de Cluster-IDs est préféré : il a traversé moins de RR, donc est plus proche de l'annonceur.
Anti-boucle avant comparaison
Avant même d'arriver au critère #12, un RR qui reçoit une route contenant son propre Cluster-ID dans la CLUSTER_LIST rejette la route immédiatement (boucle détectée). La comparaison ne porte que sur les routes acceptées.
Cas d'égalité
Si les deux chemins ont une CLUSTER_LIST de même longueur (ou ni l'un ni l'autre n'en a), le critère #12 ne départage pas → on passe au critère #13 : adresse IP du neighbor (lowest wins).
Chemin sans CLUSTER_LIST
Un chemin sans CLUSTER_LIST est arrivé directement (pas via RR). S'il est comparé à un chemin avec CLUSTER_LIST, le chemin sans CLUSTER_LIST est préféré car longueur 0 < longueur > 0.
Profil de l'attribut
Type code
10
Flags
Optional Non-Transitive
Qui l'ajoute
Route Reflector
Propagation
iBGP uniquement
Stripped vers eBGP
Oui — non-transitive
Taille unitaire
4 octets / Cluster-ID
Attribut lié
ORIGINATOR_ID (type 9)
La CLUSTER_LIST est supprimée automatiquement avant d'envoyer une route à un peer eBGP (attribut Non-Transitive). Elle ne quitte jamais l'AS. Cela signifie que le critère #12 n'est jamais actif pour des routes apprises via eBGP direct.
Pourquoi les Route Reflectors ?
Sans Route Reflectors, iBGP exige une full-mesh : chaque routeur doit avoir une session iBGP avec tous les autres. Pour n routeurs : n(n-1)/2 sessions. Les RR suppriment cette contrainte en réfléchissant les routes.
AS 65000
┌────────────────────────────────────────────────┐
│ │
│ ┌─────────────────┐ │
│ │ RR1 (Cluster │ │
│ │ ID: 1.1.1.1) │ │
│ │ RID: 1.1.1.1 │ │
│ └────────┬────────┘ │
│ iBGP │ iBGP │
│ (client) │ (client) │
│ ┌───────────────┘ ┌────────────┐ │
│ │ │ │ │
│ ▼ ▼ │ │
│ ┌─────────┐ ┌─────────┐ │ │
│ │ C1 │ │ C2 │ │ │
│ │(client) │ │(client) │ │ │
│ └─────────┘ └─────────┘ │ │
│ │ │
│ ┌───────────────────┐ │ │
│ │ RR2 (Cluster │◄───┘ │
│ │ ID: 2.2.2.2) │ iBGP peer │
│ │ RID: 2.2.2.2 │ (non-client) │
│ └────────┬──────────┘ │
│ iBGP│(client) │
│ ▼ │
│ ┌─────────┐ │
│ │ C3 │ │
│ │(client) │ │
│ └─────────┘ │
└────────────────────────────────────────────────┘
Règles de réflexion
| Source de la route | Reflété vers clients ? | Reflété vers non-clients ? | CLUSTER_LIST modifiée ? |
|---|---|---|---|
| Peer eBGP | ✓ Oui | ✓ Oui | Cluster-ID ajouté |
| Client iBGP | ✓ Oui (autres clients) | ✓ Oui | Cluster-ID ajouté |
| Non-client iBGP | ✓ Oui | ✗ Non (split horizon) | Cluster-ID ajouté |
Un RR n'ajoute son Cluster-ID à la CLUSTER_LIST que lorsqu'il réfléchit une route. Si le RR lui-même est le meilleur chemin (route reçue eBGP, installée localement), CLUSTER_LIST reste vide lors de l'annonce initiale.
Croissance de la CLUSTER_LIST selon le chemin
Annonceur (C1)
CLUSTER_LIST: (vide)
→ envoie au RR1
RR1 réfléchit →
CLUSTER_LIST: [1.1.1.1]
→ envoie au RR2
RR2 réfléchit →
CLUSTER_LIST: [2.2.2.2, 1.1.1.1]
→ envoie à C3
C3 reçoit
longueur = 2 (2 sauts RR)
Si C3 reçoit la même route via un chemin direct (sans passer par RR2), la CLUSTER_LIST serait
[1.1.1.1] (longueur 1) → ce chemin serait préféré au critère #12.Mécanisme anti-boucle
Avant de réfléchir une route, le RR vérifie si son propre Cluster-ID est déjà présent dans la CLUSTER_LIST reçue :
! ─── Vérification anti-boucle au niveau du RR ──────────────────────────
! Route reçue par RR1 (Cluster-ID = 1.1.1.1) :
!
! Cas 1 — CLUSTER_LIST reçue : [2.2.2.2]
! → 1.1.1.1 absent → OK, RR1 ajoute 1.1.1.1 et réfléchit
! → CLUSTER_LIST envoyée : [1.1.1.1, 2.2.2.2]
!
! Cas 2 — CLUSTER_LIST reçue : [2.2.2.2, 1.1.1.1]
! → 1.1.1.1 présent → BOUCLE DÉTECTÉE → route REJETÉE silencieusement
! → La route n'est pas installée, pas réfléchie
Structure de l'attribut CLUSTER_LIST
| Champ | Taille | Valeur |
|---|---|---|
| Flags | 1 octet | 0x80 — Optional, Non-Transitive, pas Partial |
| Type code | 1 octet | 10 |
| Length | 1 octet | 4 × nombre de Cluster-IDs (ex: 2 RRs → 8) |
| Value | 4n octets | Liste de Cluster-IDs (4 octets chacun), du plus récent au plus ancien |
Le Cluster-ID le plus récemment ajouté se trouve en premier dans la liste (prepend, comme AS-PATH). Pour comparer deux chemins au critère #12, on compare simplement le nombre de Cluster-IDs (length / 4), pas leur contenu.
Relation avec ORIGINATOR_ID (type 9)
| Attribut | Type | Contenu | Usage critère BGP |
|---|---|---|---|
ORIGINATOR_ID |
9 | Router-ID de l'annonceur original (ajouté par 1er RR) | Critère #11 (remplace Router-ID du peer) |
CLUSTER_LIST |
10 | Liste des Cluster-IDs traversés (1 par RR) | Critère #12 (shortest wins) |
Ces deux attributs sont toujours créés ensemble par le premier RR qui réfléchit une route. ORIGINATOR_ID n'est ajouté qu'une seule fois (par le 1er RR), alors que CLUSTER_LIST grandit à chaque RR traversé.
Cluster-ID vs Router-ID du RR
! ─── Relation Cluster-ID / Router-ID ──────────────────────────────────── ! ! Par défaut : Cluster-ID = Router-ID du RR ! → Si RR1 a RID = 1.1.1.1, son Cluster-ID = 1.1.1.1 ! ! Configuration manuelle : ! router bgp 65000 ! bgp cluster-id 10.0.0.1 ! → Cluster-ID = 10.0.0.1 (indépendant du RID) ! ! Pourquoi configurer manuellement ? ! Deux RRs dans le MÊME cluster (redondance) doivent avoir ! le MÊME Cluster-ID → sinon la route apparaît dans 2 clusters ! différents → la CLUSTER_LIST grossit inutilement de 2 entrées ! au lieu de 1 → critère #12 défavorisé sans raison. router bgp 65000 bgp cluster-id 10.0.0.1 ! même valeur sur RR1 et RR2 du cluster neighbor 10.1.1.2 route-reflector-client neighbor 10.1.1.3 route-reflector-client
Comparaison numérique (critère #12)
! ─── Exemple : R reçoit deux chemins vers 192.168.1.0/24 ────────────────
!
! Chemin A (via RR1 → RR2) :
! CLUSTER_LIST : [2.2.2.2, 1.1.1.1] ← longueur = 2
!
! Chemin B (via RR3 directement) :
! CLUSTER_LIST : [3.3.3.3] ← longueur = 1
!
! Critères #1 à #11 : tous égaux
! Critère #12 : longueur(B) = 1 < longueur(A) = 2
! → Chemin B préféré (CLUSTER_LIST plus courte)
!
! ─── Cas sans CLUSTER_LIST ──────────────────────────────────────────────
! Chemin C (route eBGP directe, pas de RR) :
! CLUSTER_LIST : absente ← longueur = 0
!
! Chemin D (via RR) :
! CLUSTER_LIST : [5.5.5.5] ← longueur = 1
!
! Critère #12 : longueur(C) = 0 < longueur(D) = 1
! → Chemin C préféré
Configuration Route Reflector de base
! ─── RR1 — Route Reflector avec clients ───────────────────────────────── router bgp 65000 bgp router-id 1.1.1.1 bgp cluster-id 1.1.1.1 ! optionnel si RID = Cluster-ID souhaité ! Clients du RR (les routes reçues d'eux sont réfléchies) neighbor 10.0.1.1 remote-as 65000 neighbor 10.0.1.1 update-source Loopback0 neighbor 10.0.1.1 route-reflector-client neighbor 10.0.1.2 remote-as 65000 neighbor 10.0.1.2 update-source Loopback0 neighbor 10.0.1.2 route-reflector-client ! Non-clients (autres RRs) — session iBGP normale neighbor 2.2.2.2 remote-as 65000 neighbor 2.2.2.2 update-source Loopback0
Deux RRs redondants dans le même cluster
! ─── Cluster avec 2 RRs (haute disponibilité) ─────────────────────────── ! ! RR1 et RR2 servent les mêmes clients. ! Ils doivent avoir le MÊME Cluster-ID pour éviter que ! la CLUSTER_LIST ne grossisse de 2 entrées à chaque passage. ! ! Résultat INCORRECT (Cluster-IDs différents) : ! Client → RR1 (ajoute 1.1.1.1) → RR2 (ajoute 2.2.2.2) → autre client ! CLUSTER_LIST = [2.2.2.2, 1.1.1.1] ← 2 entrées pour 1 seul cluster ! ! ── RR1 ── router bgp 65000 bgp router-id 1.1.1.1 bgp cluster-id 10.0.0.100 ! même cluster-id que RR2 neighbor 10.0.1.1 route-reflector-client neighbor 10.0.1.2 route-reflector-client ! ── RR2 ── router bgp 65000 bgp router-id 2.2.2.2 bgp cluster-id 10.0.0.100 ! même cluster-id que RR1 ← clé neighbor 10.0.1.1 route-reflector-client neighbor 10.0.1.2 route-reflector-client
Commandes de vérification
! ─── Vérifier la configuration RR ─────────────────────────────────────── show ip bgp summary ! vue globale des sessions show ip bgp neighbors 10.0.1.1 ! vérifier "route-reflector-client" show ip bgp 192.168.1.0/24 ! voir les chemins et CLUSTER_LIST ! ─── Chercher les routes avec CLUSTER_LIST ─────────────────────────────── show ip bgp regexp _ ! toutes les routes iBGP show ip bgp 192.168.1.0 255.255.255.0 ! chemin détaillé ! ─── Identifier un RR dans la table ───────────────────────────────────── show ip bgp 10.10.10.0/24 ! BGP routing table entry for 10.10.10.0/24 ! Paths: (2 available, best #1) ! Advertised to update-groups: ! 1 ! 65100 ! 10.0.1.1 from 2.2.2.2 (2.2.2.2) ! Origin IGP, metric 0, localpref 100, valid, internal, best ! Originator: 10.0.1.1, Cluster list: 2.2.2.2, 1.1.1.1 ! ─────────────────────────────────────────── ! ORIGINATOR_ID (type 9) CLUSTER_LIST (type 10) ! rx pathid: 0, tx pathid: 0x0
La ligne
Cluster list: dans show ip bgp affiche les Cluster-IDs dans l'ordre de la liste (du plus récent au plus ancien). Le nombre d'entrées est ce qui compte pour le critère #12.Scénario — Deux chemins via RRs différents
Topologie :
CE1──────────────────────────────────────────CE2
(eBGP) (eBGP)
│ │
PE1 (RR client) PE2 (RR client)
│ │
└──────► RR1 (Cluster 1.1.1.1) ──────────►│
│ │
└──────► RR2 ──► RR3 (Cluster 3.3.3.3) ──►│
PE2 reçoit le préfixe 10.10.10.0/24 via deux chemins :
Chemin A : PE1 → RR1 → PE2 CLUSTER_LIST : [1.1.1.1] (1 saut RR)
Chemin B : PE1 → RR2 → RR3 → PE2 CLUSTER_LIST : [3.3.3.3, 2.2.2.2] (2 sauts RR)
PE2# show ip bgp 10.10.10.0/24 BGP routing table entry for 10.10.10.0/24, version 12 Paths: (2 available, best #1, table default) Not advertised to any peer Refresh Epoch 1 65100 10.0.1.1 from 1.1.1.1 (1.1.1.1) ← via RR1 Origin IGP, metric 0, localpref 100, valid, internal, best Originator: 10.0.1.1, Cluster list: 1.1.1.1 ↑ longueur = 1 ← GAGNE critère #12 rx pathid: 0, tx pathid: 0x0 Refresh Epoch 1 65100 10.0.3.1 from 3.3.3.3 (3.3.3.3) ← via RR2→RR3 Origin IGP, metric 0, localpref 100, valid, internal Originator: 10.0.1.1, Cluster list: 3.3.3.3, 2.2.2.2 ↑ longueur = 2 ← PERD critère #12 rx pathid: 0, tx pathid: 0
Lecture du résultat
| Critère | Chemin A (RR1) | Chemin B (RR2→RR3) | Résultat |
|---|---|---|---|
| #1 à #10 | Identiques (même LOCAL_PREF, même AS-PATH, même IGP…) | Égalité | |
| #11 Router-ID | ORIG_ID = 10.0.1.1 | ORIG_ID = 10.0.1.1 | Égalité |
| #12 Cluster-list | longueur = 1 | longueur = 2 | Chemin A gagne |
Vérifier le Cluster-ID local
RR1# show ip bgp neighbors 10.0.1.2 BGP neighbor is 10.0.1.2, remote AS 65000, internal link BGP version 4, remote router ID 10.0.1.2 ... Route-Reflector Client RR1# show running-config | section router bgp router bgp 65000 bgp cluster-id 1.1.1.1 neighbor 10.0.1.1 route-reflector-client neighbor 10.0.1.2 route-reflector-client
Piège 1 — RRs redondants avec Cluster-IDs différents
Problème : deux RRs dans le même cluster (pour la redondance) ont des Cluster-IDs différents. Chaque RR ajoute son propre Cluster-ID → la CLUSTER_LIST contient 2 entrées inutiles → le critère #12 est faussé et les routes arrivent pénalisées chez les clients.
! ── Symptôme ── ! Client reçoit la même route via RR1 et RR2 (redondants) ! CLUSTER_LIST via RR1 : [1.1.1.1] ← attendu ! CLUSTER_LIST via RR2 : [2.2.2.2] ← attendu ! Mais après réflexion inter-RR : ! CLUSTER_LIST : [2.2.2.2, 1.1.1.1] ← 2 entrées pour 1 cluster ! ! ! ── Fix ── router bgp 65000 bgp cluster-id 10.0.0.100 ! MÊME valeur sur RR1 et RR2
Piège 2 — Anti-boucle mal configuré (cluster-id absent)
Problème : si
bgp cluster-id n'est pas configuré, le Cluster-ID = Router-ID du RR. Si deux RRs différents ont accidentellement le même Router-ID (mauvaise config), le mécanisme anti-boucle peut rejeter des routes légitimes.! Vérification — s'assurer que les Cluster-IDs sont uniques entre clusters show ip bgp neighbors | include cluster show running-config | include cluster-id
Piège 3 — CLUSTER_LIST non visible sur peer eBGP
La CLUSTER_LIST est Non-Transitive → elle est retirée avant d'envoyer la route à un peer eBGP. Si on fait un
show ip bgp sur un routeur eBGP voisin, la CLUSTER_LIST n'apparaît pas. Ce comportement est normal.! Sur un routeur eBGP qui reçoit la route depuis l'AS :
! → Cluster list: absent ← normal, attribut stripped avant envoi eBGP
! → Originator: absent ← idem, ORIGINATOR_ID aussi stripped
Piège 4 — Critère #12 jamais atteint en full-mesh iBGP
Dans un réseau iBGP full-mesh (sans Route Reflectors), aucune route ne porte de CLUSTER_LIST. Le critère #12 ne peut donc jamais départager deux chemins : on passe directement du critère #11 au critère #13. C'est un point d'examen CCIE courant.
Piège 5 — Hiérarchie RR multi-niveaux
Dans une hiérarchie RR (RR de 1er niveau → RR de 2ème niveau → clients), chaque niveau ajoute son Cluster-ID. Les routes traversant plus de niveaux accumulent plus d'entrées → critère #12 les pénalise. Il faut concevoir la topologie RR pour minimiser les niveaux.
! Route dans une hiérarchie 3 niveaux :
! CLUSTER_LIST : [3.3.3.3, 2.2.2.2, 1.1.1.1] ← longueur = 3
!
! Route dans hiérarchie 2 niveaux :
! CLUSTER_LIST : [2.2.2.2, 1.1.1.1] ← longueur = 2
!
! Au critère #12 : la route 2 niveaux gagne (longueur plus courte)
Cliquez sur une carte pour révéler la réponse.
Que compare le critère #12 de la sélection BGP ?
La longueur de la CLUSTER_LIST (nombre de Cluster-IDs). Le chemin avec le moins de Cluster-IDs est préféré : il a traversé moins de Route Reflectors. Si aucun chemin n'a de CLUSTER_LIST, ce critère ne départage pas.
→ Shortest CLUSTER_LIST wins
Quel est le type code de CLUSTER_LIST ? Et ses flags ?
Type code 10. Flags : Optional, Non-Transitive (0x80). Il n'est donc jamais transmis à un peer eBGP et ne quitte jamais l'AS. L'attribut associé ORIGINATOR_ID est type 9, également Optional Non-Transitive.
→ Type 10 · Optional Non-Transitive · stripé vers eBGP
Comment fonctionne l'anti-boucle de la CLUSTER_LIST ?
Avant de réfléchir une route, le RR vérifie si son propre Cluster-ID figure dans la CLUSTER_LIST reçue. Si oui → la route est rejetée silencieusement (boucle de réflexion détectée). Si non → le RR ajoute son Cluster-ID et réfléchit la route.
→ Mon Cluster-ID déjà présent = boucle = route droppée
Deux RRs couvrent les mêmes clients (redondance). Que configurer pour éviter de gonfler inutilement la CLUSTER_LIST ?
Configurer le même Cluster-ID sur les deux RRs avec
bgp cluster-id X.X.X.X. Ainsi, quand la route passe par les deux RRs, un seul Cluster-ID est ajouté au lieu de deux. Le mécanisme anti-boucle fonctionne toujours car les deux RRs partagent le même ID.
→ Même cluster → même cluster-id sur tous les RRs du cluster
Un chemin sans CLUSTER_LIST est-il préféré à un chemin avec CLUSTER_LIST au critère #12 ?
Oui. Un chemin sans CLUSTER_LIST a une longueur effective de 0. Tout chemin avec une CLUSTER_LIST non-vide a une longueur ≥ 1. Le critère #12 préfère la longueur la plus courte → le chemin direct (sans RR) gagne.
→ Longueur 0 (absent) < longueur ≥ 1 (présent)
Dans quel cas le critère #12 n'est-il jamais actif ?
Dans un réseau iBGP en full-mesh sans Route Reflectors. Aucune route ne porte de CLUSTER_LIST dans ce cas : l'attribut n'est créé que par les RR lors de la réflexion. Sans RR, on passe directement du critère #11 (Router-ID) au critère #13 (Neighbor IP).
→ Full-mesh iBGP → pas de CLUSTER_LIST → #12 inopérant
Comment identifier la CLUSTER_LIST dans la sortie de show ip bgp ?
Dans
show ip bgp X.X.X.X/Y, la ligne Cluster list: A.A.A.A, B.B.B.B affiche les Cluster-IDs du plus récent au plus ancien. Le nombre d'IDs listés = longueur de la CLUSTER_LIST = nombre de sauts RR. La ligne Originator: Z.Z.Z.Z juste avant indique l'ORIGINATOR_ID.
→ "Cluster list: X, Y" → 2 RRs traversés
Si le critère #12 est également égal (même longueur), quel critère s'applique ?
Le critère #13 — adresse IP du neighbor (lowest wins). C'est le dernier critère de l'algorithme BGP. Si deux chemins arrivent à égalité sur tous les 13 critères, le routeur Cisco utilise l'adresse IP la plus basse du peer comme tie-breaker final.
→ #12 égal → #13 Lowest Neighbor IP (dernier critère)