Zusammenfassung

  • Gegen 02:24 UTC am 6. November 2012 stellte Cloudflare fest, dass Google-Dienste aus Teilen des Internets nicht erreichbar waren. Ein veröffentlichter Pfad verlief über AS4436, PCCW/AS3491 und Moratel/AS23947 zum legitimen Google-Ursprung AS15169 [1].
  • Cloudflare beschrieb eine begrenzte Unterbrechung von rund 27 Minuten und schätzte, dass 3-5 Prozent der Internetbevölkerung betroffen gewesen sein könnten, mit stärkerer Wirkung um Hongkong. Das ist eine Cloudflare-Schätzung, keine unabhängige Vollerhebung [1].
  • RFC 7908 führt den Moratel-PCCW-Vorfall als Typ-4-Leak auf: Von einem Peer gelernte Präfixe wurden an einen Transitprovider weitergegeben und überschritten den beabsichtigten Geltungsbereich [2].
  • Cloudflare hielt zunächst eine fehlerhafte Ankündigung für wahrscheinlich. Ein Update gab Moratels Aussage wieder, ein unerwarteter Hardwarefehler habe den abnormalen Zustand ausgelöst; böswillige Absicht habe nicht vorgelegen [1]. Die öffentliche Evidenz klärt die interne Fehlerkette nicht vollständig.
  • Die Verantwortung liegt auf beiden Seiten. Moratel musste unzulässige Exporte verhindern; PCCW musste erkennen, dass die empfangenen Pfade nicht als normale Kundenrouten weitergegeben werden durften.

Was die zeitnahe Beobachtung zeigt

Cloudflare berichtete, dass Mitarbeiter die Nichterreichbarkeit gegen 02:24 UTC bemerkten. Das erste Symptom wirkte wie ein DNS-Problem, weil aus dem eigenen Netz selbst 8.8.8.8 nicht erreichbar war. Ein Traceroute zeigte jedoch eine Moratel-Adresse in Indonesien. Für Verkehr aus Kalifornien zu Google war dies ein unerwarteter Umweg, sodass sich die Untersuchung auf die BGP-Steuerung verlagerte [1].

Der dokumentierte Pfad für ein Google-Präfix enthielt AS4436, AS3491, AS23947 und AS15169. AS15169 blieb der legitime Ursprung. Es handelte sich nicht um den einfachen Fall, dass ein fremdes Netz Google als Ursprung ausgab. Der Fehler lag in der Mitte des Pfades: Eine formal plausible Route überschritt eine operative und wirtschaftliche Grenze, die sie nicht hätte überschreiten dürfen.

Cloudflare erklärte, einen Kontakt bei Moratel informiert zu haben. Die ungewöhnliche Ankündigung wurde gegen 02:50 UTC korrigiert; etwa drei Minuten später normalisierte sich das Routing [1]. Die kurze Dauer macht den Vorfall nicht bedeutungslos. Zielsysteme können gesund bleiben, während Nutzer sie wegen eines fehlerhaften Interdomain-Pfades nicht erreichen. Anwendungs-, DNS- und Supportteams suchen dann im eigenen System, obwohl die sichtbare Ursache in einer externen Routingbeziehung liegt.

Die Reichweite der Aussage bleibt begrenzt. Cloudflare war ein wertvoller operativer Beobachter, aber kein vollständiger Sensor für alle Nutzer, Netze und Google-Produkte. Die Schätzung von 3-5 Prozent muss als solche gekennzeichnet bleiben. Auch die Ursache ist nicht abschließend belegt: Der erste Text vermutete eine fehlerhafte Eingabe, das spätere Update überlieferte Moratels Hardwareerklärung. Ohne Routerlogs, Hardwarealarme, Konfigurationshistorie und interne Zeitleiste kann niemand außerhalb der Betreiber entscheiden, ob Hardware, Software, Konfiguration, Failover oder deren Zusammenspiel zuerst die Policy durchbrach.

Warum RFC 7908 von Typ 4 spricht

BGP ermöglicht autonomen Systemen, Erreichbarkeit auszutauschen. Jedes autonome System trägt eine ASN und setzt eigene Richtlinien um. Eine Ankündigung enthält Präfix, AS_PATH und weitere Attribute. Der Router entscheidet, was er annimmt, bevorzugt und erneut ankündigt.

