Zusammenfassung

  • Nach Darstellung von AMS-IX gelangten am 22. November 2023 link-lokale LACP-Frames aus einer Kundenport-Beziehung in das gemeinsam genutzte Peering-Fabric. Andere Teilnehmer reagierten auf diese Frames; LAG-Zustände und BGP-Sitzungen flackerten, während Ressourcenknappheit, volle Puffer und RSVP-Path-Error-Verhalten die Störung über Juniper- und Extreme-Kontrollflächen hinweg verstärkten.
  • Verantwortlichkeit bemisst sich hier nicht allein an dokumentierter Absicht. Entscheidend sind nachweisbare Frame-Grenzen, die Übereinstimmung von Bereitstellung und tatsächlicher Switch-Konfiguration, herstellerübergreifende Regressionstests, wirksame Alarme, belastbare Rücksetzbelege sowie ausreichend dimensionierte und erprobte Alternativen über Transit oder Remote Peering.

Eine Störung mit klaren zeitlichen Grenzen

Die Untersuchung betrifft ausschließlich die Störungen auf der Amsterdamer Peering-Plattform von AMS-IX am 22. und 23. November 2023. Sie ist keine allgemeine Bewertung des europäischen Internets und keine Aussage darüber, wie jede MPLS-, VPLS- oder Peering-Umgebung auf vergleichbare Signale reagieren würde. Der Gegenstand ist enger: ein von AMS-IX beschriebenes Entweichen von LACP-Frames, das daraus entstandene Flackern von Link-Aggregation und BGP-Sitzungen, die nachfolgende Belastung weiterer Kontrollflächen und die Frage, welche technischen Belege für wirksame Isolation und belastbare Wiederherstellung erforderlich sind.

AMS-IX gab für den 22. November einen betroffenen Zeitraum von 19:08 bis 23:04 Uhr CET an. Für den 23. November meldete der Betreiber einen weiteren betroffenen Zeitraum von 09:38 bis 10:25 Uhr CET. Diese Zeitfenster sind die offiziellen Grenzen der öffentlich beschriebenen Plattformereignisse. Sie dürfen weder stillschweigend verlängert noch als genaue Ausfallzeit jedes angeschlossenen Netzes oder jedes darüber erreichbaren Dienstes behandelt werden.

Für den Tiefpunkt meldete AMS-IX einen Plattformverkehr von 2,1 Tb/s. Außerdem berichtete der Betreiber, dass die Zahl der IPv4-BGP-Sitzungen von 885 auf 550 und die Zahl der IPv6-BGP-Sitzungen von 800 auf 450 zurückging. Diese Werte sind aussagekräftig, aber nur innerhalb ihres Messbereichs. Sie beschreiben Verkehr und Sitzungszustände auf der Exchange-Plattform. Sie sind keine Nutzerzahlen, keine Anzahl ausgefallener Anwendungen, keine Schadenssumme und kein Beleg dafür, dass der gesamte europäische Datenverkehr beeinträchtigt war.

Gerade diese Begrenzung ist für eine Verantwortlichkeitsanalyse wichtig. Große Zahlen verleiten zu großen, aber nicht gedeckten Schlussfolgerungen. Ein Rückgang der BGP-Sitzungen zeigt, dass zahlreiche Kontrollbeziehungen auf der Plattform nicht stabil blieben. Ein Einbruch des Plattformverkehrs zeigt, dass weniger Daten über diese Austauschfläche liefen. Beides beantwortet jedoch noch nicht, ob der fehlende Verkehr verloren ging, auf andere Verbindungen auswich, von einzelnen Netzen absichtlich abgezogen wurde oder wegen fehlender Alternativen seine Ziele nicht erreichte.

Daraus ergeben sich drei voneinander zu trennende Zeitlinien. Die erste ist die Stabilisierung des AMS-IX-Fabrics: Ab wann wurden unerwünschte Zustandsänderungen auf der Plattform gestoppt? Die zweite ist die Verlagerung des Verkehrs: Ab wann leiteten angeschlossene Netze Daten über andere Wege oder deaktivierten betroffene Sitzungen? Die dritte ist die Ende-zu-Ende-Erholung: Ab wann konnten die jeweiligen Kunden, Anwendungen und Gegenstellen ihre vorgesehenen Dienste wieder zuverlässig nutzen? Diese Zeitlinien können sich überschneiden, sind aber nicht identisch.

Eine Plattform kann noch instabil sein, während einzelne Teilnehmer bereits erfolgreich ausweichen. Umgekehrt kann die Plattform technisch stabilisiert sein, während nachgelagerte Routen, Sitzungen oder Anwendungen noch nicht vollständig wiederhergestellt sind. Wer nur den Plattformgraphen betrachtet, sieht deshalb weder die gesamte Schadensdauer noch den vollständigen Wiederherstellungsverlauf.

