Résumé

  • Le scénario de LACNIC 46 oppose une coupure de 14 secondes à environ 90 minutes pour trouver sa cause : 23 minutes avant la première plainte, puis 67 minutes de diagnostic manuel.
  • Le système proposé rassemble syslog, API RouterOS, données RADIUS et topologie sur un serveur local ; un modèle de langage pourrait ensuite interroger ces données par SQL en lecture seule.

La diapositive la plus ambitieuse du projet affiche 18 minutes. C’est le temps de diagnostic visé pour ramener une recherche qui en prendrait environ 90, selon le scénario présenté par Joaquín Tadeo Riedmaier et Santiago Agustín Zualet à LACNIC 46 · LACNOG 2026, à Mendoza. Le point de départ est une coupure de 14 secondes. Dans l’estimation des auteurs, la première plainte arrive 23 minutes plus tard et l’enquête manuelle en réclame encore 67.

Ces horaires sont donnés comme illustratifs, non comme les résultats d’un incident mesuré. Leur intérêt tient à la mécanique décrite : un lien tombe, les journaux sont dispersés entre les routeurs, les événements sans rapport couvrent le signal utile et le technicien ouvre chaque équipement à tour de rôle. L’interruption est terminée bien avant que la recherche de sa cause ne commence vraiment.

Riedmaier et Zualet, rattachés à la Faculté d’ingénierie de l’Université nationale de Misiones, ont présenté leur proposition pendant la séance de l’Internet Measurement Working Group. Elle réunit deux flux que l’exploitation consulte souvent séparément. Le premier pousse les messages syslog en UDP : erreurs, changements d’état, liens instables et déconnexions PPPoE/RADIUS. Le second interroge l’API REST de RouterOS v7 pour obtenir le trafic, les erreurs et les pertes par interface ou VLAN, ainsi que le CPU, la mémoire, les tables ARP et le suivi des connexions.

Un nœud Docker hébergé chez le fournisseur d’accès reçoit ces éléments. Django gère syslog et les requêtes API ; Python nettoie le bruit, normalise et déduplique les événements, puis évalue des seuils ; PostgreSQL conserve les vues préparées pour le diagnostic. Les sessions RADIUS et la topologie peuvent alors donner du contexte à un lien qui clignote : quel équipement, quelle interface, quels abonnés concernés, quelles autres mesures au même moment ?

Le modèle local intervient à la fin de cette chaîne. L’opérateur formule une question courante ; le système construit une requête SQL sur des vues aplaties et limite le compte de base de données aux lectures. Le modèle n’a pas le droit d’écrire dans les données. Les auteurs indiquent un essai sur une machine dotée de 32 Go de mémoire, sans donner le modèle choisi ni la charge de travail. La démonstration d’écran qui suit montre sept pertes de lien sur ether2, sur NAS 6, et 23 sessions PPPoE touchées. Elle est explicitement présentée comme un exemple illustratif.

Une autre diapositive aligne les erreurs d’interface, les connexions suivies, RADIUS et PPPoE à 12 h 04, puis suggère une panne physique en amont. Les auteurs précisent que ce cas est simulé et que la corrélation n’est pas un résultat mesuré. C’est une démonstration de la forme attendue d’une réponse, pas un ticket d’incident résolu.

Le projet sépare bien l’alerte et l’enquête. Des seuils doivent avertir avant l’appel du client ; le tableau de bord et les questions en langage courant servent ensuite à comprendre ce qui s’est passé. Cela place le modèle dans un rôle d’accès aux données, pas d’oracle. Une réponse bien rédigée ne répare ni une mesure absente ni une horloge mal alignée : les événements doivent arriver à temps et être reliés aux bonnes sessions avant qu’une fenêtre de chat ne puisse aider.

Les auteurs qualifient les 90 minutes d’estimation et les 18 minutes d’impact attendu, sans publier d’échantillon d’incidents ISP, d’intervalle de collecte, de mesure avant/après, de taux de fausses alertes ni de protocole pour leur objectif d’au moins 95 % ; un relevé de pilote ventilé par incident changerait cette lecture.

Cette lacune n’efface pas la proposition. Elle indique ce que la prochaine version doit démontrer : quel capteur a vu une coupure brève, quand l’alerte est partie, quelles données ont guidé l’opérateur et à quel moment la cause a été confirmée. Les 18 minutes sont aujourd’hui une promesse de conception. Un historique de terrain pourrait en faire un résultat utile aux petits fournisseurs qui ne disposent pas d’une salle d’exploitation remplie de spécialistes.

Sources : programme officiel de LACNIC 46 ; présentation originale de l’IMWG.