Mécanisme de scalabilité iBGP qui supprime l'obligation de full-mesh. Un RR réfléchit les routes entre ses clients sans que ceux-ci aient besoin de sessions directes entre eux.
La règle iBGP fondamentale : un routeur ne réannonce pas à un peer iBGP une route apprise via iBGP (iBGP split-horizon). Sans mécanisme correctif, tous les routeurs iBGP d'un AS doivent avoir une session directe avec tous les autres.
| Nombre de routeurs | Sessions full-mesh requises | Verdict |
|---|---|---|
| 5 | 10 | ✓ Gérable |
| 10 | 45 | ⚠ Complexe |
| 50 | 1 225 | ✗ Ingérable |
| 100 | 4 950 | ✗ Hors de question |
Routeur configuré pour réfléchir (relayer) les routes iBGP à ses clients. Il contourne l'iBGP split-horizon pour les routes venant de ses clients. Configuré avec route-reflector-client sur les neighbors concernés.
Routeur qui a une session iBGP avec le RR et est déclaré comme client (route-reflector-client du côté RR). N'a pas besoin de sessions avec les autres clients — c'est le RR qui leur transmet les routes.
Routeur iBGP du même AS qui n'est pas client du RR. Les routes apprises d'un non-client ne sont pas réfléchies vers les autres non-clients (split-horizon classique maintenu). Typiquement un autre RR.
Ensemble formé par un RR et ses clients. Identifié par un Cluster-ID (par défaut = Router-ID du RR). Plusieurs clusters peuvent coexister dans le même AS, avec ou sans hiérarchie.
route-reflector-client est unilatérale, côté RR uniquement. Le client voit juste un peer iBGP normal.Le comportement du RR dépend de la source de la route reçue :
Avant de réfléchir une route, le RR effectue deux vérifications :
Si le propre Cluster-ID du RR est déjà présent dans la CLUSTER_LIST de la route reçue → route rejetée silencieusement. Boucle de réflexion détectée.
Si le Router-ID local du routeur correspond à l'ORIGINATOR_ID de la route reçue → route rejetée. Le routeur est lui-même l'annonceur original.
Quand un RR réfléchit une route pour la première fois, il ajoute deux attributs BGP :
| Attribut | Type | Flags | Contenu | Critère best-path |
|---|---|---|---|---|
ORIGINATOR_ID |
9 | Optional Non-Transitive | Router-ID de l'annonceur original — ajouté une seule fois par le 1er RR | #11 (remplace Router-ID du peer) |
CLUSTER_LIST |
10 | Optional Non-Transitive | Liste des Cluster-IDs traversés — chaque RR prepend son Cluster-ID | #12 (shortest wins) |
show ip bgp ne les affichera pas — c'est normal.! Annonceur C1 envoie 192.168.10.0/24 au RR1
! ─────────────────────────────────────────────────────────────────────
!
! C1 → RR1 :
! ORIGINATOR_ID : (absent) CLUSTER_LIST : (absente)
!
! RR1 réfléchit → C2, C3, RR2 :
! ORIGINATOR_ID : 10.0.1.1 CLUSTER_LIST : [1.1.1.1]
! (Router-ID C1) (Cluster-ID RR1)
!
! RR2 réfléchit → C4, C5 :
! ORIGINATOR_ID : 10.0.1.1 CLUSTER_LIST : [2.2.2.2, 1.1.1.1]
! (inchangé !) (RR2 prepend son ID)
!
! C4 reçoit :
! ORIGINATOR_ID : 10.0.1.1 CLUSTER_LIST : [2.2.2.2, 1.1.1.1]
! longueur = 2 sauts RR
! ── RR1 : configuration Route Reflector ───────────────────────────────── router bgp 65000 bgp router-id 1.1.1.1 ! Cluster-ID = Router-ID par défaut — configurer explicitement recommandé bgp cluster-id 1.1.1.1 ! ── Clients (sessions avec route-reflector-client) ── 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 neighbor 10.0.1.3 remote-as 65000 neighbor 10.0.1.3 update-source Loopback0 neighbor 10.0.1.3 route-reflector-client ! ── Clients n'ont PAS besoin de session entre eux ── ! C1, C2, C3 : aucune configuration iBGP inter-client nécessaire
! ── Deux RRs pour la HA — MÊME Cluster-ID obligatoire ─────────────────── ! ! Si RR1 et RR2 ont des Cluster-IDs différents : ! Route C1 → RR1 → RR2 → C3 : CLUSTER_LIST = [2.2.2.2, 1.1.1.1] (2 IDs) ! ! Avec le MÊME Cluster-ID : ! Route C1 → RR1 → RR2 → C3 : CLUSTER_LIST = [10.0.0.100] (1 seul ID) ! → CLUSTER_LIST plus courte → meilleur au critère #12 ! ── RR1 ── router bgp 65000 bgp router-id 1.1.1.1 bgp cluster-id 10.0.0.100 ! même valeur sur RR1 et RR2 neighbor 10.0.1.1 remote-as 65000 neighbor 10.0.1.1 route-reflector-client neighbor 10.0.1.2 remote-as 65000 neighbor 10.0.1.2 route-reflector-client neighbor 2.2.2.2 remote-as 65000 ! RR2 = non-client (peer iBGP normal) neighbor 2.2.2.2 update-source Loopback0 ! ── RR2 ── router bgp 65000 bgp router-id 2.2.2.2 bgp cluster-id 10.0.0.100 ! même que RR1 — clé de la config neighbor 10.0.1.1 remote-as 65000 neighbor 10.0.1.1 route-reflector-client neighbor 10.0.1.2 remote-as 65000 neighbor 10.0.1.2 route-reflector-client neighbor 1.1.1.1 remote-as 65000 ! RR1 = non-client neighbor 1.1.1.1 update-source Loopback0
! ── RR de niveau 1 (RR-TOP) — ses clients sont des RRs de niveau 2 ────── router bgp 65000 bgp router-id 10.10.10.1 bgp cluster-id 10.10.10.1 ! Les RRs de niveau 2 sont clients du RR-TOP neighbor 1.1.1.1 remote-as 65000 neighbor 1.1.1.1 route-reflector-client ! RR niveau 2 — région Ouest neighbor 2.2.2.2 remote-as 65000 neighbor 2.2.2.2 route-reflector-client ! RR niveau 2 — région Est ! ── RR de niveau 2 (RR-OUEST) — ses clients sont les PE/PE routeurs ───── router bgp 65000 bgp router-id 1.1.1.1 bgp cluster-id 1.1.1.1 ! Client = RR-TOP (non-client du point de vue de RR-OUEST) neighbor 10.10.10.1 remote-as 65000 neighbor 10.10.10.1 update-source Loopback0 ! NON route-reflector-client ! Clients PE de la région Ouest neighbor 10.0.1.1 remote-as 65000 neighbor 10.0.1.1 route-reflector-client neighbor 10.0.1.2 remote-as 65000 neighbor 10.0.1.2 route-reflector-client
1 RR, N clients. Élimine la full-mesh mais crée un SPOF. Convient aux petits AS ou pour les labs CCIE.
2 RRs (même cluster-id) servent les mêmes clients. Chaque client a 2 sessions iBGP. Haute disponibilité sans SPOF.
Pour les très grands AS (opérateurs). RR de niveau 1 (core) → RR de niveau 2 (régional) → clients PE. Chaque niveau ajoute un Cluster-ID → pénalise légèrement le critère #12.
Plusieurs clusters indépendants dans le même AS. Chaque cluster a son propre RR. Les RRs forment une mini full-mesh entre eux (non-clients). Topologie typique des gros datacenters et providers.
Les Route Reflectors introduisent deux nouveaux critères dans l'algorithme BGP :
| Critère | Attribut | Règle | Condition |
|---|---|---|---|
| #11 | ORIGINATOR_ID |
Lowest ORIGINATOR_ID wins | Remplace le critère Router-ID du peer quand ORIGINATOR_ID est présent |
| #12 | CLUSTER_LIST |
Shortest CLUSTER_LIST wins | Nombre de Cluster-IDs (sauts RR). Absent = longueur 0 → préféré |
! ─── Exemple : PE reçoit deux chemins vers 10.10.10.0/24 ────────────────
!
! Chemin A — via RR1 (1 saut) :
! Originator: 10.0.1.1 Cluster list: 1.1.1.1
! longueur = 1
!
! Chemin B — via RR2 → RR3 (2 sauts) :
! Originator: 10.0.1.1 Cluster list: 3.3.3.3, 2.2.2.2
! longueur = 2
!
! Critères #1 à #10 : identiques
! Critère #11 (ORIGINATOR_ID) : 10.0.1.1 = 10.0.1.1 → ÉGALITÉ
! Critère #12 (CLUSTER_LIST) : longueur 1 < longueur 2 → Chemin A GAGNE
La Confederation (RFC 5065) est l'autre solution au problème full-mesh. Elle divise un AS en plusieurs sous-AS internes. À l'intérieur de chaque sous-AS, une full-mesh réduite est maintenue. Entre sous-AS, un mécanisme pseudo-eBGP est utilisé.
| Critère | Route Reflector | Confederation |
|---|---|---|
| Complexité config | Faible | Élevée |
| Transparence AS-PATH | AS-PATH inchangé | CONFED_SEQ/SET visibles en interne |
| Policies différentes par zone | Difficile | Naturel (sous-AS distincts) |
| Visibilité opérationnelle | Simple | Plus complexe à déboguer |
| Usage en production | Dominant | Rare (opérateurs historiques) |
! ── Confederation — configuration de base ─────────────────────────────── ! AS public = 65000 (visible depuis l'extérieur) ! Sous-AS internes = 65001 et 65002 ! ── Routeur dans le sous-AS 65001 ── router bgp 65001 bgp confederation identifier 65000 ! AS public bgp confederation peers 65002 ! autres sous-AS ! Sessions vers sous-AS 65002 : eBGP-like (CONFED eBGP) neighbor 10.1.2.1 remote-as 65002 ! Sessions intra sous-AS 65001 : iBGP normal (full-mesh réduite) neighbor 10.1.1.2 remote-as 65001
! ── Vérifier qu'un neighbor est bien configuré comme client RR ────────── show ip bgp neighbors 10.0.1.1 ! → "Route-Reflector Client" ← confirme le rôle ! → "Member of cluster-id: 1.1.1.1" ! ── Voir le Cluster-ID local ──────────────────────────────────────────── show ip bgp summary show running-config | include cluster-id ! ── Vérifier ORIGINATOR_ID et CLUSTER_LIST sur une route ──────────────── show ip bgp 192.168.10.0/24 ! Originator: 10.0.1.1, Cluster list: 2.2.2.2, 1.1.1.1 ! ───────────────────────────────────────────── ! ORIGINATOR_ID (critère #11) CLUSTER_LIST (critère #12) ! longueur = 2 → 2 sauts RR ! ── Toutes les routes avec CLUSTER_LIST (= passées par un RR) ─────────── show ip bgp | include Cluster ! ── Comparer deux chemins vers un préfixe ─────────────────────────────── show ip bgp 10.10.10.0/24 ! Paths: (2 available, best #1) ! ! Path 1 (best) : ! 10.0.1.1 from 1.1.1.1 (1.1.1.1) ! Originator: 10.0.1.1, Cluster list: 1.1.1.1 ← longueur 1 ! ! Path 2 : ! 10.0.3.1 from 3.3.3.3 (3.3.3.3) ! Originator: 10.0.1.1, Cluster list: 3.3.3.3, 2.2.2.2 ← longueur 2 ! ── Vérifier si le RR réfléchit bien une route ────────────────────────── show ip bgp 192.168.10.0/24 ! "Advertised to update-groups:" ← présent = le RR annonce bien la route ! Si absent → route non réfléchie = vérifier la config RR ou l'anti-boucle ! ── Debug (production avec précaution) ────────────────────────────────── debug ip bgp 10.0.1.1 updates ! updates envoyés/reçus vers ce peer
| Piège | Symptôme | Fix |
|---|---|---|
| RRs redondants avec Cluster-IDs différents | CLUSTER_LIST grossit de 2 entrées par passage (au lieu de 1) → critère #12 défavorisé | bgp cluster-id identique sur les deux RRs |
| Route non réfléchie entre non-clients | Deux RRs ne s'échangent pas les routes de leurs clients respectifs | Session iBGP directe (non-client ↔ non-client) entre les RRs |
| next-hop non résolu chez le client | Route présente dans la table BGP mais pas installée dans la RIB | neighbor X.X.X.X next-hop-self sur le RR, ou IGP qui connaît le next-hop eBGP |
| Critère #11/#12 ignoré | En full-mesh iBGP sans RR, ces critères ne s'appliquent jamais | Normal — ORIGINATOR_ID et CLUSTER_LIST inexistants sans RR |
| CLUSTER_LIST visible côté eBGP | Attribut absent dans show ip bgp sur un peer eBGP |
Normal — Non-Transitive, stripped avant envoi eBGP |