Résumé

  • Le 7 septembre à 09 h 19 CEST, RIPE NCC a déclaré l’incident RRC18 résolu après le redémarrage de deux services, tout en précisant que la cause restait inconnue et que l’enquête continuait.
  • À 09 h 33 CEST, l’organisation a signalé pour RRC24 un arrêt similaire de publication des fichiers update et bview, soupçonné une origine commune non identifiée et indiqué que d’autres RRC ne pouvaient pas encore être exclus.

Quatorze minutes séparent les deux publications. Elles ne séparent pas nécessairement les deux pannes. L’heure de 09 h 19 est celle du message de résolution de RRC18 ; 09 h 33 est celle de l’ouverture publique de l’incident RRC24. Le dossier ne donne ni l’instant technique de départ de RRC24, ni la preuve que le redémarrage de RRC18 aurait déplacé le problème. Cette retenue est essentielle : RIPE NCC parle d’un incident qui « reflète » le précédent et d’une cause commune « soupçonnée », pas démontrée.

Le fait vérifiable est toutefois remarquable. Au moment où le tableau public fermait un incident, son texte conservait la question causale ouverte. Huit cent une secondes plus tard, un nouveau message étendait cette question à un second collecteur et n’écartait pas une extension à d’autres RRC.

RRC18 : le service revient, l’explication non

L’incident RRC18 a été publié le 4 septembre à 18 h 14 CEST. RIPE NCC indiquait que les fichiers RIS update et bview n’étaient plus publiés. Le dernier fichier update cité portait l’horodatage du 4 septembre à 13 h 35 UTC ; le dernier bview, celui de 08 h 00 UTC. Ces repères décrivent les derniers objets nommés par l’opérateur. Ils ne permettent pas de calculer une durée exacte de panne, un nombre total de fichiers concernés ou l’état de toutes les interfaces RIS.

Le 5 septembre, après examen du système de traitement des messages de RRC18, RIPE NCC disait ne pas avoir trouvé la cause. Plus tard, l’organisation annonçait la publication des updates et bviews manquants, le rétablissement du flux de RRC18 et le passage en surveillance. La note finale du 7 septembre ajoutait le geste technique : deux services d’arrière-plan avaient été redémarrés. Elle ajoutait aussi une réserve tout aussi importante : la cause n’était toujours pas claire et le dépannage se poursuivait.

Le mot « résolu » était donc exact dans un sens opérationnel. Le service public fonctionnait de nouveau. Il ne pouvait pas, à lui seul, signifier qu’un mécanisme de défaillance avait été identifié, circonscrit et empêché de se reproduire.

RRC24 élargit la question du domaine de panne

La documentation de RIPE RIS décrit RRC18 comme un collecteur relié à un point d’échange, hébergé chez CATNIX à Barcelone, en Espagne. RRC24 est un collecteur multihop hébergé chez LACNIC à Montevideo, en Uruguay, avec une portée régionale. La différence de lieu et de mode de collecte n’établit aucun diagnostic. Elle rend simplement légitime une question d’architecture : quel élément partagé pourrait produire le même symptôme de publication sur ces deux parcours ?

Le message RRC24 n’y répond pas. Il dit que le système a cessé de publier les fichiers update et bview, que le problème ressemble à celui de RRC18 et qu’une cause commune est envisagée. Il ajoute que RIPE NCC ne peut pas exclure que d’autres collecteurs rencontrent le même problème dans les heures ou les jours suivants. Le dossier capturé est encore au stade de l’investigation.

Il serait abusif d’en déduire une perte de données BGP, une corruption de fichiers ou un effet sur le routage. La documentation RIS explique seulement que les données MRT sont publiées par collecteur, que les bviews représentent un état de routage à intervalles de huit heures et que les updates enregistrent les changements par tranches de cinq minutes. Ces objets servent ensuite de preuves aux opérateurs et aux chercheurs. Leur publication doit donc être lisible comme un état de service, sans être confondue avec l’état de la collecte ou du réseau lui-même.

La meilleure défense de RIPE NCC

Un opérateur sérieux ne devrait pas attendre une explication parfaite avant de rétablir un service. Le redémarrage de deux services peut être une mesure de confinement proportionnée. RIPE NCC a en outre rendu visibles ses limites : la cause était inconnue, l’analyse continuait, les fichiers RRC18 manquants avaient été republiés, le lien avec RRC24 restait une hypothèse, et le périmètre pouvait s’étendre.

Maintenir RRC18 en rouge alors que sa publication était revenue aurait créé une autre ambiguïté. Les tableaux d’état sont conçus pour répondre d’abord à la question « le service fonctionne-t-il maintenant ? ». Un seul indicateur ne sait pas toujours dire simultanément « oui » pour le service et « pas encore » pour la cause.

C’est précisément pourquoi la critique ne doit pas porter sur le redémarrage ni sur la clôture opérationnelle. Elle porte sur le modèle d’état. Dans la page RRC18, l’enquête ouverte survit comme une phrase à l’intérieur d’un incident fermé. La page RRC24 lui a donné une visibilité nouvelle, mais seulement parce qu’un symptôme analogue a fait l’objet d’un second message.

Un reçu à deux clôtures

RIPE NCC peut corriger cette faiblesse sans publier de topologie sensible. Un reçu public minimal associerait à chaque incident le collecteur, la classe de symptôme, l’action de rétablissement et l’heure du retour du service. Il conserverait séparément l’état de la cause : non identifiée, hypothèse en cours, étayée, rejetée ou confirmée.

Lorsqu’un lien entre incidents est envisagé, un jeton stable et non sensible pourrait désigner la même cohorte de déploiement, de bascule ou de dépendance. Le reçu indiquerait aussi le périmètre de surveillance des récidives, sa date d’expiration, le responsable du suivi, la date de clôture causale et l’historique des corrections. Il n’a besoin de révéler ni noms d’hôtes, ni paramètres, ni identifiants internes.

Le dispositif protégerait deux vérités. RRC18 a bien été rétabli. La cause du symptôme n’était pas encore close. Si RRC24 se révèle indépendant, RIPE NCC peut rejeter le rapprochement sans réécrire le passé. Si une couche commune est identifiée, les deux dossiers peuvent être reliés avec une provenance datée.

Un autre incident, publié le 25 août, concernait des bviews générés mais non publiés après une mauvaise configuration suivant une bascule ; RIPE NCC y reconnaissait aussi une lacune de surveillance. Ce dossier soutient une analyse distincte sur la différence entre génération et livraison. Il ne prouve aucune causalité pour RRC18 ou RRC24, et le présent article ne reprend pas son remède fondé sur le suivi de chaque fichier. La question ici commence après le rétablissement : que doit conserver le registre public tant que le domaine de panne n’est pas compris ?

Sources