Vom Kundenport in ein gemeinsam genutztes Fabric

Nach der Darstellung von AMS-IX begann das Ereignis mit LACP-Paketen, die von nicht näher benannter Kundenausrüstung erzeugt wurden. Diese Ausrüstung war über einen Port angeschlossen, der nicht für LACP vorgesehen war. Ein Juniper-Provider-Edge-Switch leitete die link-lokalen Kontrollpakete nach Angaben des Betreibers weiter, anstatt sie innerhalb der benachbarten Beziehung zu halten.

Diese Zuschreibung muss als solche erkennbar bleiben. Die Identität des Kunden, das genaue Gerät, dessen Softwarestand und die zugehörige Konfigurationsgeschichte sind nicht öffentlich. Ebenso wenig liegt öffentlich ein vollständiger Satz von Paketmitschnitten, Switch-Protokollen, Testfällen oder Herstellerfeststellungen vor, aus dem eine unabhängige Rekonstruktion jedes internen Schrittes möglich wäre.

LACP koordiniert die Bündelung physischer Verbindungen zwischen benachbarten Systemen. Die beteiligten Geräte tauschen Kontrollinformationen aus, um festzustellen, welche Links zu einer gemeinsamen Aggregation gehören und in welchem Zustand sie sich befinden. Die Bedeutung eines solchen Frames ist deshalb an die konkrete Nachbarschaft gebunden. Er ist kein gewöhnlicher Nutzdatenframe, der beliebig durch ein gemeinsam genutztes Layer-2-System wandern sollte.

Die zentrale technische Grenzverletzung bestand nicht allein darin, dass ein Kundengerät einen LACP-Frame erzeugte. Entscheidend war, dass der Frame nach der offiziellen Darstellung die Beziehung verließ, in der er Bedeutung haben durfte. Sobald andere Teilnehmer den Frame empfingen und als für ihre eigenen Aggregationen relevant behandelten, konnte ein lokal erzeugtes Kontrollsignal fremde LAG-Zustände beeinflussen.

Damit wurde aus einem Verhalten an einem einzelnen Kundenport ein gemeinsames Infrastrukturproblem. Das Peering-Fabric war nicht lediglich eine passive Leitung zwischen einem Sender und einem Empfänger. Es stellte die Grenze bereit, die den Geltungsbereich von Kontrollframes hätte beschränken müssen. Seine tatsächliche Weiterleitungs- und Filterlogik bestimmte, ob ein Signal lokal blieb oder auf unabhängige Teilnehmer übergriff.

Die wesentliche Sicherheits- und Zuverlässigkeitsanforderung lässt sich daher als Frame-Grenz-Invariante formulieren: Ein link-lokaler Kontrollframe darf eine Kundenport-Beziehung nicht verlassen, unabhängig davon, ob der Port statisch aggregiert, dynamisch mit LACP betrieben oder überhaupt nicht aggregiert wird. Diese Regel muss für jede relevante Portart gelten. Eine Ausnahme gerade für einen nicht mit LACP betriebenen Port unterläuft den Zweck der Isolation.

Eine solche Invariante darf nicht nur in einer Konfigurationsanleitung stehen. Sie muss sich im laufenden System wiederfinden: in der Logik des Bereitstellungssystems, in den tatsächlich installierten ACLs, in der Weiterleitungsentscheidung jedes betroffenen Switch-Typs und in Tests, die unerlaubte Frames aktiv einspeisen und deren Nichtweiterleitung nachweisen.

Warum der Nicht-LACP-Port keine nebensächliche Einzelheit war

AMS-IX erklärte, dass Schutzmaßnahmen in Form von LACP-ACLs vorhanden gewesen seien. Der relevante Anschluss sei jedoch ein Nicht-LACP-Link gewesen. Damit wird die Klassifizierung des Ports zu einem entscheidenden Teil des Ereignisses.

Wenn ein Schutzmechanismus nur dort erzeugt oder aktiviert wird, wo das Bereitstellungssystem LACP erwartet, entsteht eine Lücke: Gerade ein Port, auf dem kein LACP stattfinden soll, kann ohne gleichwertige Filterung unerwartete LACP-Frames weiterreichen. Die deklarierte Portart beschreibt dann zwar die beabsichtigte Nutzung, erzwingt aber noch nicht die notwendige Begrenzung unerwünschter Kontrollsignale.

Die richtige Kontrollfrage lautet deshalb nicht nur: „War LACP für diesen Port aktiviert?“ Sie lautet auch: „Welche Frames dürfen diesen Port unter jeder zulässigen Konfiguration verlassen?“ Ein Nicht-LACP-Port sollte nicht weniger, sondern mindestens ebenso eindeutig gegen das Austreten von LACP-Kontrollverkehr abgesichert sein. Dass eine Funktion nicht bestellt oder konfiguriert wurde, ist kein Beleg dafür, dass entsprechende Frames technisch unmöglich sind.

