Virgin Media の2023年 AS5089 障害、経路消失とエッジ遮断が説明責任の試金石に

概要

• 2023年4月4日、技術オブザーバーにより AS5089 と特定される英国の Virgin Media は、広域インターネットからの自社ネットワークとサービスへの到達可能性を損なう2つの大規模な障害を経験した。[1][2]
• Cloudflare は、UTC 00:30頃にトラフィックがほぼゼロに低下し、その後の不安定な回復を観測した。ThousandEyes は、最初の障害が約00:30から07:00 UTC まで、2回目が約15:20から17:30 UTC まで発生したと説明している。[1][2]
• ThousandEyes は、観測されたトラフィック損失の大部分が、Virgin Media ネットワークへの有効な BGP 経路の欠如に起因するとしている。また、一部のプロバイダが AS5089 への経路を保持していたが、Virgin Media のエッジでトラフィックが破棄されるという異なる状況も観測した。[2]
• これらの観測結果は、経路と転送の障害モードを確立するが、開始コマンド、デバイス、ベンダ、人物、保守作業、サイバー攻撃、その他の根本原因を特定していない。
• 同日中の再発により、復旧の証拠が中心となる。経路の再現は安定したサービス復旧と同じではなく、内部的なグリーン状態は、多様な外部ネットワークがエッジに到達し通過できることの証明にはならない。
• 説明責任は実質的な制御に従う。Virgin Media は経路生成、経路撤回、エッジポリシー、内部転送、復旧手順、インシデント開示、顧客補償を制御していた。ピアは自身の経路選択と証拠を制御した。計測プロバイダは独立した観測を提供したが、非公開の内部状態を再構築することはできなかった。
• 現在の PeeringDB、RIPE 由来、およびルーティングの記録は、AS5089 とその相互接続の文脈を特定する。これらは2023年4月4日時点のネットワークの凍結コピーではなく、インシデントのテレメトリーとして使用してはならない。[6][7][8][9][10][11]
• RFC 4271、RFC 7454、RFC 8212、MANRS はプロトコルと運用の文脈を提供するが、Virgin Media がどの制御を展開していたか、または特定の制御が事象を防止できたことを証明するものではない。[12][13][14][15]
• 信頼できる説明責任の記録は、経路の可用性、パケット転送、顧客から見えるサービスの3つの時計を整合させるべきである。正確な観測を保存し、推論をラベル付けし、未知を明らかにし、オペレータのみが生成できた証拠を文書化すべきである。

インシデントは2つの障害であり、漠然とした1日のダウンタイムではない

大規模ネットワーク障害は、開始時刻、終了時刻、影響を受けた顧客数で要約されることが多い。この形式は便利だが、責任を決定するメカニズムを消し去る可能性がある。Virgin Media の障害は、2つの観測期間、いくつかの不安定な回復段階、少なくとも2つの外部から見える障害状態として理解する方が適切である。

Cloudflare のトラフィック表示は、最初の大規模な崩壊を4月4日の UTC 00:30頃としている。Virgin Media に関連するトラフィックはほぼゼロに低下した。サービスは1回のクリーンな遷移で復旧しなかった。グラフと付随する説明は、部分的な回復、さらなる低下、後の別の障害を記述していた。この記録の重要性は、Cloudflare がすべての Virgin Media 顧客を見られたことではない。見られなかった。その価値は、大規模な外部ネットワークが Virgin Media の自律システムに関わるトラフィックの急激な変化を観測した点にある。[1]

ThousandEyes は、最初の障害が約00:30から07:00 UTC まで続いたと説明した。BGP 経路撤回、トラフィック損失、断続的な回復期間を記録した。2回目の障害は約15:20 UTC に始まり、約17:30 UTC に解決した。同様の外部特性を共有していた。この時系列は、到達可能性が2回失われたという主張を裏付ける。同じ内部コンポーネントや変更が両方の事象を開始させたことを証明するものではない。[2]

同時期の報道が顧客向けの側面を捉えた。The Register は広範なブロードバンド障害と、Virgin Media が顧客に問題が発生していると認めたことを報じた。この証拠は、ルーティングの観測がサービス影響と一致したことを示すのに役立つ。ソーシャルメディアの報告や企業声明を完全な技術的事後分析に変えるものではない。[3]

2つの障害の区別が重要なのは、間に回復が発生したためである。最初の事象後にサービス復旧を報告するオペレータは、ネットワークが再び到達可能であり、正しく転送し、期待されるトラフィックを運ぶのに十分安定しているという運用上の主張を行っている。後の再発は、トリガーが除去されていなかったこと、回復基準が狭すぎたこと、または別の関連する障害が残存していたことを示唆する可能性がある。公開記録は、どの説明が正しいかを示してはいない。

