Résumé

  • RIPE NCC a ouvert une enquête à 15 h 55 min 39 s, heure d'Europe centrale, le 3 novembre, puis marqué l'incident comme résolu à 16 h 50 min 45 s. Ces deux publications délimitent une période de signalement d'environ 55 minutes.
  • Le compte rendu publié à 17 h 17 attribue l'effet sur les applications utilisant la base de données à une bascule du répartiteur de charge. Le nettoyage des connexions périmées a servi de remède immédiat; configuration du pool et surveillance de l'usage des connexions restent à revoir.

Une bascule de charge peut réussir sur le schéma d'exploitation et échouer sur l'écran du membre. Le compte rendu de RIPE NCC décrit précisément cette frontière : les applications dépendant de la base de données ont été touchées par la bascule, et l'équipe a dû supprimer les connexions devenues périmées. Une voie de secours qui ne reprend pas les sessions de l'application ressemble à une porte de sortie dont on aurait oublié de déplacer la poignée.

La chronologie publique mérite d'être lue à la seconde, sans lui faire dire davantage. L'API de l'incident date l'ouverture de l'enquête de 15:55:39.649 et la résolution de 16:50:45.437. Soit 55 minutes et presque six secondes entre deux annonces. Aucun journal public ne chiffre les requêtes en échec au cours de cet intervalle. Celui-ci mesure donc la séquence publiée par l'opérateur, pas la durée d'indisponibilité subie par chacun.

L'objet concerné n'était pas une page de publicité. Le LIR Portal permet aux membres de voir les ressources IPv4, IPv6 et les numéros d'AS qui les concernent. Une présentation de RIPE NCC datée du 21 octobre explique le travail accompli depuis cette interface : lire la hiérarchie des allocations, vérifier les inscriptions, consulter l'utilisation, la base RIPE et le routage. Elle décrit aussi une nouvelle interface encore en conception et en test. Ces nouvelles vues ne sont pas la preuve qu'elles étaient déjà déployées le jour de l'incident; elles montrent pourquoi l'accès aux informations de ressources constitue un véritable outil de travail.

La base peut rester sous la garde de l'institution tandis que le chemin d'accès du membre se rompt. RIPE NCC identifie le point de rupture dans son propre texte. Le répartiteur a basculé, les applications ont conservé des connexions qui ne fonctionnaient plus, puis l'équipe les a nettoyées. Ce récit est plus utile que « problème technique résolu » parce qu'il sépare la redondance de l'infrastructure de la continuité du service. Il évite aussi de prétendre que des adresses ont changé de titulaire ou que des données ont disparu : le rapport ne décrit pas un tel événement.

Deux travaux sont annoncés. Revoir la configuration du pool doit modifier le comportement de renouvellement des connexions. Mieux surveiller leur usage doit permettre de voir les applications qui s'accrochent encore à une session morte. Le premier traite l'action, le second l'observation. Le rapport ne précise ni le déclencheur de la bascule, ni le nombre de membres touchés, ni la date de fin de ces travaux; ces éléments changeraient l'évaluation de la portée et de la réparation.

La phrase à retenir est simple : RIPE NCC a rétabli l'accès en supprimant des connexions périmées. La prochaine preuve de résilience sera une consultation de ressource réussie après une nouvelle bascule, vue depuis le portail et non depuis le seul répartiteur.

Documents originaux de RIPE NCC