Dieses Ereignis illustriert den Unterschied zwischen positiver Funktionskonfiguration und negativer Grenzdurchsetzung. Positive Konfiguration legt fest, was ein Port tun soll. Negative Durchsetzung legt fest, was er unter keinen Umständen in das gemeinsame Fabric einbringen darf. Für eine geteilte Austauschplattform ist beides notwendig.

Eine Bereitstellung kann formal korrekt aussehen und dennoch eine Schutzlücke enthalten, wenn ihre Vorlagen nicht alle Kombinationen von Portart, Switch-Familie und ACL-Richtung abdecken. Deshalb muss die Übereinstimmung nicht nur zwischen Kundenauftrag und Teilnehmerdaten geprüft werden. Sie muss bis zur tatsächlich aktiven Gerätekonfiguration und zum beobachteten Weiterleitungsverhalten reichen.

LAG- und BGP-Flapping als gekoppeltes Problem

Andere Teilnehmer reagierten nach dem Bericht von AMS-IX auf die ausgetretenen LACP-Frames. Ihre Link-Aggregation-Groups änderten Zustand, und sowohl LACP- als auch BGP-Sitzungen flackerten. Damit traf eine Störung auf Layer 2 unmittelbar die Erreichbarkeitsbeziehungen auf Layer 3.

Ein LAG bündelt mehrere physische Links zu einer logischen Verbindung. Ändert sich die Einschätzung, welche Mitglieder aktiv oder synchronisiert sind, kann sich die verfügbare Weiterleitungskapazität verändern. Die logische Schnittstelle kann instabil werden oder kurzzeitig ihren Zustand verlieren. Wenn eine BGP-Sitzung über diese Verbindung geführt wird, kann die Instabilität darunter auch die Routing-Sitzung treffen.

BGP wiederum hält nicht nur eine abstrakte Teilnehmerbeziehung fest. Die Sitzung trägt Erreichbarkeitsinformationen, deren Verfügbarkeit bestimmt, welche Pfade ein Netz für Ziele verwenden kann. Fällt eine Sitzung weg und kehrt wieder, müssen Zustände verworfen, neu aufgebaut und Routen erneut verarbeitet werden. Wiederholtes Flackern erzeugt damit mehr Arbeit als ein einzelner, sauber abgegrenzter Zustandswechsel.

Die von AMS-IX dokumentierten Rückgänge von 885 auf 550 IPv4-Sitzungen und von 800 auf 450 IPv6-Sitzungen zeigen, dass die Störung auf der Kontrollfläche der Plattform erheblich war. Sie sagen jedoch nicht, dass jede verlorene Sitzung einen vollständigen Ausfall des jeweiligen Netzes bedeutete. Ein Teilnehmer konnte zusätzliche Sitzungen an anderen Austauschpunkten, direkten Interconnects, Transitverbindungen oder entfernten Peering-Standorten haben. Ein anderer Teilnehmer konnte stärker von genau dieser Verbindung abhängen.

Diese unterschiedliche Abhängigkeit erklärt, warum Plattformmetriken nicht direkt in Nutzerfolgen umgerechnet werden können. Zwei Netze mit ähnlich wirkendem Sitzungsverlust können sehr unterschiedliche Ergebnisse erleben. Das eine verschiebt Verkehr über ausreichend dimensionierte Alternativen; das andere besitzt zwar einen theoretischen Ersatzpfad, aber nicht die nötige Kapazität, Automatisierung oder Entscheidungsfreiheit, ihn rechtzeitig zu nutzen.

Auch die Rückkehr einer BGP-Sitzung ist nicht mit Ende-zu-Ende-Erholung gleichzusetzen. Die Sitzung muss stabil bleiben, Routen müssen akzeptiert und ausgewählt werden, Datenpfade müssen tatsächlich funktionieren und nachgelagerte Systeme müssen ihre Zustände gegebenenfalls neu aufbauen. Eine rein binäre Messung „Sitzung aktiv“ kann diese Qualität nicht vollständig abbilden.

Juniper, Extreme und die Grenze zulässiger Zuschreibungen

Die offizielle Darstellung beschreibt mehrere herstellerspezifische Kontrollflächen. Nach Angaben von AMS-IX war die ausgehende LACP-ACL auf der betroffenen Juniper-Seite nicht vollständig wirksam. Für Extreme-SLX-Systeme berichtete der Betreiber, dass die ausgehende ACL nicht wie erwartet funktioniert habe.

