Zusammenfassung

  • Die CRTC-Bewertung datiert den Ausfall von 04:58 EDT am 8. Juli bis 07:00 Uhr am 9. Juli und nennt mehr als zwölf Millionen betroffene Mobilfunk- und Festnetzkunden [1].
  • In Phase sechs einer siebenstufigen Core-Modernisierung wurde ein ACL-Policy-Filter entfernt; vollständige BGP-Tabellen gelangten in OSPF und erschöpften CPU und Speicher [1].
  • Nach erfolgreichen früheren Phasen wurde das Risiko von Hoch auf Niedrig herabgestuft; zusätzliche Prüfung, höhere Freigabe und Labortest entfielen [1].
  • Das Managementnetz hing vom ausgefallenen IP-Core ab, und wichtige Standorte hatten keine Managementverbindung eines anderen Anbieters [1].
  • Ein belastbarer Abschluss braucht Routenobergrenzen, semantische Diff-Prüfung, automatisches Rollback, unabhängiges Management und Tests je kritischem Dienst.

Eine Filterlöschung öffnete die Protokollgrenze

Rogers führte seit Wochen ein siebenstufiges Upgrade des IP-Cores durch. Die CRTC-Bewertung verortet den Auslöser in Phase sechs: Ein Policy-Filter wurde aus der Konfiguration von Distribution-Routern gelöscht [1].

BGP transportiert Erreichbarkeit und Richtlinien zwischen autonomen Systemen und kann große Internettabellen tragen. OSPF verteilt internen Zustand innerhalb eines Betreibers. Eine begrenzte Auswahl zu redistribuieren kann sinnvoll sein; eine unbeschränkte vollständige BGP-Tabelle im Interior-Protokoll zwingt viele Geräte, nicht vorgesehenen Zustand zu verarbeiten.

Der Filter wurde um 04:43 EDT entfernt. Binnen zwei Minuten begannen Core-Gateways auszufallen. Um 04:58 verzeichnet die Chronologie eine Routenflut oberhalb der Verarbeitungsgrenze. CPU und Speicher waren erschöpft; Mobilfunk, Telefon, Internet, Unternehmensleitungen und 9-1-1 funktionierten nicht mehr. Die Wiederherstellung dauerte bis zum nächsten Morgen [1].

Die ersten Rogers-Mitteilungen waren allgemeiner. Am 8. Juli bestätigte der CEO Störungen in Mobil- und Festnetz und übernahm Verantwortung [4]. Am 9. Juli sprach das Unternehmen von einer Systemstörung nach Core-Wartung, fehlerhaften Routern, abgetrennten Geräten und umgeleitetem Verkehr [5]. Das dokumentiert den damaligen Kenntnisstand; der spätere CRTC-Bericht begrenzt die technische Aussage.

Redundanz übernahm denselben fehlerhaften Zustand

Mehrere Router schützen nicht, wenn alle dieselbe übergroße Zustandsmenge akzeptieren. Laut Bewertung erlaubte die Standardkonfiguration ohne Filter, BGP-Routen in OSPF zu verteilen. Genannt werden vier fehlende oder unzureichende Kontrollen: Überlastschutz, Begrenzung der redistribuierten BGP-Routen, manuelle und automatische Prüfung der Policy-Kommandos sowie automatisches Rollback [1].

Ein Redistribuierungsvertrag muss zulässige Routen, Zweck, Höchstzahl, Attribute, Empfänger und Verhalten bei Überschreitung benennen. Der Filter war keine kosmetische Zeile, sondern die ausführbare Grenze zweier Zustandssysteme.

Wenn ein ungültiger Zustand jedes redundante Gerät erreicht, bleibt die Fehlerdomäne gemeinsam. Eine harte Obergrenze, Vorabvalidierung oder automatisches Rollback muss die Kette beenden, bevor alle Ressourcen erschöpft sind. Ein Canary ist nur dann klein, wenn er seinen ungeprüften Zustand nicht sofort an den gesamten Core weitergibt.

Die Risikobewertung belohnte vergangene Erfolge

Das Gesamtprogramm war zunächst als Hoch eingestuft. Weil vorherige Phasen erfolgreich waren, senkte der Algorithmus Phase sechs auf Niedrig, einschließlich der Filterentfernung. Damit waren zusätzliche Kontrolle, höhere Genehmigung und Labortest nicht vorgeschrieben [1].

Der Erfolg einer Phase beweist nicht die Gleichwertigkeit der nächsten. Andere Geräte, Policy-Zweige und Reichweiten können betroffen sein. Eine gelöschte Zeile kann einen enormen Zustandsraum freigeben. Die Bewertung muss die Semantik des aktuellen Diffs erkennen: Filterlöschung, Umverteilung zwischen Protokollen und Reichweite bis in einen gemeinsamen Core verlangen hohe Prüfung.

Ein belastbarer Change-Datensatz verbindet vorherige und geplante Bytes, maschinenlesbare Routingabsicht, Laborergebnis, erwartete Routenzahl, Rolloutbereich, Abbruchbedingung, Rollback und Verantwortlichen. Der Canary darf den restlichen Core erst nach bestandenen Assertions erreichen.

Der gemeinsame Core vergrößerte die Wirkung

