Zusammenfassung

  • Ein 14-sekündiger Linkausfall steht in den Folien neben 90 Minuten bis zur Diagnose: 23 Minuten bis zur Beschwerde, dann 67 Minuten Suche.
  • Die lokale Pipeline soll Router-, RADIUS- und Topologiedaten bündeln, die ein Sprachmodell per schreibgeschütztem SQL abfragt. 18 Minuten sind das Ziel, kein Messwert.

Eine Störung kann vorbei sein, bevor das Betriebsteam überhaupt weiß, dass es eine gab. In der Zeitlinie, die Joaquín Tadeo Riedmaier und Santiago Agustín Zualet bei LACNIC 46 · LACNOG 2026 in Mendoza zeigten, dauert der Linkausfall 14 Sekunden. Der erste Kundenhinweis kommt 23 Minuten später; die manuelle Diagnose nimmt weitere 67 Minuten in Anspruch. Zusammen sind das rund 90 Minuten bis zur Ursache.

Die Autoren der Fakultät für Ingenieurwissenschaften der Universidad Nacional de Misiones nennen diese Strecke eine typische Schätzung für einen kritischen Vorfall und kennzeichnen die Uhrzeiten als Anschauung. Ihr Beitrag fand in der Sitzung der Internet Measurement Working Group (IMWG) statt. Die zentrale Idee: Bevor ein Techniker Router für Router durchsucht, sollen Ereignisse, Gerätezustände und Teilnehmerdaten bereits an einem Ort liegen.

Dafür sieht die Architektur zwei Wege vor. UDP-syslog liefert Ereignisse wie Fehler, Zustandswechsel, Link-Flapping und PPPoE/RADIUS-Abbrüche. Die REST-API von RouterOS v7 liest Verkehr, Fehler und Verwerfungen nach Interface oder VLAN, CPU- und Speicherauslastung, ARP sowie Connection-Tracking aus. RADIUS ergänzt den Sitzungszustand je NAS. Erst zusammen lässt sich fragen, ob ein kurz aussetzender Port zur selben Zeit bestimmte Teilnehmerverbindungen verloren hat.

Die Daten laufen in einem Docker-Knoten innerhalb des ISP. Django nimmt syslog entgegen und fragt die API ab; Python filtert Rauschen, vereinheitlicht und dedupliziert Ereignisse und prüft Schwellwerte; PostgreSQL hält flache Ansichten für die Abfrage bereit. Ein lokales Sprachmodell soll daraus SQL erzeugen. Die Ansichten verringern die Zahl der Verknüpfungen, und der Datenbankzugang des Modells darf nur SELECT ausführen. Die Folien erwähnen einen Test auf einem Gerät mit 32 GB RAM, nennen aber weder Modell noch Lastprofil oder Antwortzeit.

Eine Bildschirmfolie fragt nach Routern mit Link-Ausfällen in den vergangenen vier Stunden. Als Beispiel nennt die Antwort sieben Ereignisse an ether2 auf NAS 6 und 23 betroffene PPPoE-Sitzungen. Die Folie markiert die Szene als illustrativ. Eine weitere Grafik bündelt L2/L3-Fehler, Connection-Tracking, RADIUS und PPPoE um 12:04 Uhr und vermutet einen physischen Fehler. Auch dieses Szenario ist laut Präsentation simuliert; es ist kein gemessener Vorfall.

Die Lösung trennt Benachrichtigung und Ursachenanalyse. Schwellwertmeldungen sollen eintreffen, bevor sich Kunden beschweren; Dashboard und natürliche Sprache helfen anschließend bei der Rekonstruktion. Das Modell ist der Zugang zu den Datensätzen, nicht deren Ersatz. Fehlt das syslog-Ereignis, liegt die API-Abfrage weiter auseinander als der 14-Sekunden-Ausfall oder stimmen Geräteuhren nicht überein, kann eine gut formulierte SQL-Antwort die fehlende Ereignisfolge nicht wiederherstellen.

Die Präsentation bezeichnet die 90 Minuten als Schätzung und die 18 Minuten als erwartete Wirkung, veröffentlicht aber weder einen ISP-Vorfallsatz noch Abfrageintervall, Diagnosezeiten vor und nach dem Einsatz, Fehlalarmquote oder ein Messverfahren für das ≥95-Prozent-Ziel; ein nach Vorfällen aufgeschlüsseltes Pilotprotokoll würde die Bewertung ändern.

Das macht die nächste Anforderung klar: ein Probelauf mit Zeitstempeln vom ersten Routerereignis bis zur bestätigten Ursache. Daraus lässt sich ablesen, welche Messung den Kurz-Ausfall erfasste, wann die Warnung kam und ob der Techniker schneller handlungsfähig war. Erst diese Folge entscheidet, ob die lokale Datenbank und das Sprachmodell verlorene Suchzeit zurückgeben oder nur den Bildschirm verändern.

Quellen: offizielle Agenda der LACNIC 46; Originalpräsentation der IMWG.