Die LON2-Störungen von LINX 2023 machten den laufenden Netzzustand zur Rechenschaftsfrage

Zusammenfassung

Nach Angaben von LINX fiel am 20. Juni 2023 eine Dark-Fibre-Verbindung in LON2 aus. Der erste Ausfall beeinträchtigte Mitglieder dem veröffentlichten Bericht zufolge nicht unmittelbar, verringerte jedoch die verfügbare Redundanz. Damit befand sich das Netz schon vor den folgenden Symptomen in einem anderen Risikozustand. [1]
Am 21. Juni beobachtete LINX Flowmon-Drops, flappende Inter-Switch-Links, Verkehrsverluste und Erreichbarkeitsprobleme im LON2-Peering-LAN. Links wurden zur Wiederherstellung deaktiviert; später diente auch die Abschaltung einer Link-Aggregation zwischen Kerngeräten als Workaround. [1]
Für verbliebene Erreichbarkeitsfälle am 22. Juni meldete LINX MAC-Adressen, die in der Software-MAC-Tabelle eines Edge-Geräts vorhanden waren, jedoch nicht in dessen Hardwaretabelle. Das Zurücksetzen der L2VPN-EVPN-BGP-Sitzung zwischen betroffenen VTEPs füllte die Hardwaretabelle erneut. [1]
LINX führte einen Auslöser auf einen neu installierten, zuvor im Labor verwendeten Router zurück. Die alte OSPF- und Router-ID-Konfiguration war entfernt und eine neue Router-ID über NETCONF ausgerollt worden. Der laufende OSPF-Prozess verwendete die alte Identität dennoch weiter, weil der Prozess nicht bereinigt worden war. [1]
Die belastbare Lehre lautet nicht, dass OSPF, BGP, EVPN, VXLAN, Automatisierung oder disaggregierte Hardware grundsätzlich unsicher seien. Entscheidend ist das Zulassungs- und Nachweissystem: eindeutige Live-Identitäten, bereinigter Prozesszustand, repräsentative Tests, konsistente Kontroll- und Hardwaretabellen sowie nachgewiesene Erreichbarkeit.
Weitere Erreichbarkeitsprobleme am 29. Juni und sporadische Flow-Drops am 5. November nach Wartungsarbeiten an einer Dark-Fibre-Strecke dürfen nicht ohne zusätzliche Belege zu einer einzigen Universalursache zusammengezogen werden. LINX dokumentierte auch eine zurückgenommene Softwareänderung und eine fortdauernde Untersuchung durch einen Anbieter. [1]
Der Jahresbericht nennt für LON2 eine Verfügbarkeit von 99,997 Prozent und damit einen Wert unter dem internen Ziel von 99,998 Prozent. Diese Kennzahl bestätigt die betriebliche Relevanz der Störungen, bestimmt aber weder die Betroffenheit einzelner Mitglieder noch genaue Verkehrs-, Umsatz- oder Schadenssummen. [2]
Rechenschaftspflicht orientiert sich am laufenden Netz. Beabsichtigte Konfiguration, erfolgreicher Automatisierungslauf und Jahresverfügbarkeit sind wichtige Aufzeichnungen. Sie ersetzen jedoch nicht den Nachweis, dass Identitäten tatsächlich eindeutig sind, EVPN-Zustände mit der Hardwareweiterleitung übereinstimmen und Pakete über die vorgesehenen Pfade ihr Ziel erreichen.

Eine Störung, die zunächst die Sicherheitsmarge verringerte

Die öffentlich dokumentierte Sequenz begann am 20. Juni 2023 mit dem Ausfall einer Dark-Fibre-Verbindung in LON2. LINX erklärte, dass dieser erste Fehler keine unmittelbare Auswirkung auf Mitglieder gehabt habe. Er habe aber die Resilienz der Plattform verringert. [1] Diese Unterscheidung ist für die technische Bewertung wesentlich: Ein redundantes System kann nach dem Verlust eines Pfades weiterhin Verkehr transportieren und trotzdem bereits in einen deutlich riskanteren Betriebszustand gewechselt sein.

Solange beide vorgesehenen Pfade verfügbar sind, kann ein einzelner zusätzlicher Fehler möglicherweise lokal bleiben. Nach dem Verlust eines Pfades verändern sich dagegen Fehlerbudget, Wartungsspielraum und Wirkung nachfolgender Topologieänderungen. Das Netz arbeitet nicht mehr unter den Annahmen, die ein Diagramm des Normalzustands vermittelt. Die verbleibenden Inter-Switch-Links, Link-Aggregationen, Router und Tunnelendpunkte tragen nun eine andere Last und bilden eine andere Abhängigkeitsstruktur.

Am 21. Juni berichtete LINX über von Flowmon angezeigte Drops und flappende Inter-Switch-Links. Danach traten Verkehrsverlust und Erreichbarkeitsprobleme im LON2-LAN auf. Techniker deaktivierten Links, um den Dienst teilweise wiederherzustellen. Eine Link-Aggregation zwischen Kerngeräten wurde anschließend als Workaround abgeschaltet, um eine weitergehende Wiederherstellung zu erreichen. [1] Diese Chronologie verbindet physische Pfadresilienz, Topologieveränderungen und logische Weiterleitungszustände, ohne zu beweisen, dass eine einzige Komponente sämtliche Symptome verursacht hat.

Am 22. Juni war die breite Störung nach Darstellung von LINX eingegrenzt, doch für bestimmte IP-Adressen bestanden weiterhin Erreichbarkeitsprobleme. In diesen Fällen erschienen MAC-Adressen in der Software-MAC-Tabelle eines Edge-Geräts, fehlten jedoch in der Hardwaretabelle. LINX setzte die L2VPN-EVPN-BGP-Sitzung zwischen den betroffenen VTEPs zurück; dadurch wurde die Hardwaretabelle erneut befüllt. [1]

Dieser Befund zeigt, warum die Störung nicht mit der Feststellung „Faser repariert“ oder „BGP-Sitzung steht“ abgeschlossen werden konnte. Jeder einzelne Kontrollpunkt konnte plausibel aussehen, während Pakete weiterhin scheiterten. Ein Automatisierungssystem konnte einen erfolgreichen Konfigurationslauf melden. Eine Softwaretabelle konnte eine MAC-Adresse führen. Eine Sitzung konnte etabliert sein. Dennoch fehlte der Eintrag an jener Stelle, an der die Hardware die tatsächliche Paketentscheidung traf.

Der erste Faserfehler gehört deshalb auch dann zur Rechenschaftsanalyse, wenn er nach Angaben von LINX zunächst keine Mitglieder beeinträchtigte. Er veränderte den Betriebsrahmen für alles, was danach geschah. Eine Organisation, die eine solche Meldung lediglich als komponentenbezogenen Alarm schließt, weil der Verkehr noch fließt, übersieht die verringerte Reserve. Der nächste routinemäßige Eingriff findet dann nicht mehr im vorgesehenen Normalzustand statt.

Eine belastbare Betriebsführung muss den degradierten Zustand explizit machen. Er sollte in der Quelle der betrieblichen Wahrheit, im Change-System und in der aktuellen Topologie sichtbar sein. Geplante Aktivierungen müssen gegen den realen Zustand bewertet werden, nicht gegen die nominelle Architektur. Der öffentliche Bericht legt nicht offen, welche konkreten Freigabeentscheidungen LINX damals traf. Daraus dürfen weder ein verborgenes Versäumnis noch eine bestimmte interne Entscheidung konstruiert werden. Ableitbar ist allein, welche Nachweise ein Betreiber in einer vergleichbaren Situation benötigen würde.