AMS-IX ließ öffentlich offen, ob das Verhalten auf der SLX-Seite durch einen Softwarefehler oder durch eine nach einem Upgrade veränderte Syntax verursacht wurde. Diese Ungewissheit ist kein redaktioneller Mangel, der mit Spekulation gefüllt werden sollte. Sie ist selbst ein wichtiger Teil der Beweislage.

Ohne die genauen Softwareversionen, die tatsächliche ACL-Konfiguration vor und während des Ereignisses, die vom Bereitstellungssystem erzeugten Befehle, die Geräteausgaben und die Herstelleranalyse lässt sich nicht belastbar entscheiden, welche Erklärung zutrifft. Es wäre daher unzulässig, aus der öffentlichen Darstellung pauschal ein Versagen eines bestimmten Herstellers oder einer gesamten Produktfamilie abzuleiten.

Gleichzeitig wäre es ebenso unzureichend, die herstellerübergreifende Dimension zu ignorieren. Ein gemeinsam genutztes Fabric kann nur dann als isoliert gelten, wenn die beabsichtigte Regel auf allen eingesetzten Plattformen äquivalent durchgesetzt wird. Gleiche Richtliniennamen oder ähnliche ACL-Zeilen sind kein Nachweis gleicher Laufzeitwirkung.

Hersteller unterscheiden sich bei Syntax, Standardverhalten, Verarbeitung spezieller Frame-Klassen, Richtung von Filtern, Upgradepfaden und Fehlerbehandlung. Ein Bereitstellungssystem muss diese Unterschiede explizit modellieren. Es darf nicht voraussetzen, dass eine abstrakte Richtlinie allein durch das Rendern herstellerspezifischer Konfiguration zuverlässig umgesetzt ist.

Daraus folgt eine klare Testanforderung. Für jede unterstützte Kombination aus Portart, Hardwarefamilie und Softwarezweig sollte eine Konformitätsprüfung belegen, dass link-lokale LACP-Frames nicht über die Kundengrenze gelangen. Diese Prüfung muss das beobachtete Verhalten messen und darf sich nicht darauf beschränken, ob ein erwarteter Konfigurationstext auf dem Gerät vorhanden ist.

Ebenso wichtig sind Upgrade-Regressionstests. Wenn sich Syntax oder Semantik nach einer Aktualisierung ändern können, muss die Bereitstellung erkennen, ob die gewünschte Filterwirkung weiterhin besteht. Ein erfolgreicher Konfigurations-Commit ist kein hinreichender Beweis. Ein Gerät kann eine Zeile akzeptieren, ohne genau die erwartete Datenpfadwirkung zu erzeugen.

Die Verantwortung lässt sich deshalb nicht sinnvoll auf die Frage reduzieren, welches Gerät „schuld“ war. Die belastbare Frage lautet, welche Instanz die End-to-End-Invariante definierte, wie sie in herstellerspezifische Regeln übersetzt wurde und welche Messung ihre tatsächliche Durchsetzung bestätigte.

Ressourcenknappheit, volle Puffer und die RSVP-Verstärkung

AMS-IX beschrieb die LACP-Leckage und das daraus folgende LACP- und BGP-Flapping als auslösende Kette. Im weiteren Verlauf hätten Ressourcenknappheit und volle Puffer RSVP-Timeout-Fehler erzeugt. Betroffene Juniper-Geräte hätten Path-Error-Nachrichten gesendet, die auf Extreme-SLX-Switches weitere Probleme verursachten.

Diese Abfolge muss sorgfältig gegliedert werden. RSVP war nach der öffentlichen Darstellung nicht der anfängliche Auslöser. Die erste relevante Grenzverletzung war das Entweichen von LACP-Kontrollframes. Die RSVP-bezogenen Effekte traten als Verstärker in einer bereits belasteten, herstellerübergreifenden Kontrollumgebung auf.

RSVP-TE dient in MPLS-Umgebungen der Signalisierung von Pfaden und Ressourcen. Path Error ist Teil dieser Signalisierungslogik. Das Vorhandensein einer solchen Nachricht ist daher nicht an sich ein Fehler. Entscheidend ist, unter welchen Bedingungen sie erzeugt, mit welcher Häufigkeit sie verarbeitet und wie nachgelagerte Geräte darauf reagieren.

Wenn LAGs und BGP-Sitzungen wiederholt wechseln, steigt die Menge der Zustandsänderungen, die verschiedene Kontrollkomponenten verarbeiten müssen. Ressourcenknappheit und volle Puffer können die zeitliche Kopplung verschärfen: Nachrichten werden verzögert, Timeouts treten auf, neue Fehlerreaktionen erzeugen zusätzliche Arbeit, und ein System erhält weniger Gelegenheit, in einen stabilen Zustand zurückzukehren.