したがって、本記事はすべての症状を1つの創作されたシーケンスに組み合わせない。観測された期間を、境界のある説明責任の事例として扱う。最初の問いは、外部の世界が何を見ることができたかである。2つ目は、Virgin Media だけが知り得たことである。3つ目は、どの証拠がそれら2つの視点を結びつけるべきかである。

AS5089 はブランドの詳細ではなく、運用上の境界である

自律システム番号は、他のネットワークに対して一貫したルーティングポリシーを提示するネットワークを識別する。内部のルータ、ケーブル、アクセスセグメント、商用製品のすべてを説明するものではない。しかし、ドメイン間の説明責任のための有用な境界を確立する。他のネットワークは自律システムと到達可能性情報を交換し、結果の経路に従ってトラフィックを転送する。

技術情報源は、英国の Virgin Media を AS5089 と結びつけている。現在の PeeringDB データは、その ASN の下で Virgin Media を説明し、相互接続フットプリント、AS-SET、パブリックピアリング情報を記録している。現在の BGP および RIPE 由来のツールもまた、AS5089 を Virgin Media Limited と関連付け、アナウンスされたネットワークリソースを示している。これらの記録は、事象を正しいネットワーク識別に結びつけるのに役立つ。[6][7][8][9][10][11]

これらは慎重に使用しなければならない。現在の PeeringDB ページは、オペレータがレコードを更新した後に変更される可能性がある。現在のプレフィックスは、2023年4月にアナウンスされたものとは異なる可能性がある。現在の RPKI ステータスは、それ自体では、障害中の経路のステータスについて何も語らない。レジストリオブジェクトは管理情報とルーティング情報を記録するが、特定の瞬間にパケットがエッジを通過したことを証明するものではない。

レジストリとネットワークディレクトリは証拠記録である。リソース保有者、ルーティングオブジェクト、コンタクト経路の特定に役立つ。それらは、実行中のネットワークを健全にする宣言ではない。運用の真実は、ピアが実際に受信する経路と、ネットワークが実際に受け入れて転送するパケットに現れる。

AS 境界はまた、"インターネット"という言葉に責任が解消されるのを防ぐ。インターネットは独立して運用されるネットワークの集合体である。リモートのコンテンツプロバイダは稼働中のサーバを持つかもしれない。トランジットプロバイダは AS5089 への経路を運ぶかもしれない。顧客デバイスはローカルで機能するかもしれない。しかし、アクセスネットワークへの経路が消失すれば、リモートネットワークはトラフィックを配送できない。経路が残っていても、オペレータのエッジがパケットを破棄するなら、見える経路は依然としてサービスを生み出さない。

Virgin Media は、すべてのリモートピア、リゾルバ、アプリケーション、顧客デバイスを制御していなかった。自らの経路生成、エッジ動作、内部転送、復旧プロセスは制御していた。それが、公正な説明責任分析を開始すべき実質的な制御境界である。

経路撤回が到達可能性を消失させた

BGP は、自律システムがどのアドレスプレフィックスに到達可能で、どの経路を通るかについての情報を交換することを可能にする。RFC 4271はプロトコルモデルを定義している。経路はアプリケーションが動作する保証ではないが、使用可能な経路がなければ、トラフィックは通常行き場を失う。[12]

ThousandEyes は、4月4日の障害中のトラフィック損失のほとんどが、Virgin Media ネットワークへの有効な BGP 経路の欠如と関連していたと観測した。経路が撤回されると、他のネットワークはもはやそれらの経路を選択できなくなる。影響を受けるプレフィックス内のアドレス宛てのパケットは、上流で破棄されるか、接続試行の繰り返しの後に失敗する。[2]

これは単なる付随的な技術的症状ではない。経路生成は、アクセスプロバイダが自らのネットワークをグローバルインターネットから到達可能にする主要な方法の1つである。撤回は、意図的な安全措置、セッション喪失の結果、ポリシー成果、自動化の効果、または他の障害の結果である可能性がある。公開情報源は、ここでどのメカニズムが働いたかを立証していない。

根本原因の詳細がなくても、説明責任が不可能になるわけではない。問いが変わる。どのプレフィックスが消えたのか？どのピアが最初に撤回を受信したか？すべての外部経路が同時に消えたのか、それともグループに分かれてか？IPv4 と IPv6 は同様に動作したか？どの監視システムが変化を検出したか？どの内部健全性信号が再アナウンスを許可したか？顧客向けの復旧が宣言される前に、どの受け入れテストに合格しなければならなかったか？

これらの質問は証拠の要求であり、非難ではない。観測可能な振る舞いを、オペレータが保持すべき記録に対応付ける。ルートサーバ、エッジルータ、自動化コントローラ、監視システムは、タイムスタンプ付きで変更を記録できる。変更管理はデプロイメントが進行中であったかどうかを記録できる。外部ルートコレクタは部分的な外部の見え方を示すことができる。単一の記録で完全なものはないが、合わせることで防御可能な時系列を確立できる。