Mobil- und Festnetzzugang nutzten denselben IP-Core. Die Bewertung bezeichnet diese für Tier-1-Netze übliche Architektur nicht an sich als Designfehler. Sie sagt zugleich, dass die Konvergenz den Umfang extrem machte, weil eine Core-Störung beide Zugangsfamilien entfernte [1].

Konvergenz kann Auslastung verbessern und Doppelaufwand senken. Sie kann aber Sprache, mobile Daten, Festnetz-Internet, Unternehmen, Notrufe, Warnungen, Überwachung und interne Kommunikation hinter dieselbe Routingentscheidung legen. Verantwortlich ist nicht eine pauschale Ablehnung, sondern die nachgewiesene Entscheidung, welche Dienste einen einzelnen Kontrollfehler überstehen müssen.

Die CRTC-Zusammenfassung berichtet, Rogers habe die Trennung von Mobil- und Festnetz-Core beschlossen; zum Berichtszeitpunkt war sie nicht abgeschlossen [2]. Zwei Cores bleiben korreliert, wenn sie dieselbe riskante Automatisierung, Verwaltung oder Rolloutfolge teilen.

9-1-1 und öffentliche Warnungen waren ebenfalls betroffen. Rogers informierte die 9-1-1-Netzanbieter um 08:39, drei Stunden und 56 Minuten nach Beginn, und veröffentlichte die erste Kundenmeldung um 08:54 [1]. Der CRTC-Brief vom 12. Juli kritisierte fehlende frühe Hinweise auf alternative Notrufwege [3]. Teilweise geschwärzte Zahlen dürfen nicht ergänzt werden.

Das Management fiel mit dem Nutznetz aus

Der Fernzugriff nutzte den Produktions-Core. Nach dessen Ausfall konnten Techniker kritische Netzelemente nicht erreichen. Betriebszentrum und wichtige Außenstandorte hatten keine alternative Managementverbindung eines anderen Providers; Personal musste Geräte physisch aufsuchen [1].

Auch interne Kommunikation hing von Rogers-Diensten ab. SIM-Karten anderer Betreiber waren begrenzt, Fehlerprotokolle zunächst unzugänglich, und die Ursachenbestimmung dauerte ungefähr 14 Stunden. Mehrere Änderungen im Wartungsfenster erschwerten die Entscheidung, welches Ticket zurückzunehmen war [1].

Unabhängigkeit verlangt einen separaten physischen und logischen Weg, Identität außerhalb des Cores, lokale Konsolen, getrennte Logs und Kommunikation eines Drittanbieters. Der Beweis ist eine Übung mit isoliertem Produktions-Core, in der Beobachtung, Anmeldung, Änderung und Rückkehr weiterhin möglich sind.

RFC 6192 beschreibt allgemein den Schutz der Router-Control-Plane durch Identifikation, Filterung oder Begrenzung von Verkehr [8]. Es diagnostiziert Rogers nicht und definiert keine BGP-OSPF-Redistribution. Es unterstreicht aber, dass Weiterleitungs- und Steuerungskapazität unterschiedliche Ressourcen sind.

Verbesserungen brauchen Laufzeitnachweise

Der CRTC dokumentiert Schutz gegen Routenfluten, ein physisch und logisch getrenntes Managementnetz, Drittanbieter-Backup, Validierungswerkzeuge, neue Risikologik, mehr Labortests, verbessertes Rollback, klarere Rollen und alternative Kommunikation [1][2]. Die Gesamtmaßnahmen wurden als angemessen zur Ursachenbehebung bewertet [2].

Routingnachweise sind konfigurierte Obergrenze, beobachtete BGP- und OSPF-Zahlen, Ablehnung eines kontrollierten Überschreitungsversuchs und stabile Ressourcen. Change-Nachweise sind exakter Diff, unabhängige Freigabe, Labor, isolierter Canary und Rollback. Managementnachweise sind Zugriff, Identität, Logs und Kommunikation bei abgeschaltetem Core.

Dienste müssen extern geprüft werden: Mobilfunkregistrierung, Sprache, SMS, Daten, Festnetz, Unternehmen, 9-1-1, Warnungen und repräsentative Transaktionen. Eine zurückgekehrte Route beweist keinen erfolgreichen Anruf; ein grüner Router keine zugestellte Warnung.

ARIN führt AS812 aktuell als ROGERS-COMMUNICATIONS mit Rogers Communications Canada Inc. als Registrant [6]. PeeringDB veröffentlicht AS812 als Rogers Cable [7]. Diese Register belegen heutige Identität, nicht den privaten Core von 2022. Auf der Heng.lu-Fläche ist das Register das Hauptbuch; laufender Code und beobachtete Routen bestimmen die Kontinuität. Administrative Freigaben müssen mit zeitgebundenen Netzbeobachtungen abgeglichen werden.

Quellen

  1. https://crtc.gc.ca/eng/publications/reports/xonarp2023.htm
  2. https://crtc.gc.ca/eng/publications/reports/xona2024.htm
  3. https://crtc.gc.ca/eng/archive/2022/lt220712.htm
  4. https://about.rogers.com/news-ideas/a-message-from-tony-staffieri-president-and-ceo-at-rogers/
  5. https://about.rogers.com/news-ideas/a-message-from-rogers-president-and-ceo/
  6. https://rdap.arin.net/registry/autnum/812
  7. https://www.peeringdb.com/api/net?asn=812
  8. https://www.rfc-editor.org/rfc/rfc6192.html