Résumé

  • treat-as-withdraw ne corrige pas l’information reçue : il sacrifie toutes les routes du même UPDATE afin de préserver le reste de la session.
  • Un voisin BGP en état Established n’est plus une preuve suffisante de santé ; il faut relier le PDU fautif aux RIB, à la FIB et aux paquets.

Le centre d’exploitation ne voit aucune chute de session. Le voisin est toujours Established, les keepalives circulent et la majorité de la table demeure. Pourtant, plusieurs destinations viennent de disparaître. Elles partageaient un UPDATE dont un attribut était mal formé ; le routeur a traité toutes les NLRI du message comme si le voisin les avait retirées.

Ce cas illustratif résume la portée réelle de la RFC 7606. La révision protège BGP contre le dommage collatéral d’une réinitialisation systématique, mais elle ne transforme pas des octets ambigus en route valide. Elle choisit l’unité de confiance à supprimer : toute la session, une famille d’adresses, toutes les routes d’un UPDATE, ou seulement un attribut dont l’absence est réputée sans effet sur la sélection et l’installation.

Dans le modèle de base de la RFC 4271, les erreurs d’UPDATE sont signalées par une NOTIFICATION. La RFC 7606 décrit ce comportement historique comme un session reset : la session est terminée et toutes les routes apprises par ce voisin sont retirées. La réaction est claire, mais son rayon d’impact est disproportionné lorsqu’un seul attribut corrompu accompagne une poignée de préfixes au milieu d’une adjacence qui en transporte beaucoup d’autres.

Quatre décisions de confinement

La RFC 7606 classe les réponses de la plus forte à la plus faible.

La réinitialisation de session reste la réponse lorsque le message ne permet pas d’identifier sans ambiguïté les routes concernées ou lorsqu’une spécification l’exige encore. Fermer la session signifie renoncer à toute l’autorité de routage portée par le voisin, pas seulement au message fautif.

La désactivation d’un AFI/SAFI contient l’échec à une famille. La RFC 4760 prévoit, pour certaines erreurs MP_REACH_NLRI ou MP_UNREACH_NLRI, la suppression des routes de l’AFI/SAFI concerné puis l’ignorance des annonces suivantes de cette famille pendant la session. Les autres familles peuvent continuer ; celle-ci n’est pas simplement amputée d’un seul UPDATE, elle perd sa capacité d’être apprise sur cette adjacence.

Avec treat-as-withdraw, toutes les routes du message fautif sont traitées comme retirées et supprimées de l’Adj-RIB-In. La granularité est le message. Si le routeur émetteur a regroupé plusieurs NLRI avec le même jeu d’attributs, elles partagent le même sort, même si une seule destination avait attiré l’attention de l’opérateur.

L’abandon d’attribut retire l’attribut mal formé puis poursuit le traitement de l’UPDATE. La RFC 7606 l’interdit lorsque l’attribut influe sur la sélection ou l’installation. Cette condition ne se vérifie pas uniquement dans le protocole : une politique locale peut donner un rôle décisif à un attribut normalement informatif. Il faut donc lire la politique effectivement compilée, pas seulement la définition théorique de l’attribut.

Ces actions ne sont pas quatre degrés d’une réparation automatique. Elles répartissent la perte. Le routeur choisit la plus petite portion d’état qu’il peut abandonner sans prétendre comprendre ce qui ne l’est pas.

La limite est la possibilité de retrouver les NLRI

Pour appliquer treat-as-withdraw, le récepteur doit pouvoir localiser et analyser entièrement les champs NLRI concernés, y compris MP_REACH_NLRI ou MP_UNREACH_NLRI. Si une longueur incohérente empêche de savoir où commencent ou finissent les routes, le confinement au message devient une fiction. Les procédures plus fortes de la RFC 4271 ou de la RFC 4760 restent alors nécessaires.

Cette limite explique pourquoi l’activation d’un mode « enhanced error handling » ne garantit pas l’absence de reset. Certaines erreurs restent trop graves pour isoler des routes précises. Inversement, un filtre configuré par l’opérateur peut imposer treat-as-withdraw à un attribut précis alors que l’UPDATE reste analysable.

La présence de plusieurs erreurs ne permet pas de choisir la réaction la plus confortable. Lorsque les actions prescrites diffèrent, la RFC 7606 impose la plus forte. Une erreur autorisant l’abandon d’un attribut ne neutralise pas une seconde erreur exigeant le retrait du message ou la fermeture de la session.

Les règles par attribut le montrent. Les erreurs révisées touchant ORIGIN, AS_PATH, NEXT_HOP, MULTI_EXIT_DISC ou LOCAL_PREF conduisent à treat-as-withdraw dans les cas définis ; certains défauts d’ATOMIC_AGGREGATE ou d’AGGREGATOR conduisent à l’abandon d’attribut. Deux MP_REACH_NLRI ou MP_UNREACH_NLRI dans le même UPDATE déclenchent encore une NOTIFICATION de liste d’attributs mal formée, alors que, pour la plupart des autres doublons, seule la première occurrence est conservée.