運用上のリスクは1つのプロトコルセッションよりも大きい。アクセスネットワークは、複数のエッジにわたって多くのプレフィックスをアナウンスすることがある。幅広い経路を撤回する障害は、サービス、顧客アドレス空間、DNS 基盤、管理システム、サポートチャネルを一度に隔離する可能性がある。影響を受ける人々は、共有された障害が到達可能性であるにもかかわらず、異なるアプリケーションエラーを経験する。

したがって、説明責任にはスコープとタイミングが必要である。オペレータは、どのアドレスリソースが影響を受けたか、どのエッジが状態を変えたか、どのサービスがそれらのリソースに依存していたか、どの経路が利用可能なままだったかを述べることができるべきである。"ブロードバンドがダウンした"という大まかな声明では、地域的なアクセス障害と自律システム全体の隔離を区別するには不十分である。

見える経路が常に機能する転送を生むとは限らなかった

ThousandEyes の説明で最も重要な詳細は、経路撤回がすべての観測された障害を説明しなかったことだ。一部のプロバイダは、Virgin Media ネットワークへトラフィックをルーティングすることが依然として可能であったと伝えられている。それらのケースでは、トラフィックは Virgin Media のエッジで破棄された。ThousandEyes は、このパターンが、おそらくコントロールプレーンを含むシステム的な苦境を示唆していると説明した。[2]

"示唆している"という言葉が重要である。外部の観測者は、経路が残っており、パケットが境界付近で失敗することを見ることができるが、オペレータの内部制御状態を検査することはできない。エッジでの破棄は、いくつかの種類の状態から生じ得る。転送状態が欠落している、内部経路が利用不能である、インタフェースが損なわれている、ポリシーがトラフィックを拒否している、容量が崩壊している、依存関係が故障している、などだ。証拠なしに1つのメカニズムを選択することは、観測をフィクションに変えることになる。

それでも、限定的な結論は強力である。経路の存在とパケット配送は乖離していた。それらの経路について、グローバルルーティングシステムは AS5089 が到達可能であるという見かけ上の約束を運んでいたが、オペレータのエッジは対応するサービスを提供しなかった。

この乖離は繰り返し発生するネットワークリスクである。コントロールプレーンの状態は有効に見えても、データプレーンが故障することがある。BGP セッションは確立したままで、ネクストホップが使用不能であることがある。プレフィックスはルーティングテーブルに残っているが、パケットが破棄されることがある。内部ダッシュボードは、プロセスが生きているためにエッジを利用可能とマークすることがあるが、エンドツーエンドのプローブは失敗する。

説明責任の対応は、対となる証拠を要求することである。経路の健全性は、期待されるプレフィックスが期待されるピアを通じて見えるかどうかを問う。転送の健全性は、代表的なパケットがエッジを越えて宛先に到達するかどうかを問う。アプリケーションの健全性は、実際のサービスがトランザクションを完了するかどうかを問う。オペレータは、これらの階層を1つのグリーンインジケータに潰してはならない。

外部プローブは、変更されたシステムの外部からサービスをテストするため貴重である。1つのピアの見解をインターネット全体と誤解しないように、十分に多様であるべきだ。計測には、経路が撤回されたプロバイダと経路を保持したプロバイダの両方を含めるべきである。関連する地域、アドレスファミリ、サービスクラスをカバーすべきである。

結果は単一の稼働時間数ではなく、マトリックスであるべきだ。経路は存在しないかもしれず、存在するかもしれない。パケットはエッジの前、エッジ、または進入後に失敗するかもしれない。アプリケーションは、トランスポートが成功しても失敗するかもしれない。このマトリックスは、応答者が経路広告を復元するか、内部転送を修復するか、負荷を削減するか、故障しているエッジを隔離するか、あるいはより狭い範囲を伝達するかを決定するのに役立つ。

復旧は3つの時計にわたって証明されなければならない

4月4日の再発は、"復旧した"の意味を中心的なものにする。復旧は1つのタイムスタンプではない。それは少なくとも3つの時計の間の合意である。ルーティング、転送、そして顧客から見えるサービスだ。

ルーティング時計は、プレフィックスがいつ撤回され、再アナウンスされ、ピアに受け入れられたかを記録する。BGP アップデートストリーム、ルートコレクタの観測、ルッキンググラスのチェックを含むことができる。BGP の伝搬は分散しているため、異なる観測者が異なるタイミングで変化を目にする可能性がある。経路の最初の再出現は、グローバルな収束を証明しない。

転送時計は、トラフィックが実際にオペレータの境界を越え、代表的な宛先に到達したかどうかを記録する。パケットロス、レイテンシ、パストレース、アクティブプローブを含む。転送状態が不完全であれば、経路の再アナウンスより遅れる可能性がある。また、経路が見えたままでも、独立して失敗することがある。