Die öffentliche Evidenz erlaubt jedoch keine vollständige Quantifizierung dieser Schleife. Nicht verfügbar sind unter anderem die Puffertelemetrie, genaue RSVP-Nachrichtenvolumen, interne Zeitreihen der Geräteauslastung, vollständige Protokolle und die exakten Softwarestände. Deshalb kann die Analyse die von AMS-IX beschriebene Verstärkung erklären, aber nicht jede Nachricht oder Zustandsänderung unabhängig rekonstruieren.

Auch eine Verallgemeinerung auf alle MPLS-Netze wäre falsch. Die konkrete Kaskade hing von der Architektur, den eingesetzten Plattformen, deren Konfiguration, den vorhandenen Ressourcen und dem spezifischen Fehlerverhalten ab. Standards zu RSVP-TE, schnellem MPLS-Rerouting und VPLS erklären die Funktionen und Begriffe. Sie beweisen nicht, dass jede andere Umgebung unter ähnlicher Last denselben Ablauf zeigen würde.

Für die Verantwortlichkeitsfrage ist dennoch ein allgemeiner Prüfpunkt erkennbar: Kontrollflächen müssen nicht nur im Normalbetrieb, sondern auch unter Ressourcenknappheit und wiederholten Zustandswechseln getestet werden. Ein Filter kann unter ruhigen Laborbedingungen funktionieren, während die Gesamtarchitektur bei hoher Ereignisrate unerwartete Rückkopplungen zeigt.

Herstellerübergreifende Regressionstests sollten daher mehr umfassen als einen einzelnen unerwünschten Frame. Sie sollten Serien fehlerhafter oder fehlplatzierter Kontrollframes, LAG-Wechsel, BGP-Neuaufbauten, Pufferdruck, RSVP-Fehlerpfade und Rückkehr in einen stabilen Zustand abdecken. Ziel ist nicht, jedes denkbare Versagen vorherzusagen. Ziel ist, zu belegen, dass ein lokales Signal weder die Kundengrenze überschreitet noch eine unbegrenzte Kontrollschleife auf gemeinsam genutzter Infrastruktur auslöst.

Was die Plattformzahlen belegen – und was nicht

Die gemeldeten Zahlen liefern drei belastbare Beobachtungen. Erstens sank der Verkehr auf der AMS-IX-Plattform bis auf 2,1 Tb/s. Zweitens ging die Zahl der IPv4-BGP-Sitzungen laut AMS-IX von 885 auf 550 zurück. Drittens sank die Zahl der IPv6-Sitzungen von 800 auf 450.

Daraus lässt sich folgern, dass das Ereignis nicht auf einen unsichtbaren internen Fehler ohne externe Kontrollwirkung beschränkt blieb. Die Plattform transportierte deutlich weniger Verkehr, und ein erheblicher Teil ihrer BGP-Sitzungen war nicht stabil verfügbar. Diese Beobachtungen stützen die Einordnung als relevante Störung einer zentralen Austauschfläche.

Die Zahlen beantworten jedoch nicht, wie viele Endnutzer gleichzeitig betroffen waren. Eine BGP-Sitzung kann Netze sehr unterschiedlicher Größe und Bedeutung verbinden. Mehrere Sitzungen können zu demselben Teilnehmer gehören. Umgekehrt kann ein einzelner verlorener Pfad für einen stark abhängigen Dienst erhebliche Folgen haben.

Der Verkehrstiefpunkt misst ebenfalls keine Verlustrate. Daten, die nicht mehr über AMS-IX liefen, konnten auf andere Wege verlagert worden sein. Ein Teil konnte verworfen worden sein. Ein weiterer Teil wurde möglicherweise gar nicht mehr gesendet, weil Sitzungen oder Anwendungen bereits reagiert hatten. Ohne vollständige Ende-zu-Ende-Messung bleibt die Verteilung zwischen diesen Möglichkeiten offen.

Damit sind die Plattformmetriken starke Infrastrukturbelege, aber keine vollständige Schadensbilanz. Eine verantwortungsvolle Darstellung muss ihre Aussagekraft nutzen, ohne sie zu überschreiten.

Ausweichverkehr ist nicht dasselbe wie Plattformwiederherstellung

Die zeitgenössischen Berichte angeschlossener Netze zeigen, dass einige Betreiber aktiv auf die Störung reagierten. Total Uptime dokumentierte eine Verkehrsverlagerung und spätere Wiederherstellung. NFOrce berichtete über das Abschalten von Sitzungen als Maßnahme zur Begrenzung von Paketverlusten. EDPnet veröffentlichte eine Chronologie der Auswirkungen, Aussagen zu alternativer Kapazität und Aktualisierungen zur Erholung.