Redundanz ist ein geprüfter Zustand, kein Etikett

Netzpläne stellen Redundanz häufig als doppelte Linie dar. Für den Betrieb zählt jedoch nicht, wie viele Linien gezeichnet sind, sondern ob die alternativen Pfade technisch unabhängig, ausreichend dimensioniert, richtig konfiguriert und unter den maßgeblichen Fehlerbedingungen getestet sind. Ein vorhandener Ersatzpfad kann denselben Wartungsbereich, dieselbe Aggregation, denselben Kontrollprozess oder eine unerwartete gemeinsame Fehlerdomäne teilen.

Die LINX-Architekturmaterialien beschreiben LON2 als moderne, standortübergreifende Exchange-Infrastruktur und erläutern den Einsatz eines disaggregierten EVPN-over-VXLAN-Modells. [3][4][5] Solche Designs trennen die physische beziehungsweise IP-basierte Underlay-Erreichbarkeit von der Verteilung logischer Erreichbarkeitsinformationen im Overlay. Diese Trennung ermöglicht Skalierbarkeit und kontrolliertere Weiterleitung, erhöht aber zugleich die Zahl der Zustände, die ein Betreiber für einen vollständigen Nachweis miteinander abgleichen muss.

Nach dem Verlust einer Dark-Fibre-Verbindung musste die verbliebene Topologie daher mehr beweisen als bloße elektrische Link-Verfügbarkeit. Zu prüfen waren die Erreichbarkeit zwischen VTEPs, das Verhalten der Inter-Switch-Links, die Link-Aggregation, die Verteilung der EVPN-Informationen und die Programmierung der Weiterleitungshardware. Ein Pfad, der im Normalzustand nur selten oder unter anderer Last genutzt wird, ist nicht allein durch seine Existenz qualifiziert.

Für die Change-Steuerung folgt daraus eine abgestufte Betriebsart. Bei vollständiger Redundanz kann eine Änderung innerhalb des regulären Freigaberahmens liegen. Bei bereits eingeschränkter Pfadvielfalt sollte dasselbe Vorhaben höhere Anforderungen auslösen: kleinerer Änderungsumfang, repräsentativer Canary, strengere Abbruchkriterien, engeres Monitoring und eine vorab geklärte Rollback-Verantwortung. Gegebenenfalls ist eine nicht notwendige Aktivierung zu verschieben.

Wichtig ist, diese Regel nicht nachträglich als Schuldzuweisung zu formulieren. Der öffentliche Datensatz sagt nicht, ob eine Verschiebung möglich gewesen wäre oder welche Dringlichkeit die Routerinstallation hatte. Er zeigt aber, dass die Reihenfolge von Pfadverlust, Topologieproblemen und Weiterleitungsinkonsistenz betrieblich relevant war. Das reicht aus, um einen allgemeinen Kontrollstandard zu begründen.

Die Redundanzprüfung muss auch die tatsächliche Paketebene einbeziehen. Ein Failover-Test, der lediglich eine Management-Adresse erreicht, sagt wenig über den Pfad eines Mitglieds über Leaf, VTEP, EVPN-Zustand und Hardwaretabelle aus. Die Teststrecke muss dieselben Kontroll- und Weiterleitungselemente durchlaufen, die im Fehlerfall den produktiven Verkehr tragen sollen.

Ein belastbarer Nachweis enthält daher nicht nur „Pfad B verfügbar“, sondern die genaue Fehlerannahme, den aktivierten Ersatzpfad, die beobachtete Konvergenz, die relevanten Tabellenzustände, Paketproben und die verbleibenden Einschränkungen. Erst diese Kombination macht aus einer Redundanzbehauptung eine betriebliche Tatsache.

Die Grenze zwischen Labor und Produktion

Die technisch folgenreichste Veröffentlichung von LINX betrifft einen neu installierten Router, der zuvor in einem Labor eingesetzt worden war. Nach Angaben des Betreibers hatte das Gerät ursprünglich dieselbe Router-ID wie ein bereits produktiver Router. Die alte OSPF- und Router-ID-Konfiguration wurde entfernt. Eine neue Router-ID wurde über NETCONF ausgerollt. Der laufende OSPF-Prozess verwendete die alte Identität trotzdem weiter, weil der Prozess nicht bereinigt worden war. [1]

Dieser Ablauf trennt Konfigurationsabsicht von Laufzeitzustand. Eine Konfigurationsdatenbank kann den gewünschten Wert zeigen. Ein Versionsverwaltungssystem kann die korrekte Änderung enthalten. NETCONF kann die neuen Bytes erfolgreich übertragen. Keine dieser Aufzeichnungen beweist für sich genommen, dass ein bereits laufender Protokollprozess alle aus dem alten Zustand abgeleiteten Informationen verworfen hat.

Laborumgebungen sind bewusst auf Wiederverwendung ausgelegt. Geräte wechseln Rollen, Topologien, Identitäten, Softwarestände und Nachbarschaften. Diese Flexibilität ist für Tests wertvoll. Sie bedeutet aber auch, dass ein Laborgerät bei der Produktionsaufnahme zunächst als Träger potenziell fremden Zustands behandelt werden sollte. Sichtbare Konfiguration ist nur eine von mehreren Zustandsschichten.

Abhängig von Plattform und Funktion können Startkonfigurationen, Prozessspeicher, Routing- und Nachbarschaftsdaten, Forwarding-Caches, Bridge-Domains, VTEP-Zuordnungen, Zugangsdaten, Zertifikate, Test-VLANs oder unterschiedliche Softwareabbilder fortbestehen. Der LINX-Bericht belegt nicht, dass alle diese Formen von Restzustand vorhanden waren. Er belegt einen bestimmten Fall: Die laufende OSPF-Identität entsprach nicht der beabsichtigten neuen Identität.

Daraus folgt ein präziser Kontrollgrundsatz. Der Übergang darf nicht als Dateikopie, sondern muss als Zustandsüberführung definiert werden. Für jeden relevanten Prozess ist festzulegen, welche Aktion die alte Laufzeitinformation zuverlässig entfernt: Prozess-Clear, Neustart, vollständiger Reboot, Neubau aus einem bekannten Image oder eine plattformspezifische andere Prozedur. Anschließend müssen messbare Postconditions erfüllt sein.

Diese Postconditions sollten sowohl lokal als auch aus Sicht der Umgebung geprüft werden. Der Kandidat kann seine Router-ID ausgeben, doch auch seine Nachbarn müssen bestätigen, welche Identität sie tatsächlich sehen. Der lokale EVPN-Prozess kann erwartete Routen anzeigen, doch die Gegenstellen müssen die richtige Herkunft und die Hardware muss die entsprechenden Weiterleitungseinträge zeigen. Eine Produktionsaufnahme auf Grundlage ausschließlich lokaler Selbstauskunft wäre zu schwach.

Der Begriff „bereinigt“ muss folglich in überprüfbare Aussagen zerlegt werden. Er kann bedeuten, dass keine alte Router-ID aktiv ist, keine unerwartete Adjazenz besteht, keine Labor-VTEP-Adresse auftaucht, keine unzulässige Bridge-Domain vorhanden ist und kein relevanter Eintrag nur im Softwaremodell existiert. Erst wenn die Negativ- und Positivtests abgeschlossen sind, ist der Übergang nachweisbar.

