BGP Locally Originated

CCIE / ENARSI PAS un attribut BGP Best Path Critère #3

⚠ Règle de sélection — pas un attribut BGP

Contrairement à Weight!! (Weight, n est pas un Attribut), LOCAL_PREF ou Origin, le critère "Locally Originated" n'est pas un attribut BGP. Il n'a ni type code, ni RFC dédiée, ni champ transporté dans les messages UPDATE.

BGP l'identifie uniquement par le fait que le NEXT_HOP = 0.0.0.0 dans la table BGP locale. C'est une règle interne au processus de sélection : le routeur préfère toujours une route qu'il a lui-même injectée dans BGP sur une route reçue d'un voisin, à condition que Weight (#1) et LOCAL_PREF (#2) soient identiques.

Profil du critère

Type Code BGPAucun — pas un attribut
CatégorieRègle de sélection interne
Critère Best Path#3
Identifiable parNEXT_HOP = 0.0.0.0
Propagation❌ Non propagé
Configurable❌ Automatique
Valeur winsRoute locale > reçue
Règle de sélection Pas de type code NEXT_HOP = 0.0.0.0 Critère #3

Comparaison : attribut BGP vs règle de sélection

CaractéristiqueAttribut BGP (ex: Origin)Locally Originated (#3)
Type codeOui (ex: type 1)Aucun
Transporté dans UPDATEOuiNon
Visible dans show ip bgpDans la colonne PathNEXT_HOP = 0.0.0.0
Modifiable par route-mapOui (set origin, etc.)Non
RFC dédiéeRFC 4271 + spécifiquesComportement implicite
Propagé aux voisinsOui (selon règles)Non — NH remplacé

Position dans le Best Path Algorithm

1 Weight
2 LOCAL_PREF
3 ★ Locally Originated
4 AS-PATH
5 Origin
6 MED
7 eBGP/iBGP
8 IGP metric
9 AIGP
10 Oldest
11 Router-ID
12 Cluster-list
13 Neighbor IP

Le critère #3 ne s'applique que si Weight (#1) et LOCAL_PREF (#2) sont strictement égaux entre la route locale et la route reçue. En pratique, Weight=32768 sur la route locale (default) gagne déjà au critère #1 — #3 joue uniquement si Weight a été explicitement mis à 0 sur la route locale.

Les 3 méthodes d'injection — impact sur Origin

MéthodeCommandeOrigin résultantNEXT_HOP dans BGPCondition
network network 10.0.0.0 mask 255.0.0.0 i (IGP) 0.0.0.0 Préfixe exact doit exister dans la RIB
aggregate-address aggregate-address 10.0.0.0 255.0.0.0 i (IGP) 0.0.0.0 Au moins une composante dans la table BGP
redistribute redistribute ospf 1 ? (incomplete) 0.0.0.0 Toujours — même avec set origin igp en route-map

⚠ redistribute positionne toujours Origin=? (incomplete). Utiliser set origin igp dans une route-map pour forcer Origin=i si nécessaire.

Les 3 commandes qui rendent une route "locally originated" dans BGP. Dans tous les cas, le NEXT_HOP sera 0.0.0.0 dans la table BGP locale.

① network
network <prefix> mask <mask>
Origini (IGP)
NEXT_HOP0.0.0.0
ConditionPréfixe exact dans RIB
PropagationOui, vers tous voisins
② aggregate-address
aggregate-address <prefix> <mask>
Origini (IGP)
NEXT_HOP0.0.0.0
ConditionComposante présente dans BGP
summary-onlySupprime les composantes
③ redistribute
redistribute <protocol> <instance>
Origin? (incomplete)
NEXT_HOP0.0.0.0
ConditionRoute présente dans RIB
Correctif Originset origin igp en route-map

Config complète — méthode network

! Condition : 10.0.0.0/8 doit exister dans la RIB (statique ou IGP)
ip route 10.0.0.0 255.0.0.0 Null0          ! route statique Null0 pour garantir la présence dans RIB

router bgp 65001
 network 10.0.0.0 mask 255.0.0.0          ! préfixe exact requis

! Résultat dans show ip bgp :
! *> 10.0.0.0/8   0.0.0.0   0   32768 i    ← NH=0.0.0.0, locally originated

Config complète — aggregate-address

router bgp 65001
 network 10.1.0.0 mask 255.255.0.0        ! composante dans BGP
 network 10.2.0.0 mask 255.255.0.0        ! composante dans BGP
 aggregate-address 10.0.0.0 255.0.0.0 summary-only
!
! summary-only : supprime 10.1/16 et 10.2/16 de l'annonce
! sans summary-only : agrégat ET composantes sont annoncés
!
! Résultat :
! *> 10.0.0.0/8   0.0.0.0   0   32768 i    ← NH=0.0.0.0, Atomic Aggregate positionné

Config complète — redistribute (+ correctif Origin)

route-map REDIS-BGP permit 10
 set origin igp                             ! force Origin=i au lieu de ?
!
router bgp 65001
 redistribute ospf 1 route-map REDIS-BGP
!
! Sans route-map :
! *> 192.168.1.0   0.0.0.0   0   32768 ?    ← Origin=? (incomplete)
! Avec route-map + set origin igp :
! *> 192.168.1.0   0.0.0.0   0   32768 i    ← Origin=i

Le seul moyen d'identifier une route "locally originated" dans show ip bgp est le NEXT_HOP = 0.0.0.0. Il n'y a pas de flag dédié ni de colonne spécifique.

show ip bgp — lecture de la table

R1# show ip bgp
BGP table version is 7, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i internal
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop         Metric  LocPrf  Weight  Path
*> 10.0.0.0/8       0.0.0.0               0           32768  i    ← network, locally originated
*> 172.16.0.0/12    0.0.0.0               0           32768  i    ← aggregate-address, locally originated
*> 192.168.10.0/24  0.0.0.0               0           32768  ?    ← redistribute, locally originated
   10.0.0.0/8       10.0.0.1            100       100      0  65001 i   ← reçue d'un voisin eBGP
   192.168.10.0/24  10.0.0.1            100       100      0  65001 i   ← reçue d'un voisin eBGP

*> = route valide et sélectionnée comme best path. NEXT_HOP = 0.0.0.0 = indicateur d'une route locally originated. Les routes reçues des voisins ont le NEXT_HOP de l'interface du peer.

Comparaison : route locale vs route reçue — même préfixe

StatusNetworkNext HopMetricLocPrfWeightPathCritère gagnant
*> 10.0.0.0/8 0.0.0.0 0 — 32768 i #1 Weight 32768
* 10.0.0.0/8 10.0.0.1 100 100 0 65001 i —

Ici c'est Weight (#1) qui gagne (32768 vs 0). Le critère #3 "Locally Originated" ne s'applique que si Weight et LOCAL_PREF sont identiques (voir onglet Best Path).

show ip bgp — route locally originated détaillée

R1# show ip bgp 10.0.0.0/8
BGP routing table entry for 10.0.0.0/8, version 3
Paths: (2 available, best #1, table default)
  Local, (Received from a RR-client)
    0.0.0.0 from 0.0.0.0 (1.1.1.1)          ← NEXT_HOP 0.0.0.0 = locally originated
      Origin IGP, metric 0, weight 32768, valid, sourced, local, best
      Last update: 00:05:12 ago
  65001
    10.0.0.1 from 10.0.0.1 (192.168.1.1)
      Origin IGP, metric 100, localpref 100, valid, external
      Last update: 00:12:44 ago

Le critère #3 est rare dans la vraie vie — il ne joue que si Weight et LOCAL_PREF sont strictement égaux entre la route locale et la route reçue. Voici les scénarios concrets.

⚠ Quand le critère #3 ne joue PAS (cas le plus fréquent)

! Scénario : route locale VS route reçue d'un peer eBGP
! Route locale via network :
  Weight = 32768   (valeur par défaut Cisco pour routes locales)

! Route reçue d'un voisin eBGP :
  Weight = 0        (valeur par défaut pour routes reçues)

! → Critère #1 Weight tranche : 32768 > 0
! → Critère #3 n'est jamais atteint

✓ Quand le critère #3 joue — scénario exact

! Conditions requises pour que #3 tranche :
! - Weight identique sur les deux routes (ex: les deux à 0)
! - LOCAL_PREF identique (ex: les deux à 100)
!
router bgp 65001
 neighbor 10.0.0.1 weight 0             ! force Weight=0 pour la route reçue ET locale
 network 10.0.0.0 mask 255.0.0.0
!
! Résultat best path :
!  #1 Weight       : 0 = 0  → TIE
!  #2 LOCAL_PREF   : 100 = 100 → TIE
!  #3 Locally Orig : route locale NH=0.0.0.0 → GAGNE ★

Décision pas à pas — les 3 premiers critères

CritèreRoute locale (network)Route reçue peerRésultat
#1 Weight 0 (forcé) 0 (default) TIE → suivant
#2 LOCAL_PREF 100 (default) 100 (default) TIE → suivant
#3 Locally Originated NH = 0.0.0.0 ✓ NH = 10.0.0.1 ✗ ROUTE LOCALE GAGNE ★

Cas CCIE — iBGP peer redistribue aussi la même route

! Topologie : R1 et R2 dans AS65001 (iBGP full-mesh)
! R1 : network 10.0.0.0/8 → locally originated
! R2 : reçoit 10.0.0.0/8 via iBGP de R1, et aussi via eBGP de ISP
!
! Sur R2 :
!  Route de R1 (iBGP) : Weight=0, LP=100, NH=1.1.1.1 (R1)
!  Route ISP (eBGP)   : Weight=0, LP=100, NH=10.0.0.1
!
! → Critère #7 eBGP > iBGP tranche sur R2 (pas #3)
! → #3 ne s'applique que sur le routeur qui a injecté la route

Quand une route "locally originated" est annoncée aux voisins BGP, le NEXT_HOP 0.0.0.0 n'est jamais propagé tel quel — BGP le remplace automatiquement par l'adresse IP de l'interface source de la session.

Ce qui est annoncé aux voisins

! Sur R1 (AS65001) — table BGP locale :
*> 10.0.0.0/8   0.0.0.0   0   32768 i   ← NH=0.0.0.0 visible en local

! Ce que R2 (voisin iBGP) reçoit :
*>i 10.0.0.0/8  1.1.1.1   0   100   0 i ← NH remplacé par l'IP de R1 (update-source loopback)

! Ce que R3 (voisin eBGP) reçoit :
*> 10.0.0.0/8   203.0.113.1  0  0 65001 i ← NH = IP interface eBGP de R1

Règles de propagation du NEXT_HOP

Type de sessionNH local (show ip bgp)NH annoncé au voisinCommande
Vers voisin eBGP 0.0.0.0 IP interface eBGP Automatique
Vers voisin iBGP 0.0.0.0 IP source de la session Automatique
iBGP avec next-hop-self 0.0.0.0 IP locale (forcée) neighbor X next-hop-self

next-hop-self — interaction avec les routes localement originées

! next-hop-self force le NH pour toutes les routes annoncées aux iBGP peers
! y compris les routes locally originated (même si NH était déjà 0.0.0.0)
!
router bgp 65001
 neighbor 2.2.2.2 remote-as 65001
 neighbor 2.2.2.2 next-hop-self         ! NH annoncé = loopback/IP locale
 network 10.0.0.0 mask 255.0.0.0
!
! Sur R2 (peer iBGP) :
! *>i 10.0.0.0/8   1.1.1.1 ← NH = loopback de R1, pas 0.0.0.0

⚠ next-hop-self ne rend pas la route "locally originated" sur R2 — R2 la reçoit toujours comme une route iBGP avec un vrai NEXT_HOP (1.1.1.1). Seul R1 la voit avec NH=0.0.0.0.

⚡ Piège #1 — network sans correspondance exacte dans la RIB

La commande network 10.0.0.0 mask 255.0.0.0 n'injecte la route dans BGP que si 10.0.0.0/8 existe exactement dans la RIB. Un résumé plus spécifique (10.1.0.0/16) ne suffit pas. Solution : ajouter une route statique vers Null0.

ip route 10.0.0.0 255.0.0.0 Null0   ! garantit la présence dans la RIB
router bgp 65001
 network 10.0.0.0 mask 255.0.0.0

⚡ Piège #2 — redistribute génère toujours Origin=?

redistribute positionne Origin=? (incomplete) même avec une route-map set origin igp dans certaines versions IOS. Toujours vérifier avec show ip bgp que Origin=i est bien positionné. Préférer network quand c'est possible.

⚡ Piège #3 — confondre "locally originated" avec next-hop-self

next-hop-self modifie le NEXT_HOP annoncé aux voisins iBGP, mais ne rend pas la route "locally originated" sur ces voisins. Le voisin reçoit la route avec un vrai IP comme NEXT_HOP — NH=0.0.0.0 n'est visible que sur le routeur qui a injecté la route via network, aggregate ou redistribute.

⚡ Piège #4 — aggregate-address sans summary-only annonce les composantes

Sans summary-only, aggregate-address 10.0.0.0/8 crée l'agrégat ET continue d'annoncer 10.1.0.0/16, 10.2.0.0/16, etc. Utiliser summary-only pour supprimer les composantes. Attention au suppress-map pour une suppression sélective.

aggregate-address 10.0.0.0 255.0.0.0              ! agrégat + composantes annoncées
aggregate-address 10.0.0.0 255.0.0.0 summary-only  ! agrégat uniquement

⚡ Piège #5 — critère #3 masqué par Weight default

Dans la quasi-totalité des déploiements, le critère #3 n'est jamais atteint car le Weight par défaut de 32768 sur les routes locales gagne déjà au critère #1. À l'exam CCIE, si une question porte sur "Locally Originated", vérifier que Weight et LOCAL_PREF sont explicitement égaux sur les routes comparées, sinon c'est #1 ou #2 qui tranche.

✓ Bonne pratique — vérification dans show ip bgp

Pour confirmer qu'une route est locally originated : show ip bgp <prefix> et vérifier NEXT_HOP = 0.0.0.0 et weight 32768 (ou la valeur configurée), ainsi que le mot clé "local" dans la sortie détaillée.

R1# show ip bgp 10.0.0.0/8
    0.0.0.0 from 0.0.0.0 (1.1.1.1)
      Origin IGP, weight 32768, valid, sourced, local, best

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

Comment identifier une route "locally originated" dans show ip bgp ?
NEXT_HOP = 0.0.0.0 — c'est le seul indicateur visible dans la table BGP.
Cliquer pour révéler
Quel est le type code BGP de "Locally Originated" ?
Aucun. Ce n'est pas un attribut BGP — c'est une règle de sélection interne sans type code ni RFC dédiée.
Cliquer pour révéler
Quelle méthode d'injection produit toujours Origin=? ?
redistribute — toujours Origin=? (incomplete). Utiliser set origin igp dans une route-map pour corriger.
Cliquer pour révéler
Dans quel cas le critère #3 tranche-t-il réellement ?
Uniquement si Weight (#1) ET LOCAL_PREF (#2) sont strictement identiques entre la route locale et la route reçue. En pratique, Weight=32768 (default) gagne déjà au critère #1.
Cliquer pour révéler
NEXT_HOP=0.0.0.0 est-il propagé aux voisins BGP ?
Non. BGP remplace automatiquement 0.0.0.0 par l'IP de l'interface source de la session avant d'annoncer la route au voisin.
Cliquer pour révéler
Quelle commande garantit qu'un préfixe network soit injecté même sans IGP ?
ip route 10.0.0.0 255.0.0.0 Null0 — route statique vers Null0 pour assurer la présence du préfixe exact dans la RIB.
Cliquer pour révéler
Quelle est la différence entre aggregate-address avec et sans summary-only ?
Sans summary-only : agrégat + composantes annoncés. Avec summary-only : seul l'agrégat est annoncé, les composantes sont supprimées (s dans show ip bgp).
Cliquer pour révéler
Quel mot-clé apparaît dans show ip bgp <prefix> pour une route locally originated ?
Le mot "local" dans la ligne de description : valid, sourced, local, best.
Cliquer pour révéler