顧客時計は、ユーザがサービスを失ったとき、サポートチャネルが問題を認識したとき、ステータス通知が変更されたとき、顧客が実際のタスクを完了できたとき、補償や苦情プロセスが利用可能になったときを記録する。ネットワーク状態だけでなく、商業的および社会的な結果を反映する。

説明責任を果たす復旧は、これらの時計を整合させるべきである。オペレータは、経路の可視性が一貫して維持され、多様なネットワークからの転送プローブが成功し、顧客影響指標が期待される範囲に戻る安定化間隔を指定すべきである。最初の復旧がその間隔が経過する前に受け入れられたのであれば、その理由を記録が説明すべきである。

公開情報源は、Virgin Media の内部受け入れ基準を明らかにしていない。それらは、サービスが改善し、その後同様の大規模障害が再発したことを示している。それだけで、復旧がトラフィックの一時的な復帰として定義されたのか、安定したエンドツーエンドの到達可能性として定義されたのかを問うに十分である。

答えは推測されてはならない。インシデント後の記録は、境界のあるタイムラインを公開することでそれを提供できる。何が変更されたか、どの信号が復旧をトリガーしたか、どの信号が後に悪化したか、同じコンポーネントが関与していたか、どのような追加の検証が追加されたか。セキュリティや商業上の懸念が構成の開示を妨げる場合でも、集約された経路と健全性の証拠は公開できる。

このアプローチは、パフォーマンス的な透明性を避ける。経路と転送のタイムスタンプのない長い物語は、誠実に見えながらも主な主張を検証不可能にする。3つの時計を整合させる短い記録の方が、より大きな説明責任を提供できる。

2度目の障害はロールバックを証拠の問題に変える

部分的な復旧後の再発は、応答者に難しい選択を突きつける。原因を取り除いたと信じているかもしれないし、症状を回復しただけかもしれない。この区別は、ネットワークを通常運用に戻すべきか、警戒状態に留めるべきかを決定する。

ロールバックはしばしば二元的なイベントとして扱われる。新しい状態が取り除かれたので、古い状態は安全であるに違いない、と。分散ネットワークはそれほど単純ではない。古い設定が戻っても、セッションが異なる速度で再収束する可能性がある。キャッシュされた、または生成された状態が持続するかもしれない。内部の依存関係が一緒に復旧しないかもしれない。元の事象によって別の障害が露出した可能性がある。

そのため、ロールバックは観測可能な不変条件に結び付けられるべきである。期待されるプレフィックスが存在すること。予期しない撤回や経路のチャーンが停止すること。複数の外部ネットワークからエッジ転送が機能すること。内部ネクストホップが有効であること。容量が復帰する負荷を支えられること。顧客に見えるエラー率が定義された間隔で安定したままであること。

RFC 7454は BGP に関する運用とセキュリティの実践を議論する。RFC 8212は eBGP ポリシーに対する明示的なデフォルト拒否の姿勢を推進する。MANRS はフィルタリング、調整、検証、グローバル検証の実践を説明する。これらの情報源は制御の種類を定義するのに有用であるが、特定の Virgin Media の制御が失敗したことを立証するものではなく、また1つの推奨事項を適用すればこの停止を防止できたことを証明するものでもない。[13][14][15]

教訓はより狭い。経路ポリシーと復旧には、明示的でテスト可能な条件が必要である。オペレータは、ピアが何をアナウンスすることを許可されているか、何をエクスポートするか、集約がアナウンスされる前にどの内部到達可能性が存在しなければならないか、どの独立した計測がロールアウトをブロックまたは逆転できるかを知っているべきである。

全国規模のアクセスプロバイダにとって、カナリア設計は特に重要である。変更は、より広範な展開の前に、1つのエッジ、1つの地域、1つのアドレスファミリ、または1つの制御されたプレフィックスグループに限定することができる。カナリアは管理ドメインの外部から観測されるべきである。経路や転送の不変条件が失敗した場合、自動化は展開を停止し、証拠を保存すべきである。

これらいずれも、本記事が変更が4月4日のインシデントを引き起こしたと主張することを要求するものではない。あらゆる説明の基準を設定するのである。原因がデプロイメントだった場合、オペレータは境界とロールバックを示すべきである。デバイスや依存関係の故障だった場合、冗長性が経路と転送サービスを維持しなかった理由を示すべきである。複数の条件が組み合わさった場合、検出と復旧がどのように変更されたかを示すべきである。

相互接続はプライベートな運用を共有リスクに変える

AS5089 は孤立して運用されているわけではない。その到達可能性は、他のネットワークとのセッションとポリシーに依存する。PeeringDB の現在の記録は、Virgin Media に関連する相互接続施設とエクスチェンジ参加を特定している。これらの詳細は現在の文脈であり、2023年のトポロジの再構築ではないが、大規模なアクセスネットワークに到達するために必要な運用境界の数を示している。[7]

