Résumé

  • Le route flap damping répondait à une contrainte documentée: les rafales de mises à jour BGP pouvaient saturer les premiers moteurs de routage et provoquer de nouvelles instabilités.
  • Son compteur ne distinguait pas une liaison qui tombait sans cesse de l’exploration normale de chemins après un retrait. Une seule panne, suivie d’un rétablissement, pouvait donc maintenir un préfixe supprimé jusqu’à une heure dans certaines topologies étudiées.
  • L’autorité exécutable était distribuée. Les RFC décrivaient, les constructeurs programmaient les valeurs par défaut et chaque opérateur activait ou non le mécanisme; le détenteur du préfixe ne contrôlait pas le compteur d’un AS distant.
  • Après la démonstration du coût de convergence en 2002, les recommandations sont passées de paramètres coordonnés à la désactivation, puis à des seuils plus conservateurs. La correction durable a suivi la surface de configuration existante plutôt qu’une refonte générale de l’algorithme.

La route était revenue, pas le droit de l’utiliser

RIPE-229 conserve un récit d’exploitation remarquable par sa simplicité. Une mise à jour logicielle planifiée d’un routeur de cœur entraîne un rechargement: un flap. Le nouveau logiciel tombe en panne: un deuxième. L’ancien logiciel est restauré: un troisième. Dix minutes se sont écoulées.

L’opérateur a fait ce que l’on attend d’une exploitation prudente: il a essayé, constaté l’échec et fait marche arrière. Pourtant, des paramètres agressifs appliqués à certaines frontières de transit et de peering ont retenu ses préfixes /24, ainsi que ceux de ses clients, pendant plus de trois heures selon le document. Le réseau d’origine était réparé. Ailleurs, la pénalité continuait de décroître.

L’épisode a compté dans le choix suivant. À RIPE 27, il fut décidé de ne pas supprimer avant le quatrième flap consécutif et de limiter l’attente à une heure après le dernier. La nouvelle borne corrigeait un excès manifeste. Elle consacrait aussi l’idée qu’un /24 redevenu stable pouvait rester invisible pendant une heure.

Une réponse raisonnable à des machines limitées

Il serait trop facile de relire cette histoire comme l’invention gratuite d’un pouvoir de filtrage. Les archives des années 1990 décrivent un autre contexte. Le nombre de préfixes augmentait, les interconnexions entre fournisseurs devenaient plus denses et une modification de route devait être traitée par tous les équipements portant la table complète. La sélection BGP et la mise à jour des tables de transfert consommaient une capacité alors rare. Un routeur surchargé pouvait perdre ses sessions, générer de nouveaux retraits et transmettre la crise à ses voisins.

Les documents RIPE situent le développement du RFD en 1993 et son intégration dans Cisco, ISI/RSd et GateD à partir de 1995. Lorsque le RFC 2439 fut publié en novembre 1998, ses auteurs indiquaient déjà que le procédé se trouvait dans des produits commerciaux et était largement déployé. Le code et la pratique ont donc précédé la formalisation complète.

Le mécanisme attribue une pénalité à une route reçue d’un voisin eBGP. Un retrait augmente la valeur; suivant l’implémentation, une réannonce ou un changement d’attribut peut aussi compter. La pénalité décroît de manière exponentielle. Au-dessus du seuil de suppression, la route n’est plus utilisée. Sous le seuil de réutilisation, elle peut revenir. Une durée maximale limite la mémoire.

Le RFC 2439 formulait trois objectifs: réduire la charge, empêcher les oscillations soutenues et ne pas retarder les routes normalement stables. Il reconnaissait aussi qu’aucun algorithme ne pouvait prédire correctement la stabilité future. L’historique récent servait donc de substitut. Ce choix, efficace à calculer, déplaçait toute la difficulté vers la définition d’un changement significatif.

Coordonner des choix locaux