Automatisierung bleibt dabei ein entscheidender Vorteil. Die Lehre lautet nicht, Automatisierung durch manuelle Kommandos zu ersetzen. Ein konsistenter Automatisierungslauf ist nur dann vollständig, wenn er den Erfolg anhand des laufenden Netzes bewertet. Die Pipeline muss nicht allein fragen, ob eine Konfiguration akzeptiert wurde, sondern ob der Prozess die neue Identität verwendet, die Nachbarn sie beobachten und die Paketweiterleitung dem Zielzustand entspricht.

OSPF-Identität als betriebliche Ressource

OSPF verwendet eine Router-ID zur eindeutigen Identifikation eines Routers innerhalb der Routingdomäne. RFC 2328 beschreibt sie als 32-Bit-Wert, der den Router im autonomen System eindeutig identifizieren soll. [11] Diese Identität ist keine dekorative Inventarinformation. Sie ist Teil der Logik, mit der Link-State-Informationen einem Ursprung zugeordnet und zu einer konsistenten Topologiesicht verarbeitet werden.

Doppelte Router-IDs können die Zuordnung zwischen einem Router und den von ihm erzeugten Link-State-Informationen beeinträchtigen. Herstellerdokumentation ordnet doppelte IGP-Identitäten als kritische Anomalie ein und unterstreicht die Notwendigkeit eindeutiger Werte. [18] Diese allgemeine Protokoll- und Betriebsaussage darf jedoch nicht in eine Herstellerzuordnung für den LINX-Vorfall umgedeutet werden. Der öffentliche Bericht nennt nicht ausreichend belastbar einen bestimmten Geräte- oder Softwareanbieter als Ursache.

Die Rechenschaftsfrage lautet daher nicht nur: „Welche Router-ID stand in der Konfiguration?“ Sie lautet: „Welche Identität verwendete der laufende OSPF-Prozess, und welche Identität sahen die übrigen Router?“ Dieser Unterschied ist der Kern des Vorfalls. Ein Inventar kann einen eindeutigen Wert reservieren, während ein Prozess weiterhin einen früheren Wert verwendet.

Netzidentitäten sind knappe operative Ressourcen, auch wenn sie technisch leicht erzeugbar erscheinen. Router-IDs, AS-Nummern, VTEP-Adressen, Peering-LAN-Adressen, Route Distinguisher, MAC-Adressen und andere Kennungen erfüllen unterschiedliche Aufgaben. Gemeinsam ist ihnen, dass Fehler bei Vergabe, Eindeutigkeit oder Zuordnung die Fähigkeit des Netzes beeinträchtigen können, Herkunft und Ziel korrekt zu bestimmen.

Eine Registry, ein IPAM-System oder eine Source-of-Truth-Datenbank ist dafür ein notwendiges Hauptbuch. Sie dokumentiert, welcher Wert vorgesehen ist und welchem Objekt er gehört. Sie ist aber nicht souverän über den laufenden Code. Wenn ein Prozess einen anderen Wert verwendet, gewinnt für die Paketrealität zunächst der Prozesszustand. Das Hauptbuch wird erst dann betrieblich belastbar, wenn es regelmäßig mit Beobachtungen aus dem Netz abgeglichen wird.

Ein angemessener Zulassungstest benötigt deshalb mindestens drei Perspektiven. Erstens den beabsichtigten Wert aus der kontrollierten Quelle. Zweitens den Live-Wert des Kandidatengeräts. Drittens die von den Nachbarn und Überwachungssystemen beobachtete Identität. Ein Widerspruch zwischen diesen Perspektiven stoppt die Aktivierung.

Der Test sollte außerdem domänenweit nach Duplikaten suchen. Es reicht nicht, den neuen Wert mit einer lokalen Geräteliste zu vergleichen, wenn andere Systeme denselben Wert bereits verwenden oder ein alter Prozesszustand fortbesteht. Der negative Nachweis „keine zweite aktive Instanz dieser Identität“ ist genauso wichtig wie der positive Nachweis „der neue Router meldet den richtigen Wert“.

Wird eine Router-ID geändert, gehört auch die notwendige Prozessaktion in den Datensatz. Der Change-Nachweis sollte festhalten, ob ein Clear, Neustart oder Reboot erforderlich war, wann er erfolgte, welche Adjazenzen neu aufgebaut wurden und ob die Identität danach auf beiden Seiten übereinstimmte. Ohne diesen Schritt bleibt die Konfigurationsänderung lediglich eine Absichtserklärung.

EVPN und VXLAN: Mehrere Wahrheiten müssen übereinstimmen

LON2 wurde von LINX als EVPN-over-VXLAN-Umgebung beschrieben. [3][4] Vereinfacht ausgedrückt kapselt VXLAN Ethernet-Verkehr über ein IP-Underlay zwischen Tunnelendpunkten. RFC 7348 beschreibt diesen Mechanismus. [13] EVPN verwendet BGP, um Erreichbarkeitsinformationen für das Overlay zu verteilen; die einschlägigen Grundlagen und der Einsatz in Netzwerkvirtualisierungs-Overlays werden in RFC 7432 und RFC 8365 erläutert. [14][15]

Die Trennung ist architektonisch sinnvoll. Das Underlay stellt IP-Erreichbarkeit zwischen VTEPs bereit. Der EVPN-Kontrollplan verteilt Informationen darüber, wo MAC- oder IP-Ziele erreichbar sind. Die Geräte programmieren daraus schließlich die Weiterleitungsebene. Für den Operator entstehen dadurch mehrere miteinander verbundene Wahrheiten: beabsichtigte Konfiguration, Protokollzustand, Softwaretabellen, Hardwaretabellen und beobachtetes Paketverhalten.

Ein Fehler muss nicht alle diese Ansichten gleichzeitig verfälschen. Genau darin liegt die Schwierigkeit selektiver Störungen. Die Managementebene kann erreichbar sein. Das Underlay kann einen VTEP erreichen. BGP kann eine etablierte Sitzung melden. Eine MAC-Adresse kann in der Softwaretabelle erscheinen. Trotzdem kann ein Paket scheitern, wenn der entsprechende Eintrag nicht in die Hardware programmiert wurde.

Der von LINX beschriebene Unterschied zwischen Software-MAC-Tabelle und Hardwaretabelle ist daher mehr als ein Implementierungsdetail. Er zeigt, dass eine Kontrollansicht keinen vollständigen Weiterleitungsnachweis lieferte. Erst die Beobachtung der Hardwaretabelle und der tatsächlichen Erreichbarkeit machte die Abweichung sichtbar. Das Zurücksetzen der L2VPN-EVPN-BGP-Sitzung füllte die Hardwaretabelle für die beschriebenen Restfälle erneut. [1]

Diese Beobachtung beweist keinen allgemeinen EVPN-Fehler. Sie belegt weder, dass BGP falsche Informationen verteilt habe, noch dass jeder fehlende Hardwareeintrag dieselbe Ursache hatte. Sie begründet eine engere und belastbarere Aussage: In diesem Vorfall reichte das Vorhandensein eines Softwareeintrags nicht aus, um die Paketweiterleitung zu bestätigen.

RFC 9062 ist für diesen Rechenschaftsrahmen relevant, weil es Anforderungen an Betrieb, Administration und Wartung von EVPN beschreibt und Mechanismen zur Prüfung von Verbindungen sowie zum Abgleich von Kontroll- und Datenebene behandelt. [17] Das Dokument identifiziert keinen LINX-spezifischen Defekt. Es zeigt jedoch, welche Art von Betriebsnachweis eine EVPN-Umgebung benötigt.