ネットワークが経路を撤回すると、ピアは更新を処理し、代替が存在する場合は代替を選択しなければならない。エッジがトラフィックを受け入れるが転送できない場合、計測やオペレータ調整によって問題が明らかになるまで、ピアは障害のある経路にパケットを送り続ける可能性がある。したがって、インシデントは相互接続の両側に証拠の義務を生じさせた。

Virgin Media は、自らが生成する経路の正確性と有用性、およびそのエッジ背後での転送動作を制御していた。ピアは、何を受け入れたか、どのように経路を監視したか、オペレータに連絡できたかどうかを制御していた。計測プロバイダは、利用可能な観測地点のみを観測した。

この制御の分割は、インシデント調整に現れるべきである。ピアの報告は、どの経路を受信したか、どのセッションが維持されたか、どこでパケットが失敗したか、いつ動作が変化したかを述べるべきである。オペレータは、その見解が自身のテレメトリと一致するかどうかを認めるべきである。矛盾する観測は、早い段階で1つのタイムラインに正規化されるのではなく、保存されるべきである。

ここで連絡先データが重要となる。レジストリと PeeringDB の記録は、NOC やポリシーの連絡先を提供することができる。その価値は実用的である。影響を受けたネットワークは、行動を起こす権限のある人物に連絡できるか？存在するが監視されていないアドレスは、運用上の制御ではない。連絡経路は、レジストリをオペレータに対する統治の主張に変えることなく、テストされ維持されるべきである。

調整は顧客の復旧にも影響する。複数のプロバイダを持つコンテンツネットワークやエンタープライズ顧客は、障害のある経路からトラフィックを移行するかもしれない。一般家庭の顧客は、通常、インシデント中に代替のラストマイル自律システムを選択することができない。この非対称性は、アクセスプロバイダにより大きな継続性の責任を負わせる。

顧客は、制御できない AS 全体のアクセス障害を回避するようエンジニアリングしなかったことを責められるべきではない。大規模なピアは、自らのルーティングとエスカレーション手順をテストすべきではあるが、その備えがオペレータの正確な経路と転送状態に対する責任を消し去るものではない。

監視は障害のあるネットワークから独立していなければならない

ルーティングに影響を与える障害は、その診断と通信に使用されるツールも隔離する可能性がある。ステータスシステム、テレメトリコレクタ、認証サービス、サポートポータルが同じネットワークパスを共有するかもしれない。もしそうなら、オペレータは一度にサービスと証拠の両方を失う可能性がある。

したがって、独立した監視は、本番障害ドメインの外部に位置すべきである。外部ルートコレクタ、アクティブプローブ、サードパーティ計測は、他のネットワークが見ているものをテストできる。内部テレメトリはデバイスとポリシーの状態を説明するため依然として必要である。どちらの見解も単独では十分ではない。

Cloudflare の説明と ThousandEyes の分析は、外部観測の価値を示している。彼らは、Virgin Media の内部システムにアクセスすることなく、トラフィックの崩壊、経路の撤回、エッジの故障を検出できた。しかし、彼らのデータは、開始した内部イベントを特定することはできなかった。[1][2]

オペレータは、時間、プレフィックス、エッジ、アドレスファミリによって、外部と内部の証拠を相関させるべきである。時刻源は、応答者が記録を比較できるほど信頼性がなければならない。5分の時計の誤差は、経路撤回、転送障害、オペレータアクションの見かけの順序を歪める可能性がある。

監視には否認テストも必要である。経路が存在することを確認するだけでは不十分である。プローブは、代表的なプレフィックス内の宛先をテストすべきである。エッジが応答することを確認するだけでは不十分である。テストは、顧客トラフィックがそれを通過できることを検証すべきである。ポータルがネットワーク内部からロードすることを確認するだけでは不十分である。外部クライアントがそれに到達できるべきである。

設計目標は、完璧なグローバルビューを作り出すことではない。それは非現実的である。盲点を明示的にし、単一の障害ドメインが復旧を宣言するために使用されるすべての証拠を提供しないようにすることである。

公開情報開示は未知を保存すべきである

ネットワークの事後分析はしばしば相反する圧力に直面する。顧客は説明を求める。エンジニアは検証する時間を必要とする。セキュリティチームは詳細を制限するかもしれない。法務チームは責任を生みかねない声明を避けるかもしれない。結果として、運用上の証拠を提供しないほど広範な文言になることがある。

責任ある開示は、内容が空になることなく、境界を保つことができる。適切なレベルで、影響を受けたサービスとプレフィックス、観測された障害モード、経路撤回の期間、エッジ転送障害の期間、復旧手順、検証間隔、その後に変更された制御を述べることができる。