Les premières implémentations n’avaient pas les mêmes valeurs par défaut. Deux opérateurs pouvaient choisir des demi-vies, des seuils et des durées maximales différents. Le même préfixe redevenait utilisable dans une partie du réseau et restait supprimé dans une autre. Le fournisseur d’accès pouvait effacer son propre état après réparation, mais pas celui d’un routeur inconnu plusieurs AS plus loin.

Une discussion à RIPE 26 conduisit à un BOF; RIPE 27 forma un groupe de travail; RIPE-178 parut en 1998. Tony Barber, chez UUNET, avait conçu un jeu de paramètres testé pendant plusieurs mois dans son environnement. RIPE-229 le révisa en 2001 et demanda aux FAI ainsi qu’aux constructeurs d’adopter des valeurs communes.

Il s’agissait d’une coordination, pas d’un gouvernement des routeurs. RIPE pouvait recommander, mais pas modifier une configuration. Un RFC pouvait définir le mécanisme, mais pas l’activer. Les constructeurs détenaient le pouvoir d’inscrire les compteurs, les constantes et les valeurs initiales dans le logiciel. Les opérateurs détenaient le pouvoir d’exécuter ces choix sur leur propre matériel.

La recommandation distribuait aussi les coûts selon la longueur du préfixe. L’approche « graduée » de RIPE-229 traitait les /24 et les préfixes plus longs plus sévèrement: une heure de suppression une fois le seuil franchi. Les agrégats plus courts recevaient des durées plus faibles. Les auteurs invoquaient l’agrégation et le nombre d’utilisateurs potentiellement couvert. Les petits réseaux multihomés avaient cependant besoin de routes plus spécifiques; leur résilience pouvait ainsi devenir la raison de leur pénalisation.

L’exception dite des « Golden Networks » montrait la fragilité de la mesure. Des serveurs racine et des serveurs de TLD se trouvaient eux aussi dans des préfixes longs. Les supprimer par erreur aurait coûté trop cher, de sorte que le document proposait de les exclure. La longueur n’était pas devenue un meilleur prédicteur; certains acteurs avaient simplement été reconnus comme trop importants pour subir la règle générale.

Quand BGP compte ses propres hésitations

Après le retrait d’une route, BGP ne passe pas toujours directement du meilleur chemin à l’absence de chemin. Les routeurs voisins peuvent explorer plusieurs chemins AS. Chaque nouvelle préférence produit un changement d’attribut, qui se propage à son tour. Pour un compteur RFD, ces étapes peuvent ressembler à des fautes répétées du préfixe d’origine.

En 2002, Zhuoqing Morley Mao, Ramesh Govindan, George Varghese et Randy Katz ont étudié cette interaction avec un modèle analytique, des simulations, des traces et un banc de routeurs commerciaux. Dans les topologies examinées, un seul retrait suivi d’une réannonce pouvait engendrer assez de changements secondaires pour supprimer le retour de la route pendant une heure. RIPE-378 a ensuite cité une mesure où un retrait produisait 41 événements BGP quelques sauts d’AS plus loin.

La portée doit rester exacte. L’étude ne mesurait pas le déploiement mondial et n’affirmait pas que chaque topologie produisait le même effet. Elle démontrait néanmoins qu’une hypothèse centrale était fausse: un score élevé n’était pas nécessairement la trace de pannes physiques répétées. Le protocole pouvait compter sa propre recherche d’une solution.

Les chercheurs proposèrent un damping sélectif qui ne pénalisait pas les changements monotones typiques de l’exploration après retrait. Dans les topologies testées, cette modification supprimait le phénomène tout en finissant par contenir une route réellement instable toutes les quarante secondes. C’était une alternative étayée, non une preuve de déploiement général.

Désactiver d’abord, régler plus tard

RIPE-378 décrit le tournant de 2006. Le document indiquait qu’aucune demande de l’industrie des FAI ni activité des implémenteurs n’avait suivi la proposition de 2002. Les routeurs étaient aussi devenus plus puissants, réduisant le poids de la contrainte initiale. Il déclarait obsolètes RIPE-229 et ses prédécesseurs et déconseillait le RFD tel qu’il était alors implémenté dans les réseaux de FAI.

Une enquête publiée comme Internet-Draft en 2012 recueillit 63 réponses volontaires sur plusieurs listes d’opérateurs. Treize personnes déclaraient utiliser le RFD, 49 non; quinze réponses invoquaient RIPE-378 parmi les raisons de ne pas l’utiliser. Cet échantillon auto-sélectionné ne donne aucun taux mondial fiable. Il confirme plus modestement que la désactivation était une pratique compréhensible et que l’impact sur les clients préoccupait les répondants.

Le retour proposé par RIPE-580 puis RFC 7196 ne niait pas l’interaction observée. Il visait seulement les préfixes les plus bruyants. Dans la semaine de données citée par RFC 7196, un seuil de 6 000 réduisait le taux de mises à jour de 19 % par rapport à l’absence de RFD tout en supprimant 90 % de préfixes de moins qu’un seuil de 2 000. À 12 000, 0,22 % des préfixes étaient supprimés, pour une baisse moyenne horaire des mises à jour d’environ 11 %.

RFC 7196 recommanda donc au moins 6 000 pour un usage encore agressif mais moins destructeur, et au moins 12 000 pour un choix conservateur. Il suggéra aussi un mode de calcul sans suppression. Il demanda cependant de ne pas modifier silencieusement les valeurs par défaut existantes, afin de ne pas casser des configurations opérationnelles. Un erratum vérifié précise que le tableau des valeurs Cisco et Juniper n’était fourni qu’à titre d’information.

La dépendance apparaît ici sans autorité centrale. Une modification algorithmique exigeait du code, des tests et un déploiement coordonné. Un seuil plus élevé utilisait des commandes déjà présentes. Les anciennes valeurs pouvaient être critiquées tout en restant difficiles à changer automatiquement. Le coût de transition a pesé autant que la valeur technique.

L’autorité et la facture n’étaient pas au même endroit

Le détenteur du préfixe contrôlait sa propre annonce et sa réparation. Le registre pouvait fournir la preuve du titulaire de la ressource. Ni l’un ni l’autre ne commandait la réutilisation dans un routeur distant. L’opérateur de transit ou de peering contrôlait l’exécution du RFD. Le constructeur contrôlait les options disponibles. Les auteurs de normes et de recommandations contrôlaient la description et l’argument, pas les paquets.

Le bénéfice immédiat revenait au réseau qui réduisait le travail de son plan de contrôle. Lorsque la surcharge menaçait de faire tomber des routeurs, le bénéfice pouvait s’étendre à tous. En cas de faux positif, le coût changeait de côté: titulaire du préfixe réparé, clients et utilisateurs de ses services. L’enquête pouvait traverser plusieurs AS sans que la partie affectée sache lequel conservait encore la pénalité.

Un opérateur était localement autorisé à configurer le matériel qu’il possédait. Cela ne transformait pas une recommandation RIPE ou un RFC en mandat accordé par tous les titulaires affectés. Les sources ne prouvent ni illégalité ni violation contractuelle. La question de légitimité est plus concrète: la décision pouvait-elle être observée, attribuée et contestée par celui qui en payait le prix ?

Le contrefactuel doit enfin conserver la limite matérielle des années 1990. Sans RFD, davantage de mises à jour auraient atteint des routeurs plus fragiles. Un damping sélectif, des seuils conservateurs dès l’origine, un mode d’observation ou une télémétrie visible constituent de meilleures alternatives que l’hypothèse d’un coût nul. Chacune échange du bruit, du travail logiciel ou un risque d’abus contre moins de suppressions erronées.

Pour les détenteurs de ressources de numérotation, la frontière demeure. Un registre peut établir à qui appartient un préfixe et un AS peut l’annoncer correctement; la confiance opérationnelle reste pourtant une décision renouvelée dans chaque réseau. Le titre sur la ressource est une preuve. Il n’est pas un droit exécutable sur toutes les routes qui y mènent.

Sources