Les extensions plus récentes fixent leur propre frontière. La RFC 8092 exige treat-as-withdraw lorsque la longueur de l’attribut Large Communities n’est pas un multiple non nul de douze octets ; des valeurs répétées ne rendent pas l’attribut mal formé et sont simplement dédupliquées. La RFC 7607 interdit l’AS 0 dans plusieurs champs, mais renvoie le traitement à la RFC 7606 ou à la RFC 6793 selon qu’il s’agit d’AS_PATH, d’AGGREGATOR ou de leurs variantes à quatre octets.

Le registre IANA des paramètres BGP fournit les codes d’attribut et les sous-codes d’erreur actuels. Un numéro enregistré nomme le champ ; il ne rend pas légitime n’importe quel abandon local de sa signification.

La session verte déplace le travail d’observation

Le reset rend l’incident visible : le voisin tombe et toutes ses routes partent. Treat-as-withdraw réduit ce dommage, mais rend le défaut plus discret. Les destinations du message peuvent devenir injoignables ou prendre une route sous-optimale sans transition de session.

Sur une session iBGP, la RFC 7606 avertit en outre qu’un traitement divergent peut créer des croyances différentes dans le même AS, avec boucles persistantes ou trous noirs. Une route conservée sur un réflecteur et retirée sur un autre n’est pas une panne de session ; c’est une incohérence de plan de contrôle qui peut atteindre le plan de données.

Il ne faut pas confondre treat-as-withdraw avec l’abandon silencieux du message. BGP est incrémental. Ignorer l’UPDATE peut laisser en place une ancienne route que le nouvel état aurait dû remplacer ou retirer. Treat-as-withdraw produit une perte explicite ; jeter le message peut conserver un passé faux.

L’enquête doit donc commencer au fil. La RFC 7606 demande des moyens de diagnostic capables d’indiquer les NLRI en cause et de conserver l’UPDATE entier. Un compteur global ne suffit pas : il ne montre ni l’attribut, ni toutes les destinations regroupées, ni la possibilité réelle de les analyser, ni la raison d’une différence entre deux routeurs.

La Route Mirroring de BMP, RFC 7854 peut envoyer une copie verbatim d’un PDU reçu et signaler qu’il a été traité comme retiré. Ce n’est pas un journal universel. La copie peut être échantillonnée, perdre des messages et consommer mémoire ou temps de traitement ; le code Messages Lost fait partie de la preuve autant que le PDU capturé.

Reconstituer la chaîne de décision

Il faut d’abord figer le voisin, la direction, l’AFI/SAFI, le code d’attribut, les flags, les longueurs et toutes les NLRI du message. On enregistre ensuite la version logicielle et la configuration effective après héritage de groupe. Une ligne de configuration identique ne prouve pas un parseur, un défaut ou une action identiques entre plates-formes.

Le verdict doit être nommé : reset, désactivation de famille, treat-as-withdraw ou abandon d’attribut. Puis l’Adj-RIB-In ou la vue des routes cachées montre ce qui a réellement été retiré. La Loc-RIB indique si une solution de remplacement a gagné. Les réflecteurs et les sorties pertinentes révèlent une éventuelle divergence. La FIB ou le matériel prouve ce qui est devenu transférable, et des paquets contrôlés, dans les deux sens, montrent le service que les compteurs de session ne voient pas.

La documentation officielle illustre les différences d’implémentation. Le guide Cisco IOS XR montre des journaux comportant voisin, longueur, attribut, famille, NLRI et action TreatAsWithdraw ou DiscardAttr. La documentation Junos sur les erreurs BGP décrit reset, retrait, routes cachées et journalisation. Nokia SR OS expose un contrôle update-fault-tolerance opposant des réactions non destructives à certaines erreurs au comportement historique. Ces documents prouvent des possibilités ; ils ne créent ni syntaxe ni défaut communs à tous les produits.

Une alarme silencieuse n’est pas une reprise

La correction durable se fait à la source du mauvais attribut. Pour un défaut observé en iBGP, la RFC 7606 recommande de remonter jusqu’au routeur d’entrée qui a créé ou reçu l’information et d’y filtrer ou corriger le problème, afin de rétablir une vue cohérente dans l’AS.

La fermeture de l’incident exige un UPDATE propre. Les routes corrigées doivent revenir dans l’Adj-RIB-In, converger de manière identique, produire la Loc-RIB attendue, rejoindre la FIB et restaurer les paquets. Un filtre d’urgence doit avoir une date, un propriétaire et une décision de retrait ou de maintien ; sinon il devient une politique permanente fondée sur un défaut oublié.

Le résultat recherché n’est donc pas « aucune session n’est tombée ». C’est la preuve qu’un récepteur a sacrifié exactement l’état nécessaire, qu’il n’a pas effacé une information utile, qu’il a conservé le PDU permettant de justifier son choix et qu’un message corrigé a rendu aux destinations leur chemin réel.