要約

  • CRTC評価は障害を7月8日04時58分EDTから9日07時00分までとし、移動体と固定を合わせて1,200万超の顧客がサービスを失ったとしている [1]。
  • 7段階のコア更新の第6段階でACLポリシーフィルターが削除され、完全なBGP表がOSPFへ再配送されて、コアルーターのCPUとメモリーを使い切った [1]。
  • 先行段階の成功後、第6段階のリスクは「高」から「低」へ下げられ、追加審査、上位承認、ラボ試験が不要になった [1]。
  • 管理ネットワークは故障したIPコアに依存し、重要拠点には他事業者による代替管理接続がなかった [1]。
  • 信頼できる終結には、経路数上限、変更差分の意味審査、自動ロールバック、帯域外管理、重要サービスごとの負の再現試験が必要である。

一つのフィルター削除がプロトコル境界を開いた

Rogersは障害前の数週間、IPコアを7段階で更新していた。CRTC評価は、第6段階でディストリビューションルーター設定のポリシーフィルターを削除したことを起点としている [1]。

BGPは自律システム間の到達性とポリシーを扱い、巨大なインターネット経路表を運べる。OSPFは一つの運用ドメイン内で内部状態を共有する。必要な一部経路を再配送することはあり得るが、制限のない完全なBGP表を内部プロトコルへ入れれば、多数の装置が想定外の状態を処理することになる。

フィルターは04時43分EDTに削除された。2分以内にコアゲートウェイが故障し始め、04時58分には処理能力を超える経路がコアへ流入した。CPUとメモリーが枯渇し、移動体、家庭電話、インターネット、企業固定接続、9-1-1が機能しなくなった。復旧は翌朝まで段階的に続いた [1]。

初期のRogers発表はより一般的だった。7月8日、CEOは移動体と固定の障害を認め、責任を引き受けた [4]。9日には、コア保守後にルーターが不調となり、対象機器を切り離してトラフィックを迂回したと説明した [5]。これは当時の認識を示す資料であり、詳細な技術機構は後のCRTC評価に従うべきである。

冗長性が同じ状態を複製した

複数のルーターがあっても、すべてが同じ過大な状態を受け取れば保護にならない。評価は、フィルターがなくなると標準設定がBGP経路をOSPFへ流す状態だったと述べる。関連する不足として、コアルーターの過負荷保護、再配送経路数の制限、ポリシーコマンドの手動・自動監査、自動ロールバックを挙げている [1]。

再配送契約には、通過可能な経路、その理由、最大数、保持属性、受信装置、超過時の動作を明記する必要がある。フィルターは設定の飾りではなく、二つの状態系を分ける実行境界だった。

装置、拠点、ベンダーが複数でも、無効状態がすべてへ届けば共通障害領域である。経路上限、配送前の検証、または自動ロールバックは、全コアの資源が尽きる前に連鎖を止めなければならない。試験装置が即座に危険な状態を全体へ広告するなら、それは安全なカナリアではない。

リスク評価は以前の成功に引っ張られた

7段階の作業は当初「高」リスクだった。しかし先行段階が成功したため、第6段階は「低」へ格下げされた。フィルター削除も追加審査、上位承認、ラボ試験の対象外になった [1]。

前段階の成功は、次の変更が同等である証拠ではない。段階ごとに装置、ポリシー分岐、到達範囲が変わる。一行の削除でも、許容される状態空間は大幅に広がり得る。現在の差分がフィルター削除、プロトコル間再配送、共通コアへの到達を含むなら、過去の成功に関係なく高い審査が必要である。

変更記録は、前後の設定、機械可読の経路意図、ラボ結果、予想経路数、展開範囲、停止条件、ロールバック、責任者を結び付ける。カナリアの状態が検証前に全コアへ広がらない設計も必要になる。

共通コアが影響を全国規模にした

移動体と固定のアクセス網は同じIPコアを使っていた。評価は、この種のTier 1構成自体を設計欠陥とはしていない。一方で、一つのコア障害が両方を失わせたため、収束構成が影響範囲を極端にしたと結論付ける [1]。

収束は設備の重複を減らし、利用率を高められる。しかし音声、移動体データ、固定インターネット、企業、緊急通報、公共警報、監視、社内通信を同じ経路判断の後ろへ置く。重要なのは収束を一律に否定することではなく、一つの制御障害でも存続すべきサービスを決め、独立性を演習で証明することである。

CRTC要約は、Rogersが移動体と固定のIPコア分離を決めたと記す。報告時点では完了していなかった [2]。二つのコアも、危険な自動化、管理経路、展開順序を共有すれば相関したままである。

9-1-1と公共警報も影響を受けた。Rogersが9-1-1網事業者へ通知したのは開始から3時間56分後の08時39分で、最初の顧客向け案内は08時54分だった [1]。CRTCの7月12日書簡は、緊急通報の代替方法を早期に案内しなかった点を問題視した [3]。一部の正確な通話数は非公開なので推測で補ってはならない。

管理経路も同時に失われた

遠隔管理は本番IPコアに依存していた。コアが故障すると、技術者は重要装置へ到達できなかった。運用センターと重要遠隔拠点には、他社回線による代替管理接続がなく、現地での物理アクセスが必要になった [1]。

事故対応者の通信もRogersのサービスに依存していた。他社SIMは限られ、故障ルーターのログへ当初アクセスできず、根本原因の特定に約14時間を要した。同じ保守時間帯の複数変更が、どのチケットを戻すかの判断も難しくした [1]。

管理独立性には、別の物理・論理経路、コア外の認証、ローカルコンソール、別保管のログ、他事業者による通信が必要である。証明は図面ではない。本番コアを切り離した演習で、観測、認証、変更、復帰を実行できることだ。

RFC 6192は一般原則として、正当な制御トラフィックを識別し、不要なトラフィックをフィルターまたはレート制限して、ルーター制御面を安定させる方法を説明する [8]。Rogersの障害やBGPからOSPFへの再配送を診断する文書ではないが、転送能力と制御能力が異なる資源だという境界を示す。

改善策は稼働証拠で検証する

CRTCは、経路洪水防止、物理・論理的に別の管理網、第三者の予備接続、設定検証ツール、新しいリスク評価、追加ラボ試験、自動ロールバック、事故役割と代替通信の改善を記録した [1][2]。評価は、これらの組み合わせが根本原因への対応として妥当だとした [2]。

経路安全の証拠は、設定上限、BGPとOSPFの実測数、制御した超過試験の拒否、CPUとメモリーの安定である。変更安全は、正確な差分、独立承認、ラボ、隔離カナリア、自動復帰で示す。管理安全は、本番コア停止中の別回線、認証、ログ、通信で示す。

サービスは外部から、移動体登録、音声、SMS、データ、固定、企業、9-1-1、公共警報、代表取引ごとに確認する。経路復帰は通話成功を意味せず、装置の緑表示も警報到達を意味しない。

現在のARIN RDAPはAS812をROGERS-COMMUNICATIONSとし、登録者をRogers Communications Canada Inc.としている [6]。PeeringDBはAS812をRogers Cableとして公開する [7]。これは現在の公開識別台帳であり、2022年の内部コアを再現しない。Heng.luの観点では、台帳は権利と識別を記録し、稼働コードと観測経路が継続性を決める。承認記録は時刻付きの実ネットワーク観測と照合されなければならない。

出典

  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