観測と推論を区別すべきである。"これらのプレフィックスグループへの経路が撤回された"は観測である。"コントロールプレーンの依存関係が苦境にあった"は推論かもしれない。"特定のベンダプロセスが失敗した"には直接的な証拠が必要である。

ここで使用されている公開情報源は、その区別を保存している。ThousandEyes は、エッジの動作が、おそらくコントロールプレーンに影響を与えるシステム的な苦境を示唆していると述べた。本記事は、その声明を確認されたコントロールプレーンの根本原因として書き換えていない。[2]

未知は可視のままであるべきだ。開始イベント、内部の決定者、正確なデバイスセット、完全な顧客範囲、両方の障害が1つの原因を共有していたかどうか、永続的な是正策は、情報源のセットによって確立されていない。これらを保存することは正確性の一形態であり、弱点ではない。

したがって、説明責任の問いは、欠落した証拠へのアクセスを持つ当事者が適切な記録を作成したかどうかである。外部のアナリストは、自信を持った推測で開示のギャップを埋めるべきではない。オペレータは、外部からの確実性の不可能性を、何も公開しない理由として使用すべきではない。

顧客への補償はネットワークの説明責任の一部である

ルーティングと転送の証拠は、課金や顧客サポートからはかけ離れているように見えるかもしれないが、顧客が適格なサービス喪失を証明できるかどうかを決定する。アクセスプロバイダは、技術的記録と当初の補償プロセスの多くを制御している。

Ofcom の自動補償フレームワークは、顧客が従来の請求を行うことなく、特定のブロードバンドおよび固定電話サービスの障害に対して払い戻しを提供することを意図している。Virgin Media は参加者としてリストされている。Virgin Media はまた、独自の補償ガイダンスと計画工事に関する情報を公開している。[16][17][18]

これらのページは現在のものである。本記事は、2023年4月にすべての現在の金額、ルール、適格条件が変更なく適用されたと仮定するものではない。ポリシーを使用する場合は、日付を明記し、経路イベントの影響を受けたすべての顧客が自動的に適格となったと主張すべきではない。

説明責任の原則は、1回の支払いよりも広範である。オペレータは、全損がいつ開始し終了したか、どの製品が影響を受けたか、例外が適用されるかどうかを判断するのに十分なサービス状態の証拠を保存すべきである。顧客は、自らのサービスが失敗したことを立証するために BGP をリバースエンジニアリングしなければならないべきではない。

通信チャネルもまた、インシデントを生き延びなければならない。ステータスページ、サポートポータル、電話サービスが同じ障害のあるネットワークに依存している場合、顧客は障害を報告したり、更新を確認したりできないかもしれない。Virgin Media の現在の計画工事ページは、計画された中断中に代替サービスを顧客に案内している。計画外のインシデントにも、同様に独立した通信経路が必要である。[17]

補償データは、エンジニアリングの説明責任を改善できる。検証されたサービス喪失記録の数と期間は、顧客の視点での影響を示す。苦情パターンは、集約されたトラフィックグラフでは隠れてしまう地域や製品の違いを明らかにすることができる。この情報は、技術的証拠を置き換えることなく、インシデント後のレビューに反映されるべきである。

正しい基準はトレーサビリティである。顧客向けの停止期間は、経路と転送の証拠と調和可能であるべきであり、例外には文書化された理由があるべきである。これにより、紛争が減り、技術的には狭いが商業的に時期尚早な復旧宣言が抑止される。

レジストリとルーティングセキュリティの証拠はその適切な役割にとどまるべきである

ASN、プレフィックス登録、ルートオブジェクト、または RPKI 認証は、誰がアドレス空間を生成する権限があるか、他のネットワークがどのように主張を検証できるかを確立するのに役立つ。これらの記録は説明責任の表面にとって重要であるが、可用性を保証するものではない。

現在のツールは、AS5089 のネットワーク識別とアナウンスされたリソースを示している。PeeringDB はオペレータと相互接続の文脈を識別する。RIPE 由来のサービスは登録とプレフィックス情報を公開する。BGP ツールは現在のルーティング観測を示す。[6][7][8][9][10][11]

本記事は、それらの現在のページを使用して、2023年のすべての時点でどの経路が存在したかを主張してはならない。歴史的なインシデント分析は、Cloudflare と ThousandEyes による日付付きの観測に依拠すべきである。現在の記録は、エンティティを結びつけ、制御面を説明するために使用される。

RPKI にも限定された役割がある。ルート起点検証は、ネットワークが起点 ASN がプレフィックスに対して認可されているかどうかを評価するのに役立つ。しかし、認可された起点がパケットを転送できること、その内部経路が健全であること、またはそのエッジがトラフィックを受け入れることを証明するものではない。経路は起点としては有効でありながら、ブラックホールにつながることがある。