Für einen Internetknoten ist diese Prüfung besonders wichtig. Ein Peering-LAN ist eine gemeinsame Plattform, über die unabhängige autonome Systeme bilaterale Sitzungen oder Route-Server-Dienste nutzen. LINX beschreibt entsprechende Peering- und Route-Server-Angebote öffentlich. [7][8][9] Der Exchange kontrolliert nicht die Routingpolitik jedes Mitglieds, wohl aber das Fabric, das deren Pakete zwischen Ports transportiert.

Eine Inkonsistenz kann deshalb selektiv sichtbar werden. Einige Ziele oder Pfade funktionieren, andere nicht. Gesamtverkehr, Sitzungssummen und zentrale Ampeln können weitgehend normal aussehen. Ein Betreiber braucht Messungen auf der Granularität, auf der der Fehler auftreten kann: ausgewählte MAC- und IP-Einträge, relevante Leaf-Paare, VTEPs, Bridge-Domains und repräsentative Mitgliederpfade.

Die Beweisführung sollte mehrere Ebenen miteinander verbinden. Eine erwartete EVPN-Route muss im Kontrollplan sichtbar sein. Der zugehörige Eintrag muss in der Software- und Hardwareansicht übereinstimmen. Ein Pakettest muss den geplanten Pfad erfolgreich durchlaufen. Diese drei Nachweise sind nicht austauschbar. Erst zusammen belegen sie, dass die verteilte Information in tatsächliche Weiterleitung umgesetzt wurde.

Der laufende Prozess ist maßgeblich

Der LINX-Fall führt zu einem nüchternen Grundsatz: Für den Betrieb ist die wirksame Realität des laufenden Codes maßgeblich. Konfiguration, Inventar und Automatisierungsprotokoll bleiben wichtig, doch sie beschreiben zunächst eine beabsichtigte oder aufgezeichnete Wirklichkeit. Pakete folgen dem Zustand, den Prozesse und Hardware tatsächlich anwenden.

Dieser Grundsatz ist weder technikfeindlich noch gegen Governance gerichtet. Im Gegenteil: Er macht Governance überprüfbar. Eine Source of Truth gewinnt nicht dadurch an Autorität, dass sie als verbindlich bezeichnet wird. Sie gewinnt, wenn ihre Aussagen mit dem laufenden Netz versöhnt werden und Abweichungen eine klare Reaktion auslösen.

Im konkreten Fall konnte die neue Router-ID korrekt dokumentiert und ausgerollt sein, während der OSPF-Prozess noch die alte Identität verwendete. Ebenso konnte eine MAC-Adresse in der Softwareansicht vorhanden sein, während die Hardware nicht entsprechend weiterleitete. Beide Beispiele zeigen eine Lücke zwischen einem plausiblen Datensatz und dem operativen Ergebnis.

Eine kontrollierte Produktionsaufnahme sollte diese Lücke systematisch schließen. Für jeden kritischen Sollwert wird eine beobachtbare Postcondition definiert. Die Identität muss lokal und aus Nachbarsicht stimmen. Die erwarteten Routen und MAC-Informationen müssen im Kontrollplan vorhanden sein. Die Hardware muss die nötigen Einträge enthalten. Der relevante Verkehr muss den Pfad erfolgreich nutzen.

Der Nachweis braucht außerdem Zeitbezug. Ein Snapshot unmittelbar nach dem Deployment kann später durch erneute Konvergenz, Prozesszustände oder Topologieänderungen überholt sein. Daher sollte die Abnahme eine stabile Beobachtungsperiode enthalten und die Messungen mit der Änderung, dem Prozessneustart und den Pakettests auf einer gemeinsamen Zeitachse verbinden.

Auch ein Neustart ist kein Selbstzweck. Er kann Zustand bereinigen, beweist aber nicht automatisch, welcher Zustand entfernt wurde oder ob die gewünschte Wirkung dauerhaft ist. Ein verantwortbarer Datensatz erklärt, welche Hypothese mit dem Neustart geprüft wurde, welche Messung sich danach ändern sollte und ob diese Änderung tatsächlich eintrat.

Das Ziel ist kein perfektes, allwissendes Kontrollsystem. Es ist ein nachprüfbarer Zusammenhang zwischen Entscheidung und Wirkung. Wenn der Betreiber einen Router freigibt, muss er zeigen können, auf welcher Live-Beobachtung die Freigabe beruhte. Wenn ein Workaround die Erreichbarkeit wiederherstellt, muss er festhalten, welche Symptome verschwanden und welche noch offenblieben.

Warum der 29. Juni und der 5. November getrennt bleiben müssen

Der Technologiebericht von LINX dokumentiert neben der Sequenz vom 20. bis 22. Juni weitere Ereignisse. Am 29. Juni traten erneut Erreichbarkeitsprobleme auf. Am 5. November wurden nach Wartungsarbeiten eines Anbieters an Dark Fibre sporadische Flow-Drops beobachtet. LINX berichtete zudem über eine Softwareänderung, die das Verhalten der Hardware-MAC-Tabelle adressieren sollte, über deren Rücknahme nach der Novemberstörung und über eine fortgesetzte Untersuchung durch einen Anbieter. [1]

Diese Angaben erhöhen die Bedeutung dauerhafter Kontrollen. Sie erlauben aber nicht, alle Episoden einer einzigen bewiesenen Ursache zuzuordnen. Ähnliche äußere Symptome können aus unterschiedlichen Kombinationen physischer, protokollbezogener und hardwarebezogener Zustände entstehen. „Erreichbarkeit gestört“ ist eine Wirkungskategorie, keine vollständige Ursachenanalyse.

Die verbliebene OSPF-Identität im Juni ist ein spezifischer Befund. Die Abweichung zwischen Software- und Hardware-MAC-Tabelle ist ein weiterer spezifischer Befund. Die Novemberchronologie enthält Wartungsarbeiten, eine Softwareänderung, einen Rollback und eine laufende Untersuchung. Zwischen diesen Elementen dürfen nur jene Verbindungen behauptet werden, die LINX selbst öffentlich herstellt oder die durch zusätzliche technische Beweise gestützt sind.

Im Störungsbetrieb werden häufig mehrere Maßnahmen in kurzer Folge ausgeführt. Sitzungen werden zurückgesetzt, Links deaktiviert, Geräte neu gestartet, Softwarestände geändert oder Pfade umgeschaltet. Wenn der Dienst danach wieder funktioniert, ist nicht automatisch klar, welche Maßnahme entscheidend war. Wiederherstellung und Ursachenisolierung sind verwandte, aber unterschiedliche Aufgaben.

Der Ereignisdatensatz sollte deshalb jede Maßnahme mit einer Hypothese verbinden. Was sollte sich durch den Clear der EVPN-Sitzung ändern? Welche Tabelle wurde davor und danach geprüft? Was sollte der Routerneustart bereinigen? Welche Beobachtung begründete die Softwareänderung? Welche Symptome blieben nach dem Rollback bestehen? Diese Zuordnung verhindert, dass ein erfolgreicher Reset später als Beweis für eine nicht belegte Universalursache behandelt wird.

Die öffentliche Sprache muss denselben Standard einhalten. Ein Anbieter, der weiter untersucht, ist ein Hinweis auf offene technische Arbeit, kein Nachweis rechtlicher oder alleiniger Verantwortung. Eine zurückgenommene Softwareänderung ist ein wichtiges Indiz, aber kein Beweis, dass sie sämtliche Störungen verursacht hat. Präzise Unsicherheit schützt nicht nur vor Übertreibung; sie verbessert auch die technische Lernfähigkeit.

