→ Critère #11 atteint directement si bgp bestpath compare-routerid est configuré (critère #10 sauté).
Lowest Router-ID wins
Le chemin dont le peer annonçant a le Router-ID le plus bas est préféré. La comparaison est numérique (32 bits), pas lexicographique. Ex: 1.1.1.1 (0x01010101) < 2.2.2.2 (0x02020202).
ORIGINATOR_ID en contexte RR
Quand une route est réfléchie par un Route Reflector, l'attribut ORIGINATOR_ID (type 9) contient le Router-ID de l'annonceur original. Pour le critère #11, c'est ORIGINATOR_ID qui est comparé, pas le Router-ID du RR ou du peer direct.
Déterministe par nature
Contrairement au critère #10 (Oldest eBGP), le Router-ID est stable — il ne change pas selon l'ordre d'arrivée des routes. C'est pourquoi bgp bestpath compare-routerid saute #10 pour arriver ici directement.
Ne s'applique pas toujours
Si les deux chemins viennent du même peer (même Router-ID ou ORIGINATOR_ID), le critère #11 est une égalité et on passe au critère #12 (longueur Cluster-list). En pratique, deux chemins du même peer sont très rares.
bgp router-id manuellement.
! Configuration manuelle du Router-ID (bonne pratique absolue) router bgp 65001 bgp router-id 1.1.1.1 ! Utiliser l'IP de la loopback principale ! Vérification R1# show ip bgp summary BGP router identifier 1.1.1.1, local AS number 65001 ... R1# show bgp ipv4 unicast summary | include router identifier BGP router identifier 1.1.1.1, local AS number 65001 ! Voir le Router-ID des peers R1# show ip bgp neighbors 10.0.0.2 | include router identifier BGP neighbor is 10.0.0.2, remote AS 65001, internal link BGP version 4, remote router ID 2.2.2.2
| Scénario | Router-ID R1 | Router-ID R2 | Résultat critère #11 |
|---|---|---|---|
| R1 loopback 1.1.1.1, R2 loopback 2.2.2.2 | 1.1.1.1 | 2.2.2.2 | R1 gagne (1.1.1.1 < 2.2.2.2) |
| R1 loopback 10.0.0.1, R2 loopback 10.0.0.2 | 10.0.0.1 | 10.0.0.2 | R1 gagne (10.0.0.1 < 10.0.0.2) |
| R1 loopback 192.168.1.1, R2 loopback 10.0.0.1 | 192.168.1.1 | 10.0.0.1 | R2 gagne (10.0.0.1 < 192.168.1.1) |
| Même Router-ID (mauvaise config) | 1.1.1.1 | 1.1.1.1 | Égalité → critère #12 |
10.0.0.1 = 0x0A000001 = 167772161, 192.168.1.1 = 0xC0A80101 = 3232235777. Donc 10.0.0.1 < 192.168.1.1 — la plage d'adresse n'a aucune importance.
| Situation | Valeur utilisée pour critère #11 |
|---|---|
| Route eBGP directe (pas de RR) | Router-ID du peer eBGP (champ "from" dans show ip bgp) |
| Route iBGP directe (pas de RR) | Router-ID du peer iBGP |
| Route réfléchie par RR (ORIGINATOR_ID présent) | ORIGINATOR_ID (type 9) — Router-ID de l'annonceur original |
| ORIGINATOR_ID = propre Router-ID du routeur | Route REJETÉE (mécanisme anti-boucle iBGP) |
| Deux routes avec même ORIGINATOR_ID | Égalité → critère #12 (Cluster-list length) |
PE3# show ip bgp 172.16.0.0/16 BGP routing table entry for 172.16.0.0/16, version 20 Paths: (2 available, best #1) Advertised to update-groups: 1 65100 10.1.1.1 from 10.0.0.100 (10.0.0.100) ← from RR (10.0.0.100) Origin IGP, localpref 100, valid, internal, best Originator: 1.1.1.1, Cluster list: 10.0.0.100 ↑ ORIGINATOR_ID = 1.1.1.1 (Router-ID de PE1) → utilisé pour critère #11 65100 10.1.1.2 from 10.0.0.100 (10.0.0.100) ← from RR (même peer!) Origin IGP, localpref 100, valid, internal Originator: 2.2.2.2, Cluster list: 10.0.0.100 ↑ ORIGINATOR_ID = 2.2.2.2 (Router-ID de PE2) → critère #11 : 1.1.1.1 < 2.2.2.2 → PE1 gagne
R3# show ip bgp 172.16.0.0/16 BGP routing table entry for 172.16.0.0/16, version 22 Paths: (2 available, best #1, table Default-IP-Routing-Table) Advertised to update-groups: 1 65100 203.0.113.1 (metric 10) from 1.1.1.1 (1.1.1.1) ← Router-ID 1.1.1.1 Origin IGP, metric 0, localpref 100, valid, internal, best ↑ critère #11 : 1.1.1.1 < 2.2.2.2 → BEST ✅ 65100 203.0.113.2 (metric 10) from 2.2.2.2 (2.2.2.2) ← Router-ID 2.2.2.2 Origin IGP, metric 0, localpref 100, valid, internal ↑ critère #11 : 2.2.2.2 > 1.1.1.1 → perd ❌
show ip bgp, la syntaxe est : from <peer-IP> (<Router-ID>). Le champ entre parenthèses est le Router-ID du peer — c'est cette valeur qui est comparée au critère #11 (ou ORIGINATOR_ID si présent).
| Critère | Via R1 | Via R2 | Résultat |
|---|---|---|---|
| #1–#9 | Identiques sur tous les critères | Égal — suivant | |
| #10 Oldest eBGP | iBGP paths → critère #10 sauté | Sauté → #11 | |
| #11 Router-ID | 1.1.1.1 | 2.2.2.2 | ✅ R1 gagne (1.1.1.1 < 2.2.2.2) |
(défaut, sans compare-routerid)
(avec bgp bestpath compare-routerid)
! Sauter le critère #10 pour aller directement au critère #11 router bgp 65001 bgp bestpath compare-routerid ! IMPORTANT : configurer sur TOUS les routeurs BGP du même AS ! Un mix (certains avec, d'autres sans) crée des incohérences ! Vérification R1# show running-config | section router bgp router bgp 65001 bgp router-id 1.1.1.1 bgp bestpath compare-routerid ← confirme que #10 est sauté ... ! Si les Router-IDs sont bien configurés (manuellement, bas et stables) ! le critère #11 donnera toujours le même résultat sur tous les routeurs
! Configuration recommandée en production (dual border router) router bgp 65001 bgp router-id 1.1.1.1 ! Router-ID manuel stable et bas bgp bestpath compare-routerid ! Sauter #10, aller à #11 bgp log-neighbor-changes ! Tracer les changements de session neighbor 2.2.2.2 remote-as 65001 neighbor 2.2.2.2 update-source Loopback0 ! Sur R2 (border router #2) : router bgp 65001 bgp router-id 2.2.2.2 ! Router-ID différent de R1 ! bgp bestpath compare-routerid ! Même commande que R1
⚡ Changement de Router-ID = reset de toutes les sessions BGP
Si le Router-ID change (nouvelle loopback, interface up/down), IOS envoie une notification CEASE à tous les peers et réinitialise les sessions. Cela provoque une reconvergence BGP complète et une interruption de trafic. Toujours configurer bgp router-id manuellement pour éviter ce risque.
⚡ Router-ID dupliqué dans le même AS
Si deux routeurs du même AS ont le même Router-ID (ex: copier-coller de config), les sessions iBGP entre eux échouent avec une erreur OPEN message. Symptôme : show ip bgp neighbors montre Idle/Active en boucle. Vérifier avec show ip bgp summary → champ "BGP router identifier".
⚡ ORIGINATOR_ID ignoré si routeur ne comprend pas les RR
Un vieux routeur ne supportant pas les attributs Route Reflector (ORIGINATOR_ID type 9, CLUSTER_LIST type 10) peut les ignorer. Pour le critère #11, il utilisera alors le Router-ID du peer direct (le RR) au lieu de l'ORIGINATOR_ID — résultat différent de ce qu'on attend.
⚡ Confondre Router-ID BGP et Router-ID OSPF
BGP et OSPF ont chacun leur propre Router-ID, sélectionné indépendamment avec les mêmes règles (loopback, interface). Ils peuvent être différents. Le critère #11 de BGP utilise uniquement le Router-ID BGP, pas celui d'OSPF. Toujours vérifier avec show ip bgp summary, pas show ip ospf.
⚡ Anti-boucle RR : route rejetée si ORIGINATOR_ID = propre RID
Un client RR rejette silencieusement toute route réfléchie dont l'ORIGINATOR_ID correspond à son propre Router-ID — c'est le mécanisme anti-boucle iBGP. Si un routeur ne voit pas une route attendue dans un environnement RR, vérifier si ORIGINATOR_ID = propre RID avec show ip bgp X detail.
⚡ compare-routerid non appliqué uniformément
Si bgp bestpath compare-routerid est configuré sur R1 mais pas R2, R1 va au critère #11 directement tandis que R2 passe par le critère #10. Les deux routeurs peuvent sélectionner des best paths différents — exactement le problème qu'on cherchait à éviter.
✅ Bonne pratique — Router-ID bas = priorité de sélection
Utiliser des Router-IDs bas (ex: 1.1.1.1, 2.2.2.2) pour les border routers principaux garantit qu'ils seront préférés au critère #11. Cela permet de contrôler explicitement quel border router est préféré pour le trafic entrant, sans toucher aux critères 1–10.
✅ Bonne pratique — toujours bgp router-id manuel en production
Configurer bgp router-id X.X.X.X sur chaque routeur BGP, idéalement égal à l'IP de la loopback principale. Cela garantit que le Router-ID ne changera jamais automatiquement, évite les resets de sessions inattendus, et rend le critère #11 prévisible.
Cliquez sur une carte pour révéler la réponse.
bgp router-id X.X.X.X (manuel — priorité absolue) → ② Loopback avec la plus haute IP → ③ Interface physique active avec la plus haute IP. En production, toujours configurer manuellement pour éviter les resets de sessions.
bgp router-id doit toujours être configuré manuellement.
show ip bgp X.X.X.X/Y, chaque chemin affiche : from <peer-IP> (<Router-ID>). La valeur entre parenthèses est le Router-ID du peer — c'est elle qui est comparée au critère #11. Si ORIGINATOR_ID est présent, la ligne Originator: X.X.X.X indique la valeur utilisée.
compare-routerid, on saute #10 et on va directement au critère #11 (Router-ID), qui est stable et identique sur tous les routeurs ayant la même vue BGP.
show ip bgp summary, le peer reste en état Idle ou Active. Corriger avec bgp router-id unique sur chaque routeur.