Diese Berichte sind wertvoll, weil sie die Sicht außerhalb des Austauschpunkts ergänzen. Sie dürfen jedoch nur innerhalb ihrer jeweiligen Reichweite verwendet werden. Sie beschreiben die Beobachtungen und Maßnahmen dieser Betreiber. Sie belegen nicht, dass alle Teilnehmer dieselben Optionen, dieselbe Kapazität oder denselben Erfolg hatten.

Das Abschalten einer Sitzung kann eine sinnvolle Schutzmaßnahme sein, wenn der verbleibende Verkehr über stabile Alternativen geführt werden kann. Es kann aber auch Erreichbarkeit reduzieren, wenn keine ausreichenden Ersatzpfade bestehen. Ob die Maßnahme hilft, hängt somit nicht nur von technischer Konnektivität ab, sondern von Kapazität, Routingpolitik, Automatisierung und betrieblicher Entscheidungsbefugnis.

Eine alternative Verbindung ist nur dann ein belastbarer Ausweichpfad, wenn sie im Ereignis tatsächlich nutzbar ist. Ein Vertrag, eine Leitung oder eine konfigurierte BGP-Nachbarschaft allein genügt nicht. Der Pfad muss genügend Kapazität besitzen, die erforderlichen Routen transportieren, von der Routingpolitik ausgewählt werden können und unter realistischen Bedingungen getestet worden sein.

Remote Peering kann die Abhängigkeit von einem einzelnen physischen Standort oder einer einzigen lokalen Austauschfläche verringern. Transit kann zusätzliche globale Erreichbarkeit bereitstellen. Direkte Verbindungen können für bestimmte Gegenstellen eine weitere Option sein. Keine dieser Varianten ist automatisch überlegen. Ihre Resilienzwirkung hängt von Unabhängigkeit, Dimensionierung und gemeinsamer Fehlerdomäne ab.

Zwei scheinbar getrennte Verbindungen können denselben Transportanbieter, dieselbe Trasse, dieselbe Stromversorgung oder dieselbe Kontrollkomponente nutzen. Ein belastbarer Test muss deshalb nicht nur feststellen, dass zwei Pfade existieren. Er muss prüfen, welche Risiken sie tatsächlich teilen und ob der alternative Pfad bei Ausfall oder absichtlicher Deaktivierung des primären Pfads den vorgesehenen Verkehr übernehmen kann.

Die wirtschaftliche Dimension gehört ebenfalls zur Verantwortlichkeit. Zusätzlicher Transit, Remote Peering und freie Reservekapazität kosten Geld. Kleinere Netze können weniger Möglichkeiten besitzen, dauerhaft ungenutzte Kapazität vorzuhalten. Das ändert nicht die technische Notwendigkeit von Ausweichwegen, erklärt aber, warum Resilienz zwischen Teilnehmern ungleich verteilt sein kann.

Für einen Exchange-Betreiber folgt daraus keine pauschale Verantwortung für jede nachgelagerte Architektur. Angeschlossene Netze kontrollieren ihre Transitwahl, Peering-Strategie, Kapazitätsplanung und Sitzungspolitik. Der Betreiber des gemeinsam genutzten Fabrics kontrolliert dagegen die Isolation innerhalb seiner Plattform. Beide Ebenen müssen getrennt bewertet werden.

Was RIPE Atlas sichtbar macht

Die RIPE-Atlas-Auswertung ergänzt Betreiberberichte um eine Messperspektive auf Ende-zu-Ende-Pfade. Innerhalb des eingefrorenen Befunds zeigt sie, dass einige Pfade um die Störung herumgeführt wurden, während andere scheiterten oder sich veränderten.

Das stützt die Aussage, dass das Internet unter bestimmten Bedingungen Verkehr um beschädigte Bereiche herumleiten kann. Es widerlegt zugleich eine zu einfache Erzählung automatischer Selbstheilung. Ein Pfad kann nur ausweichen, wenn eine alternative Verbindung existiert, die Routingpolitik sie zulässt und die beteiligten Systeme den neuen Zustand rechtzeitig erreichen.

Messpunkte haben außerdem begrenzte Sicht. Sie beobachten ausgewählte Quellen, Ziele und Zeitpunkte. Ein stabiler Messpfad beweist nicht, dass alle Nutzer desselben Netzes stabil blieben. Ein fehlgeschlagener Pfad beweist umgekehrt nicht, dass das gesamte Netz unerreichbar war.

RIPE Atlas eignet sich daher besonders zur Identifikation unterschiedlicher Pfadreaktionen. Die Messungen können zeigen, dass einige Verbindungen wechselten, andere ausfielen und wieder andere offenbar nicht denselben Effekt erfuhren. Für eine vollständige Schadenszuordnung wären zusätzliche Betreibertelemetrie, Kundendaten und Anwendungsbeobachtungen erforderlich, die öffentlich nicht vorliegen.