Verfügbarkeit von 99,997 Prozent ist nur der Einstieg

Der LINX-Jahresbericht für 2023 gibt für LON2 eine Verfügbarkeit von 99,997 Prozent an. Der Wert lag unter dem internen Ziel von 99,998 Prozent; der Bericht führt die Abweichung auf mehrere Ausfälle zurück. [2] Auf den ersten Blick ist der Abstand klein. Für die betriebliche Bewertung zählt jedoch, welche Dienstdefinition, Messpunkte und Intervalle hinter der Kennzahl stehen.

Eine aggregierte Prozentzahl kann die Gesamtleistung eines Dienstes zusammenfassen. Sie kann nicht allein zeigen, welche Mitglieder, Ports, VLANs, Adressen oder Sitzungen betroffen waren. Sie zeigt auch nicht, ob Erreichbarkeit symmetrisch war oder ob eine kleinere Gruppe länger beeinträchtigt blieb als der überwiegende Teil des Netzes.

Selektive Weiterleitungsfehler sind besonders anfällig dafür, in einer Gesamtsicht zu verschwinden. Wenn ein Großteil des Verkehrs fließt, kann der aggregierte Durchsatz stabil wirken. Wenn die meisten MAC-Einträge korrekt programmiert sind, kann eine zentrale Zustandsanzeige grün bleiben. Bestimmte Ziele können dennoch unerreichbar sein.

Zu einem belastbaren Verfügbarkeitsnachweis gehören deshalb Messdefinitionen. Der Betreiber muss intern wissen, welche Grundgesamtheit betrachtet wird, wie Wartungsfenster behandelt werden, welche Vantage Points eingesetzt sind und wann eine Probe als Ausfall gilt. Eine portbasierte Messung kann einen elektrisch aktiven, aber logisch unbrauchbaren Pfad übersehen. Eine verkehrsbasierte Messung kann kleine betroffene Gruppen verdünnen.

Für ein EVPN-Peering-Fabric sollten mehrere Signale zusammenlaufen: Mitglieder- oder repräsentative Edge-Probes, Route-Server-Erreichbarkeit, bilaterale Pfade, Overlay-Checks, MAC- und Hardwaretabellen sowie Ereignisse aus dem Underlay. Keines dieser Signale bildet allein den gesamten Dienst ab. Ihre Korrelation ermöglicht aber eine nachvollziehbare Erklärung, warum ein Vorfall in die Kennzahl einging.

Das verlangt nicht die Veröffentlichung privater Topologie- oder Mitgliederdaten. Sicherheits- und Vertraulichkeitsgründe können eine beschränkte Aufbewahrung rechtfertigen. Öffentlich sollte die Aussage dennoch auf einer ausreichend starken internen Beweiskette beruhen: betroffene Dienstklasse, Messbereich, Zeitgrenze, Konfidenz und Status der Abhilfe.

Die von LINX veröffentlichten technischen Einzelheiten sind deshalb wertvoller als eine nackte Prozentzahl. Sie benennen beobachtete Zustände und Wiederherstellungsmaßnahmen. Die Lücken des öffentlichen Datensatzes bleiben zugleich real. Der Jahreswert darf nicht in eine erfundene Summe betroffener Mitglieder, verlorener Pakete oder finanzieller Schäden umgerechnet werden.

Change-Steuerung im degradierten Netz

Ein Netz mit verringerter Pfadredundanz sollte in einen ausdrücklich definierten Betriebsmodus wechseln. Der Dienst kann weiterhin verfügbar sein, doch die akzeptable Veränderungsfläche ist kleiner. Was im Normalzustand als begrenzte Änderung gilt, kann im degradierten Zustand eine kritische Abhängigkeit berühren.

Der erste Baustein ist maschinenlesbare Sichtbarkeit. Der Ausfall eines wichtigen Pfades sollte nicht nur in einem Incident-Chat stehen. Er muss im Change-System und in der aktuellen Topologiedarstellung erscheinen. Ein geplantes Deployment kann dann automatisch erkennen, dass es Komponenten betrifft, die momentan ohne die vorgesehene Reserve arbeiten.

Der zweite Baustein ist eine Abhängigkeitskarte. Dark Fibre, Inter-Switch-Link, Link-Aggregation, Core-Router, VTEP und EVPN-Sitzung können an demselben Ende-zu-Ende-Dienst beteiligt sein, obwohl verschiedene Teams oder Anbieter sie betreuen. Der Change-Datensatz muss zeigen, welche verbliebenen Komponenten den Verkehr tragen und welche Prüfung ihren Zustand bestätigt.

Der dritte Baustein ist ein repräsentativer Canary. Ein Test in einem vollständig gesunden Labor oder über einen nicht betroffenen Produktionspfad kann falsche Sicherheit erzeugen. Wenn der produktive Verkehr nach dem Ausfall einen bestimmten alternativen Link oder VTEP verwendet, muss der Canary genau diesen Weg und dieselbe Kontrolllogik nutzen.

Der vierte Baustein sind vorab festgelegte Abbruchbedingungen. Dazu können eine doppelte Router-ID, unerwartete Adjazenz, flappende Links, steigende Drops, ein Unterschied zwischen Software- und Hardwaretabelle oder fehlgeschlagene Edge-Probes gehören. Ein vordefiniertes Stoppsignal reduziert Diskussionen in einem bereits dynamischen Störungsfenster.

Der fünfte Baustein ist Rollback-Eigentümerschaft. Es muss klar sein, wer Links isolieren, eine Sitzung zurücksetzen, einen Prozess neu starten, ein Gerät entfernen oder eine Softwareänderung zurücknehmen darf. Eine technisch vorhandene Rückrollmöglichkeit ist wenig wert, wenn im Ereignisfall niemand eine eindeutige Entscheidungskompetenz besitzt.

Der sechste Baustein ist die erneute Qualifikation nach jeder wesentlichen Topologieänderung. Wenn ein Link deaktiviert oder eine Aggregation aufgelöst wird, sind frühere Testergebnisse möglicherweise nicht mehr repräsentativ. Der Betreiber muss die tatsächlich verbleibende Weiterleitungsstruktur erneut prüfen.

Keine dieser Anforderungen beweist, dass LINX sie nicht hatte. Sie sind abgeleitete Kontrollen für die in der Veröffentlichung sichtbare Fehlerklasse. Die Grenze zwischen Analyse und Anschuldigung bleibt klar: Aus bekannten Zustandsabweichungen lassen sich geeignete Nachweise ableiten, nicht aber unbekannte interne Prozesse rekonstruieren.

Was ein belastbarer Produktionsaufnahmedatensatz enthalten sollte

Ein nachvollziehbarer Aufnahmedatensatz beginnt vor dem Verlassen des Labors. Er identifiziert Gerät, Hardwarestand, Softwareabbild, Konfigurationsquelle, vorgesehene Rolle und alle produktiven Identitäten. Er dokumentiert, welche Bereinigung vorgenommen wurde und welcher persistente Zustand nach Plattformdesign erhalten bleiben darf.

Die Software- und Firmwarebasis sollte über überprüfbare Versionen oder Prüfsummen gebunden sein. Dasselbe gilt für die vorgesehene Konfiguration. Diese Artefakte beweisen den Ausgangspunkt, aber noch nicht den Live-Erfolg. Deshalb müssen die anschließenden Beobachtungen in denselben Datensatz einfließen.

