Résumé

  • BGP traite normalement la présence de l'ASN local dans AS_PATH comme une preuve de boucle. allowas-in modifie le verdict du récepteur ; as-override modifie le chemin avant ce verdict.
  • Les deux mécanismes peuvent servir des sites partageant un ASN, sans authentifier un préfixe ni prouver le transfert. Route Target et Site of Origin remplissent des fonctions distinctes.
  • Une exception défendable conserve le chemin avant et après mutation, fixe voisin, famille d'adresses et nombre d'occurrences, vérifie les contrôles de site et de préfixe, puis suit la route jusqu'au FIB et aux paquets.

Un rejet qui fonctionne comme prévu

Prenons un cas illustratif, pas un incident déclaré. Les agences A et B utilisent le même ASN client derrière un réseau d'opérateur. A annonce un préfixe. L'opérateur le transporte jusqu'à B, où le routeur client retrouve son propre ASN dans AS_PATH et rejette la route. La session est établie, le PE connaît le préfixe, mais B ne peut pas l'utiliser.

Ce rejet n'est pas une panne inexplicable. RFC 4271 demande qu'une route contenant l'ASN local soit exclue du processus de décision et place explicitement l'acceptation de son propre ASN hors de sa spécification. Le chemin avertit que l'information a déjà traversé ce domaine de routage. RFC 4271

Deux réponses apparaissent. Le client peut tolérer un nombre limité d'occurrences de son ASN à la réception : allowas-in ou allow-own-as. L'opérateur peut aussi remplacer les occurrences de l'ASN client avant l'annonce vers ce client : as-override.

Ces commandes ne sont pas deux orthographes d'une même solution. La première conserve le chemin et change la règle d'acceptation. La seconde change la preuve pour que la règle par défaut ne se déclenche plus. L'une déplace l'autorité vers le récepteur ; l'autre confie à l'émetteur la garde de l'historique.

AS_PATH n'est pas un acte notarié

AS_PATH aide à détecter les boucles et à sélectionner les routes, mais ne signe pas le trajet physique. RFC 4272 rappelle qu'un speaker vérifie surtout son propre ASN, pas chaque transition affirmée, et qu'un chemin faux ou raccourci peut influencer la sélection ou les boucles. Cette preuve demeure utile justement parce qu'elle est interprétée localement et peut être altérée. RFC 4272

Avec allowas-in, le récepteur accepte ce qu'il aurait rejeté. Les implémentations peuvent limiter le nombre d'occurrences, le voisin, l'AFI/SAFI, l'origine ou une route-map. FRRouting documente plusieurs de ces portées. RFC 7938 décrit la fonction, répandue mais non standardisée, dans une architecture de centre de données réutilisant des ASN privés. Cette justification dépend de cette topologie ; elle ne fournit aucun nombre universellement sûr. Documentation BGP de FRRouting, RFC 7938

Avec as-override, l'émetteur remplace avant livraison. FRRouting et Junos documentent le remplacement des occurrences égales à l'ASN du pair par l'ASN local de l'opérateur. Junos précise que les répétitions produites par le prepend du client sont elles aussi remplacées. La longueur peut sembler conservée alors que l'identité expliquant ces positions a disparu. Documentation BGP de FRRouting, Junos as-override

Une capture postérieure au changement ne suffit donc pas. Il faut archiver l'annonce originale du CE, la réception du PE, l'export prévu avant mutation, l'export réel et la vue acceptée par le CE distant. Sans cette chaîne, la réécriture autorisée et une disparition inattendue de l'historique deviennent indiscernables.

Appartenance, origine de site et autorisation

Dans RFC 4364, Route Target détermine l'éligibilité d'une route VPN à l'import. Site of Origin identifie le site d'apprentissage et sert à empêcher le retour de cette route vers un CE de ce site. L'autorisation de préfixe répond encore à une autre question : cette attache avait-elle le droit d'annoncer ce réseau ? RFC 4364

Un RT ne remplace pas la preuve self-AS supprimée. Il peut distribuer très correctement une route qui circule à tous les membres prévus. SoO vise davantage la boucle de site, mais seulement si les attaches pertinentes l'ajoutent et l'appliquent sans échappatoire. Il n'authentifie ni le client ni le préfixe.

La documentation IOS XR de Cisco avertit, dans le scénario L3VPN décrit, que l'override fait perdre de l'information et peut créer une boucle ; elle utilise SoO comme contrôle compensatoire. Cette conclusion appartient à ce montage précis, pas à toutes les topologies. Documentation BGP IOS XR

RFC 9835 sépare également as-override, allow-own-as, le maximum d'occurrences et Site of Origin dans son modèle YANG de circuit d'accès. Un modèle ne garantit pas un comportement identique sur tous les équipements, mais interdit intellectuellement de réduire ces décisions à une seule case. RFC 9835

Suivre la route jusqu'au paquet

Commencer par l'état strict. Conserver Adj-RIB-Out du site A, Adj-RIB-In du PE, le chemin au PE distant avant export, puis la vue rejetée et son motif self-AS au site B. En environnement VPN, relever RD et RT sans les présenter comme une preuve d'origine.

Pour l'exception côté réception, lire la politique effective après héritage du groupe : voisin exact, AFI/SAFI, plafond d'occurrences, option limitée à l'origine et conditions de route-map. Une route témoin hors du périmètre doit rester rejetée. La portée réelle est celle que l'équipement compile, pas celle que suggère une ligne isolée.

Pour la réécriture côté émission, comparer chaque élément de l'AS_SEQUENCE avant et après export. Si le client a préfixé plusieurs fois son ASN, toutes les occurrences correspondantes peuvent changer. La preuve originale doit vivre hors du routeur mutable, car l'annonce réécrite ne peut pas la reconstituer.

Vérifier ensuite séparément l'autorisation du préfixe, les RT, l'application du SoO et les chemins parallèles susceptibles de contourner le contrôle. RFC 6368 décrit les inconvénients du remappage et de l'acceptation de son propre ASN lorsque le client emploie BGP pour d'autres fonctions internes : l'effet ne s'arrête pas nécessairement à la session PE–CE. RFC 6368

Enfin, une route acceptée n'est pas un paquet livré. Contrôler le choix dans le Loc-RIB, la récursion, l'entrée FIB ou matérielle et le trajet bidirectionnel. Un essai de panne prudent doit révéler une rentrée inattendue sans provoquer une circulation dangereuse. RFC 7705 montre, dans un contexte de migration ASN, que manipuler l'historique peut faire accepter une route que la règle self-AS aurait bloquée ; ce n'est pas la norme d'as-override, mais un avertissement utile. RFC 7705

Le retour arrière doit restaurer une propriété, pas seulement supprimer une commande. Le canari self-AS doit être de nouveau rejeté là où prévu, tandis que la connectivité autorisée, le FIB et les paquets reviennent à l'état conçu. Sinon, le dossier prouve une action de configuration, pas le retour de la sécurité.