Auch der Vergleich mit früheren IXP-Ereignissen und wissenschaftliche Arbeiten zur Erkennung von Austauschpunktstörungen unterstreichen die methodische Grenze: Externe Messungen können Symptome, Pfadänderungen und Wiederherstellungsmuster sichtbar machen. Sie ersetzen keine internen Geräteprotokolle und keine vollständige Kenntnis der Routingentscheidungen jedes Teilnehmers.

Drei Ebenen der Erholung

Die Ereignisse sollten anhand dreier Erholungsebenen bewertet werden.

Erstens ist die Plattformstabilisierung zu prüfen. Dazu gehören das Ende des LACP- und BGP-Flappings, die Wiederherstellung stabiler Kontrollzustände und der Nachweis, dass unerwünschte Frames nicht weiter über Kundengrenzen gelangten.

Zweitens ist die Verkehrsverlagerung zu betrachten. Teilnehmer konnten Sitzungen deaktivieren oder Verkehr auf Transit- und andere Peering-Pfade verschieben. Diese Maßnahmen reduzierten möglicherweise die direkte Abhängigkeit vom instabilen Fabric, bedeuteten aber nicht, dass die Ursache innerhalb der Plattform bereits beseitigt war.

Drittens steht die Ende-zu-Ende-Wiederherstellung. Sie verlangt, dass Nutzer und Dienste ihre Ziele tatsächlich wieder zuverlässig erreichen. Dafür müssen nicht nur BGP-Sitzungen aktiv sein. Die gewählten Routen müssen funktionieren, die Kapazität muss ausreichen, und nachgelagerte Systeme müssen wieder in einen stabilen Zustand gelangen.

Ein belastbarer Abschlussbericht sollte diese Ebenen getrennt ausweisen. Andernfalls kann eine erfolgreiche Verkehrsverlagerung als Reparatur der Plattform erscheinen oder eine technische Plattformstabilisierung als vollständige Kundenerholung dargestellt werden. Beides würde unterschiedliche Kontrollverantwortungen vermischen.

Von angekündigten Maßnahmen zu überprüfbarer Wirksamkeit

AMS-IX nannte mehrere Folgemaßnahmen. Dazu gehörten ACLs für Nicht-LACP-Links, Verbesserungen der ACL-Erzeugung im Bereitstellungsstack, eine Überprüfung ausgehender LACP-ACLs auf Juniper- und Extreme-Systemen, Untersuchungen zu Alarmen für Slow-Protocol-BPDUs sowie Änderungen der Kommunikationsregeln für die technische Mailingliste.

Diese Maßnahmen passen zu den sichtbar gewordenen Kontrolllücken. Sie adressieren Porttypen, Konfigurationsgenerierung, herstellerübergreifende Filterung, Erkennung und Kommunikation. Dennoch sind sie zunächst angekündigte Reparaturverpflichtungen. Die öffentlich vorliegende Evidenz enthält keine unabhängige, vollständige Bestätigung, dass jede Maßnahme dauerhaft und auf allen relevanten Port- und Gerätekombinationen wirksam ist.

Eine Verpflichtung wird erst durch überprüfbare Ausführung zur belastbaren Kontrolle. Für ACLs bedeutet das: Die Regeln müssen auf allen vorgesehenen Ports vorhanden sein, syntaktisch akzeptiert werden und im Datenpfad nachweislich die verbotenen Frames blockieren. Für das Bereitstellungssystem bedeutet es: Jede unterstützte Portart muss automatisch die korrekte Schutzkonfiguration erhalten, und Abweichungen müssen erkannt werden.

Für Alarme genügt nicht, dass eine neue Signatur definiert wurde. Es sollte nachweisbar sein, dass Testframes den Alarm auslösen, die Meldung die richtige betriebliche Stelle erreicht und eine konkrete Reaktion erfolgt. Alarmierung ohne geübte Handlungskette ist nur eingeschränkte Vorsorge.

Rücksetzfähigkeit benötigt ebenfalls Belege. Wenn eine Konfigurationsänderung oder ein Upgrade die Filterwirkung verändert, muss eine bekannte, getestete Rückkehrmöglichkeit bestehen. Dazu gehören eine versionierte Sollkonfiguration, ein klarer Auslöser für die Rücksetzung und ein Test, der nach dem Rücksetzen die wiederhergestellte Frame-Grenze bestätigt.

Kommunikation ist kein Ersatz für technische Isolation, gehört aber zur Schadensbegrenzung. Angeschlossene Netze benötigen rechtzeitig genug Informationen, um Sitzungen zu deaktivieren, Ausweichpfade zu aktivieren und eigene Kunden zu informieren. Ein Kommunikationskanal sollte deshalb festgelegte Schwellen, Zuständigkeiten und Mindestinformationen besitzen.