Für OSPF gehören die vorgesehene Router-ID, der vom laufenden Prozess gemeldete Wert und die von Nachbarn beobachtete Identität zusammen. Eine domänenweite Duplikatprüfung ist erforderlich. Wenn der Wert geändert wurde, müssen notwendiger Clear, Prozessneustart oder Reboot und die danach neu aufgebauten Adjazenzen vermerkt werden.

Das Underlay braucht einen eigenen Nachweis. VTEP-Loopbacks müssen über die erwarteten Pfade erreichbar sein. Interfacezustand, Metriken, Link-Aggregationen und die aktive Topologie müssen dem vorgesehenen Betriebsbild entsprechen. Bei degradierter Glasfaserresilienz ist gerade der verbleibende Pfad zu prüfen, nicht ein theoretischer Normalpfad.

Danach folgt das Overlay. Der Router sollte die vorgesehenen EVPN-Informationen senden und empfangen. Route Targets, Bridge-Domains und VNI-Zuordnungen müssen mit der kontrollierten Quelle übereinstimmen. Unerwartete Informationen dürfen nicht als harmloser Laborrest abgetan werden, solange ihre Wirkung nicht ausgeschlossen ist.

Die Weiterleitungsabstimmung ist der entscheidende Schritt. Für ausgewählte MAC- und IP-Ziele müssen Software- und Hardwareansicht übereinstimmen, soweit die Plattform diese Einsicht ermöglicht. Reale Pakete müssen die betroffenen Leaf- und VTEP-Kombinationen erfolgreich passieren. Der LINX-Bericht zeigt ausdrücklich, warum eine Softwaretabelle allein kein ausreichender Beweis ist. [1]

Auch Negativtests gehören zum Datensatz. Es darf keine doppelte Router-ID, keine unerwartete Nachbarschaft, keinen alten Labor-VTEP, kein unfreigegebenes VLAN, kein unbekanntes Route Target und keinen nur in Software vorhandenen relevanten Weiterleitungseintrag geben. Solche Abwesenheitsnachweise sind schwieriger als einfache Erfolgsmeldungen, aber gerade dafür existiert eine Zulassungsschranke.

Monitoring muss vor der Verkehrsfreigabe an das neue Gerät gebunden sein. Flow-Telemetrie, Linkzustand, Protokollsitzungen, Hardwareprogrammierungsalarme und Edge-Probes brauchen klare Objektzuordnung. Ebenso wichtig sind Alarmverantwortung und Reaktionsweg. Ein Alarm ohne zuständigen Empfänger ist kein vollständiger Kontrollmechanismus.

Der Canary sollte begrenzt, aber architekturgleich sein. Er kann nur bestimmte Pfade oder einen kontrollierten Zeitraum betreffen. Er darf jedoch nicht jene EVPN-, VTEP-, Hardware- oder Ersatzpfadkomponenten umgehen, deren Verhalten geprüft werden soll. Ein einfacher Test über eine abweichende Strecke qualifiziert den produktiven Pfad nicht.

Der Abschluss vergleicht Soll- und Ist-Zustand. Konfigurationsprüfsummen, Live-Ausgaben, Nachbarsicht, Tabellenabgleich, Probeergebnisse, Telemetrie und Freigabeentscheidung werden zeitlich miteinander verbunden. Wurde eine Ausnahme akzeptiert, müssen Eigentümer, Gültigkeitsdauer und kompensierende Kontrolle feststehen.

Ein solcher Datensatz ist kein Selbstzweck. Er ermöglicht einer zweiten qualifizierten Person, die Freigabe nachzuvollziehen. Er erlaubt zudem, bei einer späteren Störung genau zu bestimmen, welcher Zustand vorlag und welche Annahmen tatsächlich geprüft worden waren.

Automatisierung muss Postconditions prüfen

Der Fall eignet sich nicht als Argument gegen NETCONF oder automatisierte Netze. Automatisierung reduziert manuelle Abweichungen, macht Änderungen reproduzierbarer und kann Prüfungen konsequenter ausführen. Ihr Erfolgskriterium muss allerdings über die Annahme einer Konfiguration hinausreichen.

Eine Pipeline sollte zwischen Transaktionserfolg und Betriebserfolg unterscheiden. „Das Gerät hat die Änderung akzeptiert“ ist ein Transaktionsergebnis. „Der OSPF-Prozess verwendet die neue Router-ID, die Nachbarn sehen sie, und es besteht kein Duplikat“ ist eine betriebliche Postcondition.

Dasselbe gilt für EVPN. Eine erfolgreiche BGP-Konfiguration beweist nicht, dass erwartete Informationen konsistent gelernt und in Hardware programmiert wurden. Die Pipeline sollte ausgewählte Routen und MAC-Einträge verfolgen, den Software-Hardware-Abgleich durchführen und Paketproben auslösen.

Solche Kontrollen müssen fail-closed sein. Bei widersprüchlichen Identitäten oder fehlenden Hardwareeinträgen darf die Aktivierung nicht lediglich eine Warnung erzeugen, die unter Zeitdruck übergangen wird. Die sichere Standardreaktion ist, den Kandidaten isoliert zu halten, bis der laufende Zustand verstanden und korrigiert ist.

Der Kontrollumfang sollte zur Änderung passen. Nicht jede Aktivierung benötigt eine vollständige Prüfung aller Tabellen. Sie braucht jedoch ausreichend repräsentative Stichproben, um die spezifische Fehlerklasse erkennen zu können. Bei einem Gerät aus dem Labor ist der Restzustand besonders wichtig; bei einem Softwarewechsel kann die Hardwareprogrammierung im Mittelpunkt stehen.

Ein erfolgreicher Automatisierungslauf sollte deshalb ein Beweispaket erzeugen. Dazu gehören Inputs, erwartete Postconditions, beobachtete Werte, Abweichungen, automatisch ausgeführte Korrekturen und die endgültige Freigabe. Damit wird Automatisierung nicht nur zum Konfigurationswerkzeug, sondern zum Erzeuger eines auditierbaren Betriebsnachweises.

Wiederherstellung muss bis an den Mitgliederpfad reichen

Core-Alarme können zeigen, dass ein Link stabil ist. BGP kann eine etablierte Sitzung anzeigen. Eine Hardwaretabelle kann Einträge enthalten. Keine dieser Beobachtungen beweist allein, dass ein Mitglied den erwarteten Gegenpunkt über den Peering-Dienst erreicht.

Die Wiederherstellung braucht daher eine Außen-nach-innen-Perspektive. Probes sollten an mitgliedernahen oder repräsentativen Punkten beginnen und jene Pfade durchlaufen, die betroffen waren. Wo sinnvoll, müssen bidirektionale Tests, verschiedene Paketgrößen und mehr als ein Protokoll verwendet werden.

Die Ergebnisse sollten nach Fehlerklasse segmentiert werden. Wenn am 22. Juni nur bestimmte IP-Adressen unerreichbar blieben, konnte eine grobe Fabric-Prüfung bereits bestehen, während diese Restfälle fortdauerten. Der Abschluss musste die konkrete Klasse der verbliebenen Störung prüfen, nicht nur den Gesamtzustand.

Dazu können ausgewählte MAC-Einträge, Nachbarauflösung, EVPN-Routen, Hardwaretabellen und Paketproben gemeinsam betrachtet werden. Die genaue Kombination hängt von Plattform und Symptom ab. Entscheidend ist, dass der Nachweis am beobachteten Fehler ansetzt.

Meldungen von Mitgliedern sind ebenfalls Beweise, aber nicht automatisch die alleinige Wahrheit. Ein Mitglied kann einen Fehler sehen, den zentrale Überwachung verpasst. Umgekehrt kann ein Anwendungs- oder Transitproblem wie eine Exchange-Störung wirken. Gemeinsame Zeitstempel, Pfadinformationen und reproduzierbare Probes helfen bei der Trennung.

