BGP Origin

CCIE / ENARSI Best Path Critère #5

BGP Origin — Définition

L'Origin indique comment une route est entrée dans BGP. C'est le seul attribut qui répond à la question : "cette route vient-elle d'un réseau annoncé proprement, d'une redistribution, ou d'un vieux protocole ?"

Attribute NameORIGIN
Type Code1
CategoryWell-known Mandatory
Présent dansChaque BGP UPDATE
Position Best PathCritère #5
Préférencei > e > ?

✅ Well-known Mandatory — ce que ça signifie

Well-known = tous les routeurs BGP doivent reconnaître cet attribut.

Mandatory = doit être présent dans chaque BGP UPDATE sans exception. Contrairement à LOCAL_PREF (Discretionary) qui peut être absent.

Obligatoire dans chaque UPDATE Type Code 1 — premier attribut RFC 4271 Propagé avec la route

🎯 Les 3 valeurs possibles

i
IGP
Route introduite via la commande network dans BGP. BGP connaît l'origine exacte.
PRÉFÉRÉ — Best Path
e
EGP
Route provenant de l'ancien protocole EGP (RFC 904). Quasi-inexistant aujourd'hui — historique uniquement.
NEUTRE — désuet
?
INCOMPLETE
Route issue d'une redistribution ou d'une agrégation ambiguë. BGP ne peut pas certifier l'origine.
MOINS PRÉFÉRÉ

