Résumé

  • Le 8 novembre 2026, la base du RIS Looking Glass de RIPE NCC a épuisé une limite configurée à 32k descripteurs de fichiers. L’API interne a ensuite occupé tous les créneaux de traitement disponibles; Looking Glass, RIS Peers et d’autres API de RIPEstat sont devenues indisponibles.
  • La base et les API ont repris l’après-midi, mais les messages BGP restaient à rejouer. À 20 h 06 UTC, environ un dixième des pairs de RRC25 accusaient encore du retard. Le retour estimé vers 05 h 00 UTC le 9 novembre n’était pas une clôture; l’incident restait en Monitoring lors de notre vérification.

Une petite limite pour fermer plusieurs fenêtres

La panne est partie du meuble à tiroirs de l’observatoire. Dans son avis d’incident, RIPE NCC désigne la base du RIS Looking Glass et sa limite de 32k descripteurs de fichiers. Une fois cette limite atteinte, l’API interne chargée des requêtes Looking Glass a consommé tous les créneaux de traitement disponibles. Le public a perdu l’accès à Looking Glass, à RIS Peers et à beaucoup d’autres API de RIPEstat. Un plafond local est devenu un embouteillage commun.

Le chiffre 32k décrit une configuration, pas un nombre de routes perdues ou d’utilisateurs touchés. RIPE NCC ne publie ni la courbe des descripteurs ouverts, ni l’origine de leur hausse, ni la raison du choix de ce plafond. Sa séquence causale, elle, est précise. La base sature, l’API interne monopolise le traitement, plusieurs services publics n’acceptent plus les demandes. L’institution qui mesure les routes a trouvé un goulot d’étranglement dans son propre dispositif de mesure.

Le premier ticket client serait arrivé à 00 h 58 UTC le 8 novembre; le premier message public date de 12 h 51 UTC, soit 11 heures et 53 minutes plus tard. Ce ticket ne date pas à lui seul le début de la panne de chaque API. À 13 h 20 UTC, RIPE NCC expose le plafond et la saturation des créneaux. À 13 h 39 UTC, il annonce la base rétablie, une API en reprise et un débit proche de la normale.

Le guichet a rouvert; les observations arrivaient encore en retard

Cette reprise n’efface pas le second temps de l’incident. À 13 h 39 UTC, RIPE NCC précise que Looking Glass rejoue les messages BGP des heures précédentes et restera en retard pendant ce rattrapage. Sa documentation Looking Glass présente un flux d’observations RIS presque en temps réel, ventilé par collecteur et par pair, avec un champ latest_time. Le délai d’une réponse HTTP et l’âge de ce qu’elle montre ne sont pas le même chronomètre.

À 20 h 06 UTC, le retard persistait chez environ un dixième des pairs de RRC25, selon RIPE NCC, en raison d’un volume élevé de messages. Le centre prévoyait un rattrapage vers 05 h 00 UTC le lendemain et promettait une mise à jour. La documentation RIS Peers classe également les données par collecteur; ses consultations historiques s’alignent sur 00 h 00, 08 h 00 et 16 h 00 UTC. Une preuve de reprise doit donc parler des pairs et de l’heure de leurs données, pas seulement de la couleur d’un voyant API.

La panne a touché l’outil de RIPE NCC qui observe le routage, puis la fraîcheur des données qu’il affiche. L’accès aux réponses a été rétabli avant la fraîcheur de toutes les réponses. Le centre a décrit le premier rétablissement et laissé le second encore en cours.