Zusammenfassung

  • InterLAN IX beziffert den Einsatz von Lighthouse bei RIPE 93 mit neun Nokia-Routern, zwanzig Arista-Switches, 197 Diensten und 214 Portal-Kunden. Eine Änderung erhält eine Vorschau je Gerät, eine Prüfung vor dem Schreiben, einen Erreichbarkeitstest und ein Zeitfenster zum Bestätigen oder Zurückrollen.
  • Die externe API kann Schreibwünsche über gesperrte und protokollierte Transaktionen auslösen. Der KI-Assistent nutzt ausschließlich lesende Diagnosewerkzeuge; KI-gestützte Konfigurationsänderungen stehen noch unter „Geplant“.

Ein grünes Häkchen im Portal ist billig. Ein konsistenter Dienst auf zwei unterschiedlich reagierenden Routern ist teuer. Genau diese Lücke steckt hinter dem Vortrag von Andrei Dinu aus dem Connect-Programm der RIPE 93. Die Originalfolien zu InterLAN Lighthouse sprechen von „atomaren“ Änderungen über mehrere Geräte. Sie zeigen aber auch, wie viel Handarbeit in diesem Wort steckt: versionierte Dienstvorlagen, erzeugte Konfiguration, Vorschau für jedes Ziel, Prüfung vor dem Commit, Erreichbarkeit danach und ein Ablaufprotokoll. Wenn Gerät eins den neuen Zustand annimmt und Gerät zwei nicht, beginnt erst die eigentliche Geschichte.

Die Folien nennen einen konkreten Betriebsumfang. InterLAN zeigt neun Nokia-Router, zwanzig Arista-Switches, 197 Dienste und 214 Kunden im Portal. Das sind Angaben des Betreibers zum Einsatz, keine veröffentlichte Erfolgsquote für Änderungen. Kunden können den Status ihrer Dienste einsehen und begrenzte Änderungen beantragen. Hinter dem Portal liegen drei getrennte Systeme: BirdNest für Route-Server, NoSignal für Live-TV und Lighthouse für Netzkonfiguration. Ein gemeinsamer Eingang macht aus ihnen noch keinen einzigen Kontrollmechanismus.

Auf Nokia-Geräten verwendet Lighthouse einen Bestätigungs-Timer. Bleibt die Bestätigung aus, stellt das Gerät die frühere Konfiguration wieder her. Davor prüft das System, ob es das Gerät noch erreicht; danach hält es Ergebnis und Rücknahme fest. Eine Bildschirmabbildung zeigt vier Minuten und zweiundvierzig Sekunden Restzeit in einem Beispiel. Diese Zahl ist keine allgemein zugesagte Frist. Entscheidend ist der Ablauf: Eine falsche Netzänderung kann den Verwaltungszugang selbst zerstören. Dann ist ein Rückweg auf dem Gerät wertvoller als die Hoffnung, jemand könne rechtzeitig den Knopf im Portal drücken.

Der zweite Konflikt sitzt zwischen Datenbank und laufender Maschine. Lighthouse vergleicht gespeicherte Sollwerte mit der Konfiguration des Geräts. Manuelle Eingriffe bleiben als Abweichungen sichtbar; Prüfungen suchen fehlende SAPs und doppelte IDs oder EVIs. Ein Operator kann über eine neue Transaktion reparieren oder eine Abweichung übernehmen, falls das erlaubt ist. Wer nachts einen Dienst gerettet hat, möchte nicht, dass sein Eingriff beim nächsten Abgleich geräuschlos verschwindet. Die Datenbank besitzt das Soll, aber sie besitzt nicht automatisch die bessere Antwort auf einen Notfall.

Vor dem Produktivwechsel gibt es eine Probe im digitalen Zwilling. InterLAN übernimmt die zuletzt gespeicherte Konfiguration und die bekannte Topologie, bereinigt die Vorlage und baut ein eigenes Labor mit Containerlab und Nokia srsim. Dort werden nahezu dieselben Aktionen und Rücknahmen geübt, ohne eine Änderung zurück ins produktive Netz zu schreiben. Die Grenzen stehen ebenfalls auf der Folie: Management und Routing müssen vorbereitet sein; Arista vEOS und BIRD-Container für Kundensimulation sind weitere Vorhaben. Das Labor ist nützlich, gerade weil sein Rand erkennbar bleibt.

Die modische KI-Frage beantwortet InterLAN mit einer Rechtevergabe. Die externe API erlaubt Lesen und Schreiben, doch Schreibvorgänge gehen durch Transaktionen, Sperren, Rücknahme und Audit. Der Assistent erhält lesende MCP-Werkzeuge für Zustand, Logs und Diagnostik. Die Beispiele zeigen einen Kundenbericht und einen Migrationsplan. KI-gestützte Änderungen stehen auf der Folie „Nächste Schritte“ und folgen der Reihenfolge Vorschlag, Prüfung, Freigabe. Das System kann einen Plan formulieren; es kann ihn heute nicht selbst auf einen Router schreiben.

RIPE NCC kommt in dieser Geschichte mit einer klaren, anderen Aufgabe vor. Laut RIS-Dokumentation steht der Sammler RRC22 bei InterLAN-IX in Bukarest. RIPE NCC betreibt die Messung, InterLAN den Austauschpunkt und Lighthouse. Ein beobachteter BGP-Pfad, ein gespeicherter Sollzustand und eine laufende Router-Konfiguration sind drei verschiedene Belege. Eine Messstelle bescheinigt dem Änderungswerkzeug keine sichere Ausführung.

Für ein Urteil über die tatsächliche Rückroll-Leistung fehlt eine datierte Reihe: Anzahl versuchter Transaktionen, unvollständige Gerätewechsel und erfolgreiche Rücknahmen. Die Folien belegen Konstruktion und vom Betreiber genannte Größe. Ihre stärkste Aussage ist die Zuständigkeitsgrenze. Das Schreiben hat Prüfungen und ein Protokoll, ein manueller Eingriff hinterlässt eine Spur, die KI bleibt Leser. Wer diese Grenzen später verschiebt, muss den Beleg für jeden Schritt mitverschieben.

Quellen: RIPE-93-Vortrag; Originalfolien von InterLAN Lighthouse; RIS-Sammlerübersicht der RIPE NCC.