📌 Ordre de préférence Best Path (critère #5)

À égalité sur Weight, LOCAL_PREF, Locally Originated et AS-PATH length, BGP compare l'Origin :

i
MEILLEUR
›
e
INTERMÉDIAIRE
›
?
MOINS BON

Une route network (i) battra toujours une route redistribuée (?) à égalité sur les critères 1→4.

Comment l'Origin naît — Méthodes d'injection

L'Origin est assigné automatiquement selon la méthode utilisée pour injecter la route dans BGP. Il n'est jamais calculé — il est déterminé par la commande.

network → i BGP sait exactement que c'est un réseau local annoncé
aggregate-address → i Par défaut — sauf si as-set avec composants ?
redistribute → ? TOUJOURS incomplete — sans exception
Learned via BGP → conservé L'origin de la route source est propagé tel quel

🔍 Exemples concrets

! network → Origin i
router bgp 65000
 network 10.0.0.0 mask 255.0.0.0
! → show ip bgp : Path = 65000 i

! redistribute → Origin ?
router bgp 65000
 redistribute ospf 1
! → show ip bgp : Path = 65000 ?   (toujours !)

! même si OSPF a appris la route via "network" dans OSPF
! BGP ne peut pas remonter à l'origine IGP → forced ?

⚠️ Redistribute donne TOUJOURS ?

Peu importe la source : OSPF, EIGRP, static, connected — redistribute donne systématiquement ?. BGP ne peut pas certifier qu'une route redistribuée a une origine IGP propre. C'est intentionnel dans la RFC.

Si tu veux forcer l'origine à i sur des routes redistribuées → utilise une route-map avec set origin igp.

Modifier l'Origin avec route-map

L'Origin peut être modifié via set origin dans une route-map. Utile pour normaliser les routes redistribuées ou forcer une politique.

! Forcer Origin i sur des routes redistribuées
route-map FIX-ORIGIN permit 10
 set origin igp
!
router bgp 65000
 redistribute ospf 1 route-map FIX-ORIGIN
! → routes OSPF redistribuées avec Origin i au lieu de ?
! Valeurs possibles pour set origin
route-map SET-ORIGIN permit 10
 set origin igp        ! → i (meilleur)
 set origin egp        ! → e (historique)
 set origin incomplete ! → ? (moins préféré)

📋 Filtrage basé sur l'Origin

Possible mais rare en production. Peut être utile pour rejeter des routes redistribuées (?) d'un voisin ou forcer une politique de qualité de route.

! Accepter uniquement les routes avec Origin i
route-map FILTER-ORIGIN permit 10
 match origin igp
!
router bgp 65000
 neighbor 1.1.1.1 route-map FILTER-ORIGIN in
! Routes avec Origin ? ou e → rejetées
Rare en production match origin igp / egp / incomplete

Table BGP — Origin visible dans la colonne PATH

L'Origin n'a pas de colonne dédiée dans show ip bgp. Il apparaît comme le dernier caractère de la colonne PATH : i, e, ou ?.

R1# show ip bgp — Trois routes avec origins différents
StatusNetworkNext HopMetricLocPrfWeightPath
*>10.0.0.0/81.1.1.101000 100 200 i
*>172.16.0.0/162.2.2.201000 300 e
*192.168.0.0/243.3.3.301000 400 ?
i → Annoncé via network
e → Ancien protocole EGP
? → Redistribué depuis IGP

🔍 show ip bgp — Détail d'une route

R1# show ip bgp 10.0.0.0

BGP routing table entry for 10.0.0.0/8
  Path: (1 available, best #1)
    1.1.1.1 from 1.1.1.1
    Origin IGP, metric 0, localpref 100, valid, external, best
    AS_PATH: 100 200

R1# show ip bgp 192.168.0.0

BGP routing table entry for 192.168.0.0/24
  Path: (1 available, best #1)
    3.3.3.3 from 3.3.3.3
    Origin incomplete, metric 0, localpref 100, valid, external, best
    AS_PATH: 400

Origin et Aggregation — Cas important

Le comportement de l'Origin lors d'une agrégation dépend de l'option as-set. C'est un piège classique CCIE.

✅ aggregate-address sans as-set → Origin i

router bgp 65000
 aggregate-address 10.10.0.0 255.255.0.0
 ! → Origin forcé à i
 ! peu importe l'origin des routes composantes

BGP crée un nouveau préfixe agrégé avec Origin i par défaut. Les routes composantes (même redistribuées avec ?) sont "nettoyées".

Origin → i (forcé) AS_PATH vide (atomic aggregate)

⚠️ aggregate-address as-set → Origin hérité (?)

router bgp 65000
 aggregate-address 10.10.0.0 255.255.0.0 as-set
 ! → Origin hérité du "pire" composant
 ! Si 1 route composante est ?, l'agrégat devient ?

Le as-set inclut les AS-PATH des routes composantes pour éviter les boucles. En contrepartie, si au moins une route composante a Origin ? (redistribuée), l'agrégat hérite du ?.

Origin → ? si composant redistributed AS_PATH = union des AS composants

📊 Tableau récapitulatif Aggregation

CommandeOrigin résultantAS_PATHRemarque
aggregate-address i (forcé) Vide (atomic) Toujours i, indépendant des composants
aggregate-address as-set ? si composant ? Union des AS composants Hérite du pire origin des composants
aggregate-address as-set (tous i) i Union des AS composants Si tous les composants sont i → agrégat i

⚠️ PIÈGE #1 — redistribute donne TOUJOURS ?

Sans exception. OSPF, EIGRP, static, connected, RIP — toujours ?. Même si OSPF a appris la route via network, BGP ne peut pas remonter à l'origine. Pour forcer i : route-map set origin igp appliquée à la redistribution.

⚠️ PIÈGE #2 — Origin n'a pas de colonne dans show ip bgp

L'Origin est le dernier caractère de la colonne PATH. Les candidats cherchent souvent une colonne "ORIGIN" — elle n'existe pas. 100 200 i → i est l'origin, 100 200 est l'AS-PATH.

⚠️ PIÈGE #3 — aggregate-address as-set hérite du pire origin

Si une seule route composante de l'agrégat est redistribuée (?), l'agrégat avec as-set prend Origin ?. Sans as-set, l'agrégat est toujours i.

⚠️ PIÈGE #4 — Well-known Mandatory ≠ Always Present

"Mandatory" signifie présent dans chaque UPDATE, mais BGP peut avoir des bugs d'implémentation. En théorie : toujours présent. Si absent → session BGP NOTIFICATION error.

✅ RAPPEL — Ordre Best Path complet autour du critère #5

Weight (#1) → LOCAL_PREF (#2) → Locally originated (#3) → AS-PATH length (#4) → Origin i > e > ? (#5) → MED (#6) → eBGP > iBGP (#7) → IGP metric (#8) → AIGP (#9) → …

🔍 Commandes de vérification

show ip bgp                    ! Origin en fin de colonne PATH
show ip bgp 10.0.0.0          ! "Origin IGP/incomplete" dans le détail
show ip bgp regexp _65000_     ! filtrer par AS
show route-map FIX-ORIGIN      ! vérifier set origin
1
Type Code IANA
Premier attribut défini — RFC 4271
#5
Position Best Path
Critère #5 — après AS-PATH length, avant MED
i
IGP — meilleur
network · aggregate-address (sans as-set)
e
EGP — historique
Ancien protocole EGP — quasi inexistant aujourd'hui
?
Incomplete — moins bon
redistribute — TOUJOURS ? sans exception
MAN
Well-known Mandatory
Présent dans CHAQUE BGP UPDATE — obligatoire
PATH
Colonne dans show
Dernier caractère de la colonne PATH — pas de colonne dédiée
AS-SET
Aggregation + as-set
Hérite du pire origin des composants → ? si redistribué

🎓 Résumé Exam en 5 points

  1. Origin = Well-known Mandatory · type code 1 · présent dans chaque UPDATE
  2. Critère #5 Best Path : i > e > ?
  3. network → i · redistribute → ? (toujours)
  4. Visible en dernier caractère de PATH dans show ip bgp
  5. aggregate as-set → hérite du pire origin des composants