Diese Entscheidungen bilden Beziehungen ab. Ein Kunde kauft gewöhnlich Transit von einem Provider. Peers tauschen üblicherweise ihre eigenen Routen und Kundenrouten, bieten einander aber nicht automatisch vollständigen Transit. Eine Route kann deshalb auf der eingehenden Peering-Session zulässig sein und beim Export an einen Provider unzulässig werden.

RFC 7908 definiert einen Routenleak als Weitergabe über den beabsichtigten Umfang hinaus. Typ 4 beschreibt ein AS, das von einem lateralen Peer gelernte Routen an den eigenen Transitprovider weitergibt. Der RFC nennt den Moratel-PCCW-Leak von Google-Präfixen ausdrücklich als Beispiel [2].

Damit wird klar, warum reine Ursprungsvalidierung nicht genügt. AS15169 konnte am Ende des Pfades korrekt sein. Zu prüfen war die Beziehung: Durfte AS23947 diesen Pfad an AS3491 exportieren, und durfte AS3491 ihn als Kundenroute akzeptieren? Ein zulässiger Ursprung macht den Zwischenpfad nicht automatisch zulässig.

Nachweispflicht auf der Exportseite

Der exportierende Betreiber muss Session, Rolle, empfangene Routen, lokale Auswahl und tatsächlich zum Nachbarn gesendete Routen rekonstruieren können. Eigene Präfixe, autorisierte Kundenrouten, von Peers gelernte Routen und von Providern gelernte Routen müssen getrennt werden.

Wenn ein Hardwarefehler den Vorfall auslöste, muss ein belastbarer Abschluss dessen Wirkung auf die Policy erklären. Lud ein Neustart eine unvollständige Konfiguration? Aktivierte ein Ersatzpfad eine breitere Richtlinie? Wurde während der Konvergenz vorübergehend eine falsche Tabelle exportiert? Umging der Fehler einen Filter? „Hardwarefehler“ benennt eine Auslöserklasse, erklärt aber nicht, warum der Export offen ausfallen konnte.

Intent und laufender Zustand müssen verbunden werden. Ein Konfigurationsdiff hilft, reicht jedoch nicht. Nötig sind die tatsächlich angekündigten Routen, relevante Communities und Attribute, Geräteereignisse, Zeitstempel, Änderungsverantwortliche und die Rücknahmesequenz. Erst diese Daten zeigen, ob die Reparatur den Kontrollpfad geschlossen oder nur die sichtbare Route entfernt hat.

Nachweispflicht beim Upstream

Cloudflare beschrieb PCCW als Moratels Upstream, der den empfangenen Routen vertraute und sie weitergab [1]. Aktuelle RDAP-Daten identifizieren AS3491 als PCCWG-APAC-HK und verknüpfen es mit PCCW Global (HK) Limited [6]. Das stützt die heutige Identität, rekonstruiert aber nicht jeden Vertrags- und Sessionaspekt von 2012.

Ein Transitprovider ist keine passive Leitung. Er entscheidet, welche Kundenankündigungen akzeptiert, wie sie klassifiziert und wohin sie weitergegeben werden. Dafür braucht er autorisierte Präfixe und Ursprünge, einen erwarteten Kundenkonus, zulässige Pfadmuster, Routenlimits, Alarme und kontrollierte Ausnahmen.

Wenn ein Kunde legitimerweise viele Drittrouten transportiert, ist ein einfacher Filter schwierig. Die Schwierigkeit erhöht die Bedeutung genauer Beziehungsdaten und häufiger Abstimmung. Sie hebt die Filterpflicht nicht auf.

Ein großer Upstream vergrößert den Wirkungskreis eines lokalen Fehlers. „Der Kunde hat es angekündigt“ beendet die Verantwortung daher nicht. Das Produkt des Upstreams ist kontrollierte Weitergabe. Er muss zeigen können, wann die Route ankam, warum sie akzeptiert wurde, wie sie bevorzugt und an welche Nachbarn sie verteilt wurde.

Register und laufende Realität

Das aktuelle APNIC-RDAP identifiziert AS23947 als MORATELINDONAP-AS-ID und verbindet es mit PT. Mora Telematika Indonesia [5]. Der Eintrag für AS3491 nennt PCCWG-APAC-HK und PCCW Global (HK) Limited [6]. Solche Register sichern Identität, Kontakt und Kontinuität von Nummernressourcen.