Der Betreiber sollte außerdem Teil- und Vollwiederherstellung unterscheiden. Die LINX-Chronologie beschreibt deaktivierte Links als Wiederherstellungsmaßnahme und später verbliebene spezifische Erreichbarkeitsprobleme. [1] Eine einzige Abschlusszeit würde diese Zwischenphase verwischen.

Eine präzise Meldung erklärt daher, welcher Dienstumfang wiederhergestellt wurde, von welchen Punkten dies geprüft wurde und was noch untersucht wird. Sie vermeidet die Behauptung universeller Wiederherstellung auf Grundlage einer schmalen Stichprobe. Diese Zurückhaltung ist kein rhetorisches Ausweichen, sondern schützt den späteren Ereignisdatensatz vor falscher Eindeutigkeit.

Verantwortung verteilen, ohne Schuld zu erfinden

LINX kontrollierte das gemeinsame Peering-Fabric und die Aufnahme eines Routers in diese Umgebung. Dazu gehören Gerätefreigabe, Konfigurationsautomatisierung, Monitoring, Wartungsreihenfolge, Link-Isolation, Session-Clears und Kommunikation über den Exchange-Dienst. Das sind direkte Kontrollflächen, auch wenn Hardware oder Glasfaser von externen Anbietern stammen.

Faseranbieter kontrollieren physische Reparatur und Wartung innerhalb ihres jeweiligen Leistungsbereichs. Geräte- und Softwareanbieter kontrollieren Produktuntersuchung, Fehleranalyse und verfügbare Korrekturen. Der öffentliche Datensatz erlaubt keine weitergehende Zuweisung als die von LINX ausdrücklich berichtete. Eine laufende Anbieteruntersuchung ist kein Beweis für Fahrlässigkeit oder alleinige Verursachung.

Mitglieder kontrollieren ihre eigenen Anschlüsse, BGP-Sitzungen, Routingrichtlinien und Kontinuitätsentscheidungen. Sie können Route Server, bilaterales Peering, mehrere Exchange-LANs, andere Internetknoten oder Transit in unterschiedlichen Kombinationen verwenden. Öffentliche LINX- und Peering-Verzeichnisse beschreiben Dienste und Präsenz, aber nicht das vollständige Ausweichdesign jedes einzelnen Mitglieds. [7][8][20]

Daher ist weder anzunehmen, dass alle Mitglieder gleich betroffen waren, noch dass eine zweite Verbindung automatisch einen technisch unabhängigen und funktionierenden Ersatzpfad bereitstellte. Vertragszahl und Pfadunabhängigkeit sind unterschiedliche Sachverhalte.

Verantwortung kann sich überlappen. LINX kann das Fabric betreiben, ein Anbieter kann die Faser warten, und ein Mitglied kann über seine Anschlussstrategie entscheiden. Die analytisch nützliche Frage lautet, wer welches Beweiselement und welche Entscheidung kontrollierte.

Wer wusste, dass die Pfadresilienz eingeschränkt war? Wer konnte eine Aktivierung verschieben? Wer prüfte die laufende Router-ID? Wer durfte den OSPF-Prozess bereinigen? Wer verglich Software- und Hardwaretabellen? Wer testete die Mitgliedererreichbarkeit? Wer kommunizierte den Restzustand?

Eine solche Kontrollmatrix ist stärker als die vorschnelle Suche nach einem einzigen Schuldigen. Netzstörungen überschreiten regelmäßig technische und organisatorische Grenzen. Die Matrix weist Handlungen zu, ohne eine rechtliche Bewertung zu erfinden. Sie zeigt auch Lücken: Wenn niemand den Ende-zu-Ende-Test besitzt, kann jeder Komponentenverantwortliche sein Ticket schließen, während der Dienst weiterhin beeinträchtigt ist.

Auch öffentliche Rechenschaft sollte dieser Disziplin folgen. LINX-Berichte stützen Aussagen darüber, was der Betreiber beobachtete und unternahm. RFCs erklären Protokollverhalten. Herstellerdokumentation kann allgemeine Betriebshinweise liefern. Keines dieser Dokumente offenbart automatisch private Verträge, vollständige Schäden oder einen rechtlichen Sorgfaltsmaßstab.

Ein Beweismodell für Wiederholungen

Die Juni- und Novemberereignisse zeigen, warum Wiederholungsmanagement ein versioniertes Beweismodell braucht. Jede Korrekturmaßnahme sollte die zugrunde liegende Fehlerhypothese, die erwartete beobachtbare Änderung und den Bestätigungstest nennen.

Für die Router-Identität lautet eine Hypothese, dass ein laufender OSPF-Prozess eine alte ID beibehielt. Das erwartete Korrekturergebnis ist eine eindeutige Live-Identität in der gesamten Domäne nach der erforderlichen Prozessaktion. Beweise sind lokaler Zustand, Nachbarsicht und Duplikatprüfung.

Für die Abweichung zwischen Software- und Hardware-MAC-Tabelle betrifft die Hypothese die Programmierung oder Synchronisierung zwischen Kontroll- und Weiterleitungsebene. Erwartet wird, dass ausgewählte Einträge in beiden Ansichten vorhanden sind und Pakete den vorgesehenen Pfad nutzen. Beweise sind Tabellen, EVPN-Sitzungszustand und Pakettests.

Für die reduzierte Faserresilienz betrifft die Hypothese Pfadvielfalt und das Verhalten der verbleibenden Topologie. Erwartet werden wiederhergestellte physische Vielfalt und ein erfolgreicher kontrollierter Failover. Beweise können Pfadkarten, Linkzustände, Kapazitätsmessungen und Tests des Ersatzwegs sein.

Für eine Softwareänderung muss die Hypothese an einen bestimmten Defekt oder ein bestimmtes Symptom gebunden sein. Eine erfolgreiche Installation beweist nicht, dass das Zielproblem verschwunden ist. Ein späterer Rollback ist bedeutsam, beweist aber allein nicht, dass die Änderung sämtliche beobachteten Ausfälle verursachte.

Alle Beweispakete benötigen eine gemeinsame Zeitachse. Ohne synchronisierte Zeit können Teams einen Protokollwechsel mit einem Verkehrssymptom verbinden, das früher oder später auftrat. Geräte, Telemetrie, Tickets und Change-Systeme müssen ausreichend genaue Zeitstempel und bekannte Uhrenabweichungen besitzen.

Dabei sind Ereigniszeit, Beobachtungszeit und Aktionszeit zu unterscheiden. Ein Drop kann auftreten, bevor das Monitoring ihn meldet. Eine Sitzung kann zurückgesetzt werden, bevor das Ticket aktualisiert wird. Ohne diese Trennung kann eine scheinbar klare Abfolge falsch sein.

Mit diesem Modell lassen sich Episoden vergleichen, ohne sie zu verflachen. Wenn ein späteres Ereignis dieselbe Hardwaretabellen-Abweichung unter ähnlicher Topologie reproduziert, steigt die Konfidenz für einen gemeinsamen Mechanismus. Wiederholt sich nur das äußere Symptom, muss die Konfidenz niedriger bleiben.

Betriebsmetriken, die dem Netz folgen

Klassische Change-Metriken wie Erfolgsquote und mittlere Wiederherstellungszeit sind nützlich, aber unvollständig. Eine Änderung kann im Automatisierungssystem erfolgreich sein und dennoch alten Prozesszustand hinterlassen. Eine Wiederherstellung kann im Durchschnitt schnell wirken, während bestimmte Ziele länger unerreichbar bleiben.