この区別は現実層と一致する。セキュリティメタデータはルーティング決定の品質を改善するが、実行コードの証拠を置き換えるものではない。説明責任には、正確な記録と観測されたサービスの両方が必要である。

同じ注意が RFC 8212のデフォルト拒否のアプローチや MANRS の実践にも適用される。それらは偶発的な経路伝搬のクラスを減らし、調整を改善する。到達可能性の崩壊に対する普遍的な説明ではなく、一般的な制御が事後の診断を確立することはできない。

アクセスネットワーク復旧のための実践的な証拠基準

Virgin Media のインシデントは、他のアクセスネットワークが採用できる具体的な復旧記録を示唆している。その記録は、停止前に設計されるべきである。なぜなら、事後に収集された証拠は容易に不完全になるからだ。

第一に、経路状態を保存する。影響を受けた各プレフィックスグループについて、アナウンス、撤回、ピアセッション、ポリシーバージョン、タイムスタンプを記録する。どの外部経路が消え、どの経路が残ったかを示すのに十分な情報を含める。顧客に敏感な構成は公開しないが、内部および規制上のレビューのために保持する。

第二に、転送状態を保存する。多様な外部ネットワークから代表的な宛先に向けてプローブを実行する。トラフィックがどこで停止したか、エッジがそれを受け入れたか、内部の宛先が応答したかを記録する。IPv4 と IPv6 を分離する。パスが異なる場合、住宅用、ビジネス用、DNS 用、管理用の依存関係を分離する。

第三に、変更状態を保存する。インシデントウィンドウ周辺の展開、保守、自動化の決定、ロールバックアクションを記録する。変更がイベントを引き起こさなかった場合は、記録を確認した後にのみその旨を述べる。原因が不明なままならば、そのステータスと調査境界を保存する。

第四に、復旧基準を定義する。指定された間隔に対して、経路の安定性、転送の成功、アプリケーションの健全性、顧客影響の改善を要求する。最初の成功したプローブや最初の経路再アナウンスから完全な復旧を宣言することを避ける。

第五に、再発リスクをテストする。復旧後の状態をインシデント前の状態と比較する。劣化したままの依存関係を特定する。少なくとも1つの通常の負荷サイクルを通じて強化された監視を継続する。2回目の障害が発生した場合、最初のタイムラインを上書きするのではなく、差異を保存する。

第六に、ピアと調整する。テストされた NOC パスと、他のネットワークが経路と転送の観測を報告するための構造化された方法を提供する。矛盾する証拠を認める。外部レポートは、オペレータの内部からは見えない障害を明らかにする可能性がある。

第七に、層状に伝達する。顧客には簡潔なサービス声明と補償経路を提供する。技術的な利害関係者には、境界のあるルーティングと転送の時系列を提供する。規制当局には、期間、範囲、対応を評価するのに十分な証拠を提供する。

第八に、補償を調整する。検証されたサービス喪失期間を、顧客がネットワークメカニズムを理解することを要求せずに、補償および苦情システムにリンクする。ポリシーの日付と適格制限を明記する。

第九に、集中を見直す。影響を受けるネットワークを共有するサポート、ステータス、認証、テレメトリシステムを特定する。重要な証拠と通信経路を、可能であれば障害ドメインの外部に移動する。

第十に、永続的な是正策を公開する。監視を改善するという約束は十分ではない。どの信号が追加されたか、どの閾値が変更されたか、どのロールアウト境界が導入されたか、どの復旧テストが必須となったか、そしてその制御がどのように監査されるかを明記する。

このフレームワークは、すべての停止が防止可能であると仮定しない。オペレータが障害境界を特定し、サービスを安全に復旧し、何が変わったかを証明できることを要求する。

説明責任は後知恵ではなく、能力に従うべきである

大規模なアクセスネットワークの停止は、顧客、サービス、他のネットワークの間の数百万の関係に影響を与える。その規模は、1つのオペレータに無制限の責任を割り当てるか、あるいは逆に、その事象を不可避なインターネット障害と呼ぶ誘惑を生む。どちらのアプローチも正確ではない。

Virgin Media は、経路生成、エッジ転送、内部復旧、運用通信、顧客補償という、自らが有していた制御に対して説明責任を負うべきである。指定されたベンダの障害や悪意ある行為など、公開証拠が立証していない事実について責任を負わされるべきではない。

ピアは、自らの経路受信、監視、エスカレーションに対して説明責任を負うべきである。コンテンツプロバイダは、現実的な依存関係と通信設計に対して説明責任を負うべきである。規制当局は、顧客に不可能な証明の負担を課すことなく、技術的証拠を利用できる補償フレームワークに対して説明責任を負うべきである。

計測プロバイダは、自らの観測地点の限界を明記すべきである。彼らの観測は、独立しているからこそ価値があり、全知であるからではない。アナリストやジャーナリストは、それらの限界を保存すべきである。