Sie zeigen nicht, was ein Router um 02:24 UTC ausführte. Ein Register sagt, wer eine ASN betreibt; es zeigt weder die aktive Policy noch die über eine Session ausgegebenen Routen. Hier liegt die Heng.lu-Oberfläche: Das Register ist Hauptbuch und Verwalter, kein Ersatz für das laufende Netz. Rechenschaft entsteht erst, wenn Ressourcenidentität, beabsichtigte Beziehung und ausgeführter Zustand abgeglichen werden.

Die historische RIPEstat-Antwort für 8.8.8.0/24 zeigt AS15169 am abgefragten Tag als sichtbaren Ursprung [4]. Mit einer Granularität von acht Stunden kann sie einen wenige Minuten dauernden Leak-Pfad nicht belegen. Für den abnormalen Pfad stützt sich der Artikel auf Cloudflares zeitnahe Beobachtung, für die Klassifikation auf RFC 7908.

Kontrollen mit sicherem Ausfall

Jede externe BGP-Session braucht explizite Import- und Exportregeln. Eine fehlende Policy darf nicht bedeuten, die vollständige Tabelle anzunehmen oder anzukündigen. Von einem Peer gelernte Routen dürfen nicht standardmäßig an einen Provider exportiert werden.

Ein Provisionierungsregister sollte Nachbar-ASN, Rolle, autorisierte Präfixe oder Ursprünge, Limits, Änderungsverantwortliche, Freigabe und Ablauf einer Ausnahme enthalten. Automatisierung muss daraus Policy erzeugen und anschließend verifizieren, dass der laufende Router der Freigabe entspricht.

Auch die tatsächlich angekündigte Menge muss überwacht werden. Unerwartete Drittursprünge, ein sprunghafter Anstieg der Routenzahl, ein AS_PATH gegen die Sessionrolle oder widersprüchliche Communities sollten Eindämmung auslösen.

RFC 9234 definierte Jahre später BGP Roles und das Only-to-Customer-Attribut. Diese Mechanismen machen Beziehungen maschinenlesbarer und können rollenwidrige Weitergabe erkennen helfen [3]. Sie sind Kontext für heutige Kontrollen, kein Beleg für einen Einsatz bei Moratel oder PCCW im Jahr 2012.

Externe Beobachtung bleibt nötig. Route Collectors oder entfernte Netze können eine überschrittene Grenze erkennen, obwohl beide Betreiber ihre lokale Sicht für korrekt halten. Dieses Signal muss mit Adj-RIB-In, lokaler Entscheidung und Adj-RIB-Out korreliert werden, nicht deren interne Evidenz ersetzen.

Ein überprüfbarer öffentlicher Abschluss

Ein belastbarer Abschluss beginnt mit einer UTC-Zeitleiste: erstes Nutzersymptom, interner Alarm, bestätigte abnormale Route, Kontakt zwischen Betreibern, Ende der Ankündigung, beobachteter Rückzug und stabile Erholung. Beobachtung und Diagnose sind getrennt auszuweisen.

Danach sollte die Fehlerklasse beschrieben werden, ohne sensible Konfiguration zu veröffentlichen: Peer-Route an Transit exportiert, Policy fehlend, veraltet oder umgangen, Kundenfilter des Upstreams zu weit. Wo der interne Auslöser unklar bleibt, muss diese Unsicherheit sichtbar bleiben.

Schließlich braucht die dauerhafte Änderung einen Test. Freigegebene Beziehungsabsicht, generierte Policy, Hash des Deployments, Negativtest mit einer gleichartigen Route, Alarmgrenze, Rollback-Verantwortlicher und externe Bestätigung des Rückzugs bilden eine überprüfbare Kette. Die Wiederherstellung beendet den Notfall. Der Nachweis, dass derselbe Pfad abgelehnt wird, beendet die Kontrolllücke.

Quellen

  1. https://blog.cloudflare.com/why-google-went-offline-today-and-a-bit-about/
  2. https://www.rfc-editor.org/rfc/rfc7908.txt
  3. https://www.rfc-editor.org/rfc/rfc9234.txt
  4. https://stat.ripe.net/data/routing-history/data.json?resource=8.8.8.0/24&starttime=2012-11-06T00:00:00&endtime=2012-11-07T00:00:00
  5. https://rdap.apnic.net/autnum/23947
  6. https://rdap.arin.net/registry/autnum/3491