Ein Labor-zu-Produktion-Programm sollte deshalb Postcondition-Fehler messen. Wie oft weicht die beabsichtigte Identität vom Live-Wert ab? Wie häufig ist ein ungeplanter Prozess-Clear oder Reboot nötig? Wie viele Aufnahmen entdecken alte Nachbarn, Routen oder Weiterleitungseinträge? Wie oft unterscheiden sich Software- und Hardwareansicht während eines Canary?

Eine weitere Metrik ist die Exposition im degradierten Zustand. Wie lange arbeitet das Netz ohne vorgesehene Pfadvielfalt? Wie viele Änderungen finden in diesem Zeitraum statt? Welche wurden ausdrücklich risikoseitig akzeptiert? Welche besaßen einen architekturgleichen Canary und einen belegten Rollback?

Auch die Mitgliederperspektive braucht eine Messgröße. Welcher Anteil des relevanten Dienstumfangs wurde nach einem Vorfall von repräsentativen Edge-Punkten geprüft? Wie groß war der Abstand zwischen breiter Wiederherstellung und Lösung der Restfälle? Wurden fehlgeschlagene Probes und erfolgreiche Wiederholungen erhalten?

Die Vollständigkeit der Beweiskette kann ebenfalls bewertet werden. Enthält der Abschluss synchronisierte Telemetrie, Topologiezustand, Protokollidentität, Hardwaredaten, Edge-Probes, Maßnahmenverantwortung und begrenzte öffentliche Aussagen? Fehlende Elemente zeigen, wo der Betreiber die eigene Schlussfolgerung nicht ausreichend belegen konnte.

Diese Metriken dürfen nicht zur nächsten Kontrolltheater-Schicht werden. Ein Team kann die Zahl ausgefüllter Checklisten optimieren, ohne das laufende Netz zu verbessern. Stichproben, unabhängige Prüfung und der Vergleich mit späteren Vorfällen halten die Messung ehrlich. Maßstab bleibt, ob reale Zustandsabweichungen vor einer Mitgliederbeeinträchtigung erkannt werden.

Was die öffentliche Beweislage nicht hergibt

Die verfügbaren Quellen identifizieren nicht jedes betroffene LINX-Mitglied, jeden Präfix, jede Sitzung, jeden Standort oder jedes Verkehrsvolumen. Sie liefern keine vollständige Dauer aller Erreichbarkeitsprobleme. Private Gerätekonfigurationen, Prozessspeicher, Automatisierungstransaktionen und vollständige Anbieterunterlagen sind nicht öffentlich.

Die Beweislage zeigt nicht, dass die doppelte Router-ID allein sämtliche Juni- und Novemberereignisse verursachte. Sie beweist ebenso wenig, dass EVPN, VXLAN, OSPF, BGP, Automatisierung oder disaggregierte Hardware grundsätzlich unsicher sind.

Der Jahreswert von 99,997 Prozent liefert keine kundenbezogene Schadenssumme. Er darf weder in erfundene Ausfallminuten für jedes Mitglied noch in nicht belegte Umsatzverluste umgerechnet werden. Die genaue Wirkung hing wahrscheinlich von Pfaden und Anschlussdesigns ab, die öffentlich nicht vollständig bekannt sind.

Der Datensatz beweist keine Fahrlässigkeit, Vertragsverletzung oder Beweisunterdrückung durch LINX, einen Anbieter oder einzelne Beschäftigte. Technische Rechenschaftsanalyse kann die erforderlichen Kontrollen benennen, ohne eine rechtliche Feststellung zu treffen.

Auch die Herstelleridentität darf nicht aus allgemeinen Dokumentationsquellen abgeleitet werden. Protokoll- und Fehlerbehebungsunterlagen erklären, wie doppelte Identitäten oder BGP-Sitzungsprobleme grundsätzlich untersucht werden können. [18][19] Sie beweisen nicht, welches Produkt im konkreten Ereignis verantwortlich war.

Diese Grenzen sind keine unwichtigen Fußnoten. Sie bestimmen die Konfidenz jeder Schlussfolgerung. Die stärksten Tatsachenbehauptungen sind jene, die LINX in Technologiebericht und Jahresbericht selbst veröffentlicht hat. Protokollaussagen sind innerhalb des Geltungsbereichs der RFCs belastbar. Private Ursachen-, Schadens- und Rechtsfragen müssen offenbleiben.

Das laufende Netz ist der abschließende Datensatz

Die dauerhafte Lehre aus LON2 lautet nicht, dass Labore gefährlich oder moderne Fabrics zu komplex seien. Sie lautet, dass der Übergang vom vorgesehenen zum laufenden Zustand bewiesen werden muss.

Ein Konfigurationsrepository kann eine neue Router-ID enthalten. NETCONF kann sie übertragen. Ein Inventar kann das richtige Gerät und Interface anzeigen. Der EVPN-Kontrollplan kann eine gelernte MAC-Adresse führen. Ein Dashboard kann eine Verfügbarkeit nahe einhundert Prozent ausweisen. Jede dieser Aussagen kann richtig sein, während der Paketpfad dennoch falsch ist.

Der abschließende Betriebsdatensatz besteht daher aus miteinander verbundenen Beobachtungen: eindeutige Protokollidentität in der gesamten Domäne, aktuelle Adjazenzen, kohärenter EVPN-Zustand, programmierte Hardwareweiterleitung, stabile physische Pfade und erfolgreich abgeschlossene Erreichbarkeitstests.

Dieser Standard stärkt auch die Automatisierung. Ein automatisierter Prozess wird vertrauenswürdiger, wenn er Postconditions prüft und bei Widersprüchen stoppt. Die Antwort auf alten Prozesszustand ist nicht mehr Handarbeit, sondern ein Deployment-Vertrag, der die erforderliche Bereinigung kennt und das Live-Ergebnis verifiziert.

Für einen Internetknoten ist das besonders wichtig, weil das Fabric zwischen unabhängigen Netzen liegt. Der Exchange kann nicht jede Routingentscheidung der Mitglieder kontrollieren. Er kann aber den Zustand seiner gemeinsamen Plattform belegen: reduzierte Redundanz erkennen, doppelte Identitäten abweisen, Kontroll- und Weiterleitungsebene abgleichen, repräsentative Pfade testen und unbekannte Auswirkungen ehrlich begrenzen.

Die öffentliche Darstellung von LINX liefert dafür ungewöhnlich konkrete Ansatzpunkte. Sie benennt den degradierten Faserzustand, die fortbestehende OSPF-Identität, die Abweichung zwischen Software- und Hardware-MAC-Tabelle, Workarounds, spätere Ereignisse und eine fortdauernde Untersuchung. [1]

Eine verantwortungsvolle Reaktion macht daraus keine vereinfachte Schuldgeschichte. Sie verwandelt die Beobachtungen in Zulassungsschranken und prüfbare Betriebsnachweise. Architekturbezeichnungen garantieren keine Kontinuität. Ein nicht getesteter Ersatzpfad ist ein Versprechen. Eine nur in der Sollkonfiguration vorhandene neue Identität ist ein Versprechen. Ein ausschließlich in Software vorhandener MAC-Eintrag ist ein Versprechen.

Rechenschaft beginnt dort, wo der Betreiber anhand des laufenden Netzes zeigen kann, dass jedes dieser Versprechen zu funktionierender Paketweiterleitung geworden ist.