Die nachhaltige Reparatur wäre schließlich nicht nur die Beseitigung der im November 2023 beobachteten Kombination. Sie müsste die zugrunde liegende Invariante absichern: Kein link-lokaler LACP-Frame darf von einem Kundenport zu unabhängigen Teilnehmern gelangen. Wird diese Regel direkt überprüft, ist die Kontrolle weniger von der exakten Wiederholung eines historischen Fehlers abhängig.

Dokumentierte Absicht und laufende Wirklichkeit

Teilnehmerlisten, AS-Nummern, Schnittstellendaten, Porttypen und vorgesehene Richtlinien sind wichtige Belege. Sie dokumentieren, wer verbunden war, welche Beziehung vorgesehen wurde und welche Regeln gelten sollten. Ohne solche Aufzeichnungen wäre eine Rekonstruktion erheblich schwieriger.

Diese Aufzeichnungen erzwingen jedoch keine Paketbehandlung. Eine Datenbankzeile mit der Kennzeichnung „Nicht-LACP“ hindert ein Gerät nicht automatisch daran, einen LACP-Frame weiterzuleiten. Eine ACL-Vorlage blockiert nichts, solange sie nicht korrekt gerendert, installiert und im laufenden Datenpfad wirksam ist.

Die operative Wirklichkeit bestand während des Ereignisses aus Switch-Weiterleitung, ACL-Verhalten, LAG-Zuständen, BGP-Sitzungen und tatsächlich nutzbaren Ausweichpfaden. Diese Zustände entschieden, welcher Verkehr seine Ziele erreichte. Dokumentation und Absicht sind Rechenschaftsbelege; sie sind keine selbstvollziehenden Kontrollen.

Eine starke Kontrollarchitektur verbindet deshalb Register und Laufzeit. Der deklarierte Porttyp erzeugt eine konkrete Schutzkonfiguration. Das Gerät bestätigt deren Installation. Ein aktiver Test bestätigt die tatsächliche Filterwirkung. Telemetrie erkennt Abweichungen. Änderungen werden mit ihrem Ergebnis protokolliert. Erst diese Kette erlaubt den Nachweis, dass Absicht und Verhalten übereinstimmen.

Verantwortlichkeit ohne vorschnelle Schuldzuweisung

Die öffentliche Beweislage erlaubt eine Zuordnung technischer Kontrollbereiche, aber keine Feststellung rechtlicher Haftung. Es gibt keinen ausreichenden öffentlichen Grund, dem unbekannten Kunden, AMS-IX, Juniper, Extreme oder einem verbundenen Netz Fahrlässigkeit, Rechtswidrigkeit, Vertragsbruch oder böswillige Absicht vorzuwerfen.

Die Identität des Kunden ist nicht öffentlich. Ebenso fehlen genaue Informationen darüber, warum dessen Gerät LACP-Frames erzeugte, welche Konfiguration vorgesehen war und welche Tests vorgenommen wurden. Das Senden des Frames ist ein Teil der Kette, aber nicht der einzige relevante Kontrollpunkt.

AMS-IX kontrollierte nach dem eingefrorenen Befund das gemeinsam genutzte Fabric, die erlaubten Frame-Klassen, die Bereitstellungslogik, die auf der Plattform eingesetzten Switch-Konfigurationen, die Alarmierung und die Ereigniskommunikation. Daraus folgt eine betriebliche Pflicht zur Erklärung und Überprüfung dieser Kontrollen, nicht automatisch eine juristische Schlussfolgerung.

Juniper- und Extreme-Systeme bildeten verschiedene technische Kontrollflächen. Ihre tatsächlichen Reaktionen sind für die Ursachenanalyse relevant. Ohne vollständige Herstellerfeststellungen und Versionen wäre eine pauschale Bewertung der Anbieter jedoch spekulativ.

Angeschlossene Netze kontrollierten ihre Ausweichpfade, Kapazitätsreserven, Sitzungspolitik und die Entscheidung, Verkehr abzuziehen. Diese Verantwortung ist ebenfalls begrenzt: Ein Teilnehmer kann eine Störung innerhalb des AMS-IX-Fabrics nicht selbst beheben. Er kann nur seine Abhängigkeit und seine Reaktion gestalten.

Endnutzer kontrollierten keine dieser Ebenen. Sie konnten weder Frame-Filter auf dem Exchange installieren noch BGP-Sitzungen verlagern oder herstellerübergreifende Tests verlangen. Diese Asymmetrie ist ein Grund, warum Infrastrukturbetreiber und angeschlossene Netze belastbare Wiederherstellungsbelege benötigen.