顧客は、自律システム境界に対して最も少ない制御しか持たない。一般家庭のユーザは、通常、自らのプロバイダを迂回して経路を再設定することはできない。彼らの主な責任は、影響を報告し、利用可能な補償を利用することであり、第二のアクセスネットワークを設計することではない。

能力に基づく説明責任は後知恵を避ける。それは、各当事者がその時点で何を観測し、決定し、変更し、証明できたかを問う。また、原因を創作することなく、欠落した証拠を明らかにする。

結論

2023年4月4日の Virgin Media の障害は、経路と転送状態が、AS5089 が広域インターネットから使用可能な経路として存在したかどうかを決定したため、ネットワーク基盤の事象であった。観測されたトラフィック損失のほとんどは、有効な BGP 経路の欠如を伴っていた。一部の経路は残ったが、トラフィックは依然としてオペレータのエッジで失敗した。その後サービスは復旧し、同日に再び失敗した。[1][2]

これらの事実は、根本原因が未公開のままであっても、説明責任の基準を定義するのに十分である。復旧は、経路の可用性、パケット転送、顧客から見えるサービスにわたって証明されなければならない。レジストリデータは、運用上の真実と誤解されることなく、ネットワークを特定しなければならない。外部計測は、内部状態を明らかにするふりをすることなく、オペレータの主張をテストしなければならない。顧客への補償は、同じ証拠タイムラインに接続されなければならない。

最も強力なインシデント後の記録は、情報源が裏付けられない確実性を主張しないだろう。どの経路が変化したか、パケットが何をしたか、顧客が何を経験したか、オペレータが何を変更したか、そして安定した復旧がどのように検証されたかを示すだろう。それが、ネットワークが一時的に復帰することと、オペレータがサービスが復旧したことを実証することの違いである。

将来のインシデントに対して、その証明は、公共の懸念が高まった後に再構築されるのではなく、運用が進行するにつれて組み立てられるべきである。経路更新、転送プローブ、顧客影響信号、変更記録、ステータス通知は、調整されたタイムラインを共有すべきである。オペレータは、障害モード、復旧テスト、永続的な制御の変更を示すのに十分なその記録を公開し、顧客とセキュリティ上重要な詳細を保護すべきである。この証拠を生み出すことができるネットワークは、失敗から学び、ピアと調整し、公正な補償を提供するのに有利な立場にある。それを生み出せないネットワークは、パケットを復旧できるかもしれないが、同じ条件が再発しない理由を実証することはできない。

出典

1. Cloudflare、"Cloudflare's view of the Virgin Media outage in the UK":https://blog.cloudflare.com/virgin-media-outage-april-4-2023/
2. ThousandEyes、"Virgin Media UK Outage Analysis: April 4, 2023":https://www.thousandeyes.com/blog/virgin-media-uk-outage-analysis-april-4-2023
3. The Register、"UK's Virgin Media suffers massive broadband outage":https://www.theregister.com/on-prem/2023/04/04/uks-virgin-media-suffers-massive-broadband-outage/1495714
4. ThousandEyes、"The Top Internet Outages of 2023":https://www.thousandeyes.com/blog/top-internet-outages-2023
5. Cloudflare、"Q2 2023 Internet disruption summary":https://blog.cloudflare.com/q2-2023-internet-disruption-summary/
6. Cloudflare Radar、AS5089 traffic:https://radar.cloudflare.com/traffic/as5089
7. PeeringDB、AS5089 Virgin Media:https://www.peeringdb.com/net?asn=5089
8. bgp.tools、AS5089 Virgin Media Limited:https://bgp.tools/as/5089
9. RIPEstat、AS5089 network information:https://stat.ripe.net/data/network-info/data.json?resource=AS5089
10. RIPEstat、AS5089 announced prefixes:https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS5089
11. RIPE Database、AS5089 query:https://apps.db.ripe.net/db-web-ui/query?searchtext=AS5089
12. RFC 4271、"A Border Gateway Protocol 4 (BGP-4)":https://www.rfc-editor.org/rfc/rfc4271
13. RFC 7454、"BGP Operations and Security":https://www.rfc-editor.org/rfc/rfc7454
14. RFC 8212、"Default External BGP (EBGP) Route Propagation Behavior without Policies":https://www.rfc-editor.org/rfc/rfc8212
15. MANRS、Network Operators Programme:https://manrs.org/netops/
16. Ofcom、"Automatic compensation: What you need to know":https://www.ofcom.org.uk/phones-and-broadband/service-quality/automatic-compensation-need-know
17. Virgin Media、"We're improving the network in your area":https://www.virginmedia.com/help/planned-work
18. Virgin Media、"Automatic compensation":https://www.virginmedia.com/help/billing-and-payments/automatic-compensation