Zusammenfassung

  • InterLAN IX beschreibt für Lighthouse ein Mitgliederportal, in dem eine Änderung mehrere Router erreichen kann. Für jedes Gerät gibt es eine Vorschau, einen Rücksetz-Timer und eine eigene Bestätigung; wenn sichere Wiederherstellung nicht belegbar ist, übernimmt ein Mensch.
  • Die Datenbank verwaltet den beabsichtigten Zustand. Manuelle Geräteeingriffe erscheinen als Abweichung, und der KI-Assistent darf nur lesen und Berichte schreiben. Ein Klick ist ein Antrag, kein Eigentumstitel am gemeinsamen Netz.

Der erste Router sagt Ja. Was sagt der zweite?

Selbstbedienung ist leicht zu verkaufen. Ein Mitglied stellt eine Anfrage, das Portal zeigt ein grünes Häkchen, und ein Techniker muss nicht mehr jede Kleinigkeit von Hand übertragen. In einem Internetknoten hat die bequeme Oberfläche allerdings eine harte Rückseite: Eine Anfrage kann mehrere Geräte betreffen. Zwischen der ersten und der letzten Bestätigung existiert ein Zwischenzustand. Andere Teilnehmer nutzen die Infrastruktur währenddessen weiter.

Genau diesem Zwischenraum widmet sich die Zusammenfassung des InterLAN-IX-Vortrags auf RIPE 93. Andrei Dinu beschreibt Lighthouse für ein Netz mit Nokia-SR-OS-Routern und Arista-EOS-Switches. Jedes betroffene Gerät soll eine Vorschau seiner Konfiguration, einen eigenen Timer für die Rücknahme und eine gesonderte Bestätigung erhalten. Kann die Software eine sichere Wiederherstellung nicht nachweisen, übernimmt ein Mensch. Auf der Konferenzseite stehen derzeit weder Transkript noch Folien oder Aufzeichnung; Betriebszahlen, Fehlversuche und Rücksetzprotokolle fehlen ebenfalls. Veröffentlicht ist ein Entscheidungsdesign, keine Erfolgsbilanz.

InterLAN selbst bietet öffentliches Peering über zwei Route-Server, private VLANs und Ersatzports an. Diese Dienste nutzen eine gemeinsame Plattform. Welche einzelnen Bestellarten Lighthouse bereits abdeckt, ist öffentlich nicht aufgeführt. Für die Governance-Frage reicht die Struktur: Ein Teilnehmer kennt sein gewünschtes Ergebnis; der Betreiber muss die Auswirkungen einer Änderung auf seine geteilten Geräte beherrschen. Wenn Router eins umgestellt wird und Router zwei ausfällt, hilft die hübsche Oberfläche den übrigen Mitgliedern wenig.

Ein Timer kann ein Gerät zurücksetzen. Er ist keine Zeitmaschine für die Minuten, in denen das Netz teilweise umgestellt war. Die Einzelbestätigung macht den Zustand sichtbar; der menschliche Eingriff bei unbewiesener Rückkehr verteilt Verantwortung dorthin, wo Entscheidungen getroffen werden können. Der Satz „Die Automatisierung hat es erledigt“ klingt im Rückblick besonders schwach, wenn niemand sagen kann, wer bei einem Fehler das Steuer übernimmt.

Die Datenbank schreibt das verbindliche Protokoll

Der scheinbar langweiligste Teil von Lighthouse trägt das größte Gewicht: Die Datenbank hält den beabsichtigten Zustand. Direkt am Gerät vorgenommene Änderungen werden als Abweichung markiert und nicht stillschweigend zum neuen Soll erklärt. Eine dringende Reparatur um Mitternacht kann richtig sein, ohne morgens als dauerhafte Regel zu gelten. Wer Soll und Ist vermischt, kann einen Fehler nicht mehr sauber von einer bewussten Ausnahme unterscheiden.

Heng Lus Note 73 fragt nach dem Abstand zwischen Mitmachen und Mandat. Im Maschinenraum ist diese Frage messbar. Das Mitglied darf beantragen. Der Betreiber genehmigt den Zustand der gemeinsamen Infrastruktur. Ein Ingenieur darf im Ernstfall eingreifen. Eine belastbare Datenbank sollte dokumentieren, welche Handlung zur dauerhaft autorisierten Konfiguration wurde. Das Self-Service-Portal verteilt keinen Blankoscheck, nur weil es freundlich aussieht.

Lighthouse soll Änderungen an einem digitalen Zwilling proben, der aus Produktions-Snapshots gebaut wird. Entscheidend sind dessen Zeitstempel, die erfassten Abweichungen und die Verbindung zwischen Probe und Freigabe. Ein öffentlicher Beispieldatensatz dafür liegt nicht vor. Ein guter Nachweis würde eine reale Anfrage von der Vorschau über Probe und Einzelbestätigungen bis zum eventuellen Rücksetzen verfolgen. Das ist weniger fotogen als eine animierte Netzkarte und erheblich nützlicher.

Der KI-Assistent hat laut Vortragsseite nur lesende Werkzeuge. Er schreibt Berichte und Migrationspläne, aber keine Konfiguration. Auch ein sprachlich glänzender Vorschlag muss sich die technische Freigabe erst verdienen. Die FAQ von InterLAN zieht eine weitere Linie: BGP-Sitzungen zu den Route-Servern sind freiwillig, jedes Mitglied wählt seine Peering-Politik selbst. Der Knoten betreibt das gemeinsame Gewebe; die Teilnehmer entscheiden ihre eigenen Peering-Beziehungen. Der RIPE-NCC-RIS-Kollektor RRC22 sitzt bei InterLAN-IX in Bukarest und beobachtet BGP-Daten. Solche Beobachtungen zeigen mögliche Auswirkungen, nicht den internen Genehmigungsweg einer Konfigurationsänderung.