Résumé

  • PeeringDB indique dans les notes de la version 2.84.0, datée du 21 octobre, avoir corrigé des suppressions de connexions à des points d’échange que les clients utilisant ?since= ne recevaient pas. Le signalement initial décrit des lignes netixlan effacées sans état « deleted » et des fiches réseau dont l’horodatage updated restait ancien.
  • Le correctif modifie le chemin de suppression et ajoute un test sur la réponse de l’API. Il agit sur les changements à venir. Pour nettoyer une copie déjà divergente, l’auteur du signalement préconise une synchronisation complète ; le nombre de copies corrigées n’est pas publié.

Un départ sans avis de départ

Un annuaire d’interconnexion sert souvent à dresser une liste de contacts ou à préparer une présence à un échange. Imaginons deux équipes ouvrant la même fiche réseau : l’une interroge PeeringDB, l’autre sa copie locale. La première ne voit plus la connexion ; la seconde la trouve encore. La fiche décrit une présence déclarée, pas le trafic d’une session BGP. L’erreur porte déjà assez loin sans lui prêter une panne : les deux équipes ne travaillent plus sur le même état public.

Le contrat technique est décrit dans les spécifications de l’API de PeeringDB. Le paramètre ?since= demande les objets modifiés depuis un instant donné. Les objets supprimés peuvent être récupérés avec le statut deleted et une valeur since positive. La FAQ du service précise qu’un cache peeringdb-py commence par une copie intégrale, puis prend les modifications au fil de l’eau. Cette économie de requêtes suppose que l’ajout, la modification et la suppression voyagent tous par le même canal. Une suppression muette transforme une copie efficace en archive trompeuse.

Le 7 octobre, Remco van Mook a ouvert le signalement PeeringDB #2057 après avoir comparé une copie alimentée par ?since= aux listes complètes de l’API. Il a suivi le traitement périodique du statut auprès des registres Internet : lorsqu’un réseau ne remplissait plus les conditions, le programme supprimait en bloc ses lignes netixlan, qui relient un réseau à un LAN d’échange, avant de supprimer le réseau. La suppression en bloc passait à côté de la méthode qui aurait marqué chaque ligne deleted et avancé son horodatage. La ligne quittait la base ; aucun changement ne se présentait au prochain appel incrémental.

Le signalement décrit une deuxième panne de transmission. Certaines fiches réseau devenaient deleted, mais leur champ updated conservait l’heure de l’ancien état. Les exemples publiés associent une suppression en 2026 à une date updated de 2022. Un client qui demande « depuis mon dernier passage » ne verra jamais un changement daté quatre ans trop tôt. Cette fois, le statut existe encore à la source, mais le filtre temporel le cache.

Les chiffres disent où regarder

Dans sa comparaison sur environ six mois, le rapporteur a repéré 286 connexions netixlan effacées brutalement, rattachées à 125 réseaux, ainsi que 46 réseaux supprimés sans mise à jour de l’horodatage. PeeringDB ne donne pas le nombre de clients ni de décisions touchés. Les chiffres du signalement démontrent une dérive accumulée dans une copie précise. Ils suffisent aussi à écarter l’idée d’un cas unique inventé pour un test.

Un commentaire du 9 octobre décrit l’anomalie inverse : 569 lignes netixlan encore actives à la source manquaient dans la copie synchronisée. Elles concernaient 349 réseaux et 279 échanges. L’auteur avançait deux chemins possibles, sans départager la cause : une transaction devenue visible après la fenêtre de lecture malgré un horodatage antérieur, ou une restauration sans nouvelle date. Le correctif des suppressions ne règle pas ce second mystère par simple voisinage dans le même ticket.

Le coût d’une telle divergence est facile à situer. Une équipe de peering peut contacter un réseau sur la foi d’une présence périmée. Un outil d’inventaire peut signaler comme actuel un lien dont la source a effacé la fiche. Un autre contrôle peut perdre du temps à arbitrer deux réponses contradictoires. Le ticket ne rapporte ni session BGP erronée ni incident de routage. Il établit le défaut de cohérence qui précède ce genre de mauvaise décision : le client peut finir sa synchronisation sans erreur et rester faux sur l’existence d’une ligne.

PeeringDB a fusionné le 20 octobre le correctif 81ac767. Le code retire l’effacement en bloc des connexions actives et laisse la suppression du réseau traiter ses dépendances. Le nouveau test construit un réseau, des connexions à un échange et un contact technique ; il déclenche ensuite le traitement RIR et vérifie trois choses visibles : le réseau et les connexions passent à deleted, leurs dates avancent, et une requête API ?since= retourne les connexions supprimées. Tester la réponse de l’API compte davantage qu’un message interne « suppression réussie » : c’est elle que reçoit la copie.

Les notes de version PeeringDB datent la 2.84.0 du 21 octobre et inscrivent le ticket #2057 parmi les corrections destinées aux utilisateurs qui synchronisent leurs données. Le calendrier indiquait le 20 octobre comme cible de production ; la note de version porte sa propre date. Aucune des deux ne décrit une opération qui aurait effacé automatiquement les anciennes lignes fantômes des caches déjà distribués.

La réparation traverse-t-elle la frontière ?

Pour une future suppression suivant le chemin testé, la source sait désormais annoncer le départ. Le passé est moins docile : une ligne détruite sans tombstone n’existe plus pour produire tardivement un événement. Une fiche dont la date de mise à jour reste en 2022 ne franchira pas non plus un curseur placé en 2026. Le signalement indique la remise à plat complète comme réparation côté client. Il manque un relevé public des copies effectivement reconstruites ; ce fait changerait l’appréciation de la dette résiduelle.

Ce n’est pas une simple corvée informatique. La copie locale existe précisément pour éviter de télécharger tout l’annuaire à chaque consultation. Après une erreur de suppression à la source, le prix de la réconciliation retombe sur chaque exploitant d’une copie. PeeringDB contrôle la transition d’état et l’API ; le client contrôle son curseur et sa fréquence de reconstruction. Une tâche de synchronisation réussie ne suffit pas à certifier que les deux inventaires concordent.

Le projet d’API v3 exige que les suppressions et retraits figurent dans les deltas, les instantanés quotidiens servant de départ et de repli. Ce texte est encore un projet. Son intérêt ici est une question vérifiable pour le prochain contrat : chaque retrait aura-t-il une identité et une version que le lecteur peut constater ? La disponibilité d’un serveur ne répond pas à cette question. Un serveur peut répondre à chaque appel tout en taisant la seule modification recherchée.

Un petit raccourci dans un chemin de suppression a créé deux réalités d’annuaire. La 2.84.0 répare ce raccourci. Le reste demande une comparaison entre copie et source, puis une preuve que la prochaine suppression prendra effectivement le chemin observable.