OVHcloudの2021年バックボーン障害が問う、BGPからOSPFへの再配送と説明責任

要約

2021年10月13日、OVHcloudは米国バージニア州Vint Hillのルーターで、DDoS耐性を強化するためのバックボーン保守作業を開始した。
OVHcloudによれば、BGPからOSPFへの経路再配送を扱うコマンドの解釈上の問題により、インターネットの全経路表がOSPFへ投入された。
BGPとOSPFは、対象範囲、ポリシー、状態量、フラッディング、収束に関する前提が異なる。両者の間の再配送は、通常の設定変更ではなく、特権的な状態遷移として管理されるべきである。
障害ではOSPFが不安定化し、バックボーンのルーターにCPUとメモリーの圧力が生じ、IPv4へ世界規模の影響が出た一方、IPv6の到達性は維持されたと報告された。
遠隔ロールバックは成功せず、現地でルーターを物理的に切り離して電源を落とすことが、実効的な復旧境界になった。
変更承認、設定投入の成功応答、構文上の妥当性は、安全な稼働状態の証拠ではない。レンダリング済み設定、BGP・OSPF状態、LSDB、RIB、FIB、隣接関係、資源使用率、外部からのIPv4・IPv6到達性を一つの証拠連鎖として確認する必要がある。
IPv6が利用可能だったことは、障害範囲を限定した部分的分離の証拠である。しかし、制御、転送、管理、監視の各面が完全に独立していたことまでは証明しない。
復旧はサービスが一部戻った時点ではなく、意図したポリシー、実際にインストールされた経路状態、外部到達性が一致した時点で閉じるべきである。

2021年10月13日に起きたこと

OVHcloudが公表したインシデント報告によれば、作業は2021年10月13日09時05分（UTC）に始まった。対象は米国バージニア州Vint Hillにあるバックボーンルーターで、作業目的はネットワークの分散型サービス妨害、すなわちDDoSへの耐性を強化することだった。

この目的と、実際に発生した障害の原因は分けて理解しなければならない。障害時にDDoS攻撃が発生していたとする根拠はなく、公表記録が示すのは、DDoS対策を強化するための保守変更中に発生した、事業者起因の制御プレーン障害である。サイバー攻撃、BGPハイジャック、攻撃者によるルーター変更として扱うこともできない。

09時18分、チームは対象ルーターをBGPから隔離し、設定を更新した。ここでいうBGPからの隔離は、変更中のルーターが通常どおり外部経路交換へ参加し続けないようにする操作として理解できる。ただし、公表資料だけから、具体的な隣接関係、セッション構成、経路フィルター、機器ベンダー、ソフトウェア、実行されたコマンド構文を再現することはできない。

09時20分、OVHcloudによれば、BGP経路をOSPFへ再配送するコマンドの解釈に問題が生じ、インターネットの全経路表がOSPFへ入った。公表事実として言えるのはここまでである。何個の経路が投入されたか、どの種類のリンク状態広告として表現されたか、各ルーターが何件を受け取ったか、内部トポロジー上のどこまで伝播したかについて、公表資料にない具体値を補ってはならない。

その後、OSPFは不安定化し、バックボーンのルーターでCPUとメモリーへの圧力が発生した。OVHcloudは世界規模のIPv4影響を報告した一方、IPv6については引き続きアクセス可能だったとしている。この差は、少なくとも障害時にIPv4とIPv6の動作が完全には同一でなかったことを示す重要な観測結果である。

遠隔からのロールバックは失敗した。チームは対象ルーターを物理的に切断し、電源を落とした。その後、バックボーンは段階的に再収束し、OVHcloudは10時57分までに広範な復旧が進んだと報告した。復旧が段階的だったことは、問題の機器を停止すれば瞬時にすべてが正常化するという単純な構図ではなく、分散したルーティング状態が再び安定するまでの時間と観測が必要だったことを示している。

この事象を何と呼ぶべきか

この事象は、内部のBGPからOSPFへの再配送に関する障害であり、古典的な意味でのインタードメイン・ルートリークではない。一般にルートリークという表現は、ある自律システムが本来のポリシーに反して外部へ経路を伝播し、インターネット上の経路選択を乱す状況に使われる。今回の公表内容が指しているのは、BGPが保持していたインターネット規模の状態が、内部ゲートウェイプロトコルであるOSPFへ入ったことによる、プロトコル境界内部の障害である。

同様に、BGPハイジャックでもない。第三者が不正な経路を生成してトラフィックを引き寄せたとする証拠は示されていない。DDoS攻撃でもなく、サイバー攻撃でもない。DDoS耐性の強化という変更目的を、攻撃の発生事実と混同すると、原因、責任範囲、必要な対策がすべて曖昧になる。

正確な分類は説明責任の出発点である。分類を誤れば、BGPセキュリティだけを強化すればよい、外部の悪意ある経路だけを防げばよい、という誤った結論につながる。ここで問われるのは、正規の権限を持つ運用者が、正当な保守目的で実施した変更によって、許容範囲を超える状態遷移が起きないよう、システム側がどのように制約し、検出し、停止するかである。

BGPとOSPFは異なる責務を持つ

BGPは、自律システム間の到達可能性を交換し、属性とポリシーに基づいて経路を選択するためのプロトコルである。インターネット全体の接続性を扱うため、経路は単なる宛先情報ではなく、ASパスなどの属性や、受信、選択、広告に関する運用ポリシーと結び付いている。

OSPFは、一つの管理領域内でトポロジーと到達可能性を共有するリンクステート型の内部ゲートウェイプロトコルである。ルーターはリンク状態情報を交換し、リンクステートデータベースを構成し、それに基づいて経路を計算する。OSPFは外部経路を扱えるが、「扱える」というプロトコル上の能力は、インターネット規模のBGP状態を無制限に受け入れても安全だという意味ではない。

二つのプロトコルは、運用上の失敗の現れ方も異なる。BGPではポリシー、属性、セッション、経路選択、広告範囲が中心的な管理対象になる。OSPFでは、隣接関係、リンク状態広告のフラッディング、LSDBの一貫性、最短経路計算、エリア境界、外部経路の取り込みが重要になる。

一方のプロトコルから他方へ経路を移す再配送は、単なる形式変換ではない。経路の意味、規模、伝播方法、失効方法を異なる状態機械へ渡す操作である。したがって、再配送には、どの経路が対象になるか、どちらの方向へ流れるか、何件まで許容するか、どこまで伝播させるか、異常時にどの条件で停止するかという明示的な境界が必要になる。

再配送は特権的な状態遷移である

通常のアクセス制御では、「誰が変更できるか」が中心になる。しかし、バックボーンの再配送では、正規の担当者が承認済みの作業として変更しても、結果が安全とは限らない。そのため、権限管理だけでなく、変更によって生成され得る状態の範囲をシステムとして制限しなければならない。

第一の境界は適格集合である。再配送の対象となるプレフィックス、経路ファミリー、属性、起点、タグ、ポリシー条件を定義し、それ以外は既定で拒否する必要がある。「BGPからOSPFへ」という方向だけでは粗すぎる。どのBGP経路を、どの条件で、どのOSPF領域またはルーター群へ渡すのかまで固定しなければならない。

第二の境界はカーディナリティ、すなわち状態数である。許可された対象が少数であるはずなら、候補経路数、実際の生成数、受信側で観測された数に上限を設けるべきである。上限を超えた場合は警告だけでなく、投入前の拒否、自動撤回、変更停止のいずれかへ結び付ける必要がある。

第三の境界は方向である。一方向の再配送が、別の設定や相互再配送を通じて戻り経路を作れば、経路のフィードバック、重複、選択の不安定化を招く可能性がある。今回の公開資料は、そのような具体的な循環が起きたとは述べていない。しかし一般的な検証では、再配送の方向性と経路の出所を追跡し、意図しない再流入がないことを確かめる必要がある。

第四の境界は伝播範囲である。たとえ設定対象が一台でも、そのルーターが生成した状態は隣接ルーターを通じて広がり得る。変更を一台に限定したことと、影響を一台に限定したことは同じではない。カナリア運用では、投入対象だけでなく、生成された経路状態を受け取る範囲も限定されていなければならない。

状態量、フラッディング、収束の問題

インターネット規模の経路集合をOSPFへ渡す危険性は、各経路が個別に正しいかどうかだけでは測れない。各エントリーが構文上有効でも、集合全体がOSPFの想定する運用規模や、各ルーターの資源余裕を超えれば、ネットワークは不安定になり得る。

OSPFでは状態が隣接関係を通じて配布され、各ルーターがLSDBを維持する。大量の状態変化は、広告の生成、受信、検証、格納、フラッディング、経路計算、RIBへの反映、FIBへのプログラムという複数段階に負荷を与える可能性がある。どの段階がどれだけ支配的だったかは、公表資料だけでは断定できない。

CPU負荷が上がれば、経路計算だけでなく、隣接関係を維持する制御メッセージの処理、管理アクセス、監視への応答にも影響が及ぶ可能性がある。メモリー圧力が高まれば、LSDB、経路表、関連するプロセス状態の維持が難しくなり得る。これらは一般的に考えられる技術的メカニズムであり、OVHcloudの個別機器で実際にどの内部処理がどの順序で限界に達したかを示すものではない。

重要なのは、単一の「設定成功」メッセージでは、この連鎖の安全性を確認できないことである。設定システムがコマンドを受理しても、再配送の候補数、生成された状態数、隣接ルーターへの伝播、LSDBの増加、RIBとFIBの変化、CPUとメモリーの推移までは証明されない。

承認された意図と稼働状態の違い

変更管理には通常、作業目的、承認者、対象機器、実施時刻、手順、ロールバック計画が記録される。これらは必要だが、運用上の結果を保証するものではない。承認は意図の記録であり、実際のルーティング状態の記録ではないからである。

同じことは候補設定にも言える。候補設定が構文検査を通過しても、対象機器上でレンダリングされた最終設定が意図どおりか、既存設定との組み合わせでどの経路が適格になるか、実行時に何件の状態が生成されるかは別の問題である。機器から正常応答が返っても、バックボーン全体で安全な状態が成立したとは限らない。

説明責任を成立させるには、少なくとも次の証拠を時刻付きで接続する必要がある。

変更申請で承認された目的、対象、許容範囲。
テンプレートや自動化の入力ではなく、機器へ適用されるレンダリング済み設定。
機器が返した受付・適用応答。
適用直前と直後のBGP経路、OSPF外部経路、隣接関係、LSDBの状態差分。
RIBに選択された経路と、FIBへ実際にプログラムされた転送状態。
CPU、メモリー、制御プレーンのキュー、隣接関係の安定性。
複数地点から観測したIPv4・IPv6の到達性と経路変化。
異常検出、停止、ロールバック、物理的隔離、再収束の各時刻。

この連鎖があれば、「担当者は何を意図したか」だけでなく、「システムは何を実行し、ネットワークはどの状態になり、利用者からどう見えたか」を検証できる。

カナリアと自動中止条件

バックボーン変更のカナリアは、単に最初の一台を選ぶことではない。選ばれた機器から生成される状態が、全体へ直ちに広がらないようにすることが本質である。変更対象が一台でも、その一台が広い制御プレーンへ新しい状態をフラッディングすれば、カナリアとしての隔離は成立しない。

有効なカナリアには、事前に定義された観測時間と中止条件が必要になる。再配送候補数が予定値を超えた、OSPF外部経路数が増加した、LSDBの変化量が上限を超えた、隣接関係が揺れた、CPUまたはメモリーが許容帯域から外れた、RIBとFIBの差分が拡大した、外部プローブで到達性が低下した、といった条件を自動停止に結び付ける。

ここで上限は監視用の参考値ではなく、状態遷移の許可条件でなければならない。「予想より多いが変更は継続し、担当者が判断する」という設計では、収束が急速に悪化する局面に人間の反応時間が追い付かない可能性がある。特に、管理アクセス自体が同じ制御プレーンの不安定化に巻き込まれるなら、検出後に遠隔で修正できるという前提は弱い。

安全な実装では、変更前に許容される経路集合を計算し、予想件数と照合する。投入直後には、生成された経路数と受信側の状態を監視する。上限超過時には新規状態の生成を止め、必要に応じて変更を自動撤回する。さらに、撤回操作が対象ネットワークの正常性へ依存しないように設計する必要がある。

遠隔ロールバックの失敗が示した境界

OVHcloudの報告では、遠隔ロールバックは成功せず、最終的に現地でルーターを物理的に切断して電源を落とした。この事実は、ロールバック手順が文書に存在するだけでは不十分だという問題を明確にする。

変更対象の制御プレーンが不安定化した場合、その同じ制御プレーンを経由して管理セッションへ接続し、設定を戻そうとする設計には共通障害点がある。管理トラフィックが到達できない、機器が高負荷で応答できない、セッションが維持できない、コマンドが適用されても周囲の状態が収束しない、といった複数の失敗が考えられる。

独立した回復経路には、別ルーティングの管理ネットワーク、コンソールサーバー、帯域外アクセス、遠隔電源制御、現地作業手順、物理ポートの切断手段が含まれる。重要なのは、これらを「最後の手段」として名前だけ用意するのではなく、変更対象が故障し、通常の経路が不安定で、担当者が強い時間圧力を受けている条件で実行できるよう、定期的に訓練することである。

物理的な切断が有効だったからといって、常に電源断が最適な復旧方法だとは限らない。事象ごとに転送影響や再収束への影響は異なる。しかし、この事例では、公表記録上、物理的隔離が問題のルーターからの状態伝播を止める実効的な境界になった。したがって、物理アクセスと電源制御は緊急時の即興ではなく、バックボーンの説明責任を構成する制御として扱うべきである。

IPv4への影響とIPv6の継続性

OVHcloudは世界規模のIPv4影響と、継続したIPv6アクセスを報告した。この差は、障害分析における貴重な証拠である。少なくとも観測された結果として、両プロトコルの障害範囲が完全には一致しなかった。

ただし、IPv6が到達可能だったという一事だけから、IPv4とIPv6のアーキテクチャが全面的に独立していたとは結論できない。両者は、ルーター筐体、電源、インターフェース、光回線、管理系、監視系、設定配布基盤、担当チームなどを共有していた可能性がある。何を共有し、何を分離していたかは、公表情報だけでは確定できない。

評価すべき分離には少なくとも四つの面がある。第一はBGPやOSPFなどの制御プレーン、第二はパケットを転送するデータプレーン、第三は設定変更やコンソール接続に使う管理プレーン、第四は外部プローブやテレメトリーを集約する観測プレーンである。ある一面で分離されていても、別の一面に共有障害点があれば、完全な独立性は成立しない。

それでも、IPv6の継続性を単なる注記として扱うべきではない。何が残ったかを調べれば、障害時にも機能した設計境界が見える可能性がある。IPv4とIPv6について、経路交換、内部配送、転送、監視、管理到達性を個別に比較すれば、将来の障害範囲を限定する設計に役立つ。

復旧をいつ閉じるか

ルーターを停止し、一部の監視値が戻った時点で復旧を完了とするのは早い。分散ルーティングシステムでは、制御プレーンの収束、RIBへの経路選択、FIBへの反映、実際の転送、外部からの到達性が時間差を伴って回復する可能性がある。

復旧の閉鎖条件は三つの状態の一致で定義すべきである。第一は意図したポリシーであり、どの経路をどの方向へ広告し、何を再配送しないかという設計上の期待である。第二はインストールされた状態であり、BGP、OSPF、LSDB、RIB、FIB、隣接関係が示す実際の動作である。第三は外部到達性であり、複数のネットワークや地域からIPv4とIPv6が利用可能かという利用者側の観測である。

設定が元に戻っても、不正な状態が一部に残っていれば閉鎖できない。内部状態が正常でも、外部からの到達性が戻っていなければ閉鎖できない。外部プローブが成功しても、経路が暫定的な迂回や不安定な隣接関係に依存しているなら、安定した復旧とは言い切れない。

10時57分までに広範な復旧が報告されたという時系列は重要だが、すべての顧客、すべての経路、すべての地域が同時刻に完全復旧したと拡張して解釈すべきではない。顧客別の影響や損失、個別サービスの正確な復旧時刻については、追加の証拠が必要である。

バックボーン変更の説明責任

この事例が示す中心的な問題は、設定変更の是非を個人の注意力だけへ帰属させてはならないということだ。公表資料から、誰が最終判断をしたか、承認体制がどう構成されていたか、要員配置に問題があったかを確定することはできない。過失、違法性、隠蔽、法的責任を認定する根拠もない。

しかし、システムとして求めるべき証拠は定義できる。再配送の適格集合は明示されていたか。件数上限は投入前に強制されたか。変更は伝播範囲を限定したカナリアで試されたか。異常なLSDB、RIB、FIB、CPU、メモリー、隣接関係を自動中止へ結び付けたか。ロールバック経路は変更対象から独立していたか。IPv4とIPv6の外部到達性を別々に検証したか。これらは、個人への推測を避けながら、運用設計の検証可能性を問うための項目である。

現在のOVHcloudのネットワークおよび製品資料には、グローバルバックボーン、拠点、BGPを用いるレイヤー3接続、ECMP、BFD、顧客向け接続サービスのプレフィックス数制限など、今日の制御語彙が示されている。これは、経路数、隣接関係、障害検出、冗長性を測定可能な制約として表現できることを説明する材料になる。

一方、現在の公開資料は、2021年にVint Hillで使われていた非公開構成の証明ではない。同じ製品設定が使われていたとも、その後の是正措置が有効だったとも断定できない。現在の設計説明を過去の内部実装へ遡及して当てはめることは避けなければならない。

同様に、RFCはBGP、OSPF、OSPFv3、再配送、スタブルーター、BFD、BGP運用、ルートリーク防止などの振る舞いと制御境界を定義する。しかし、OVHcloudがどの仕組みを配備していたか、特定の仕組みが今回の障害を必ず防げたかを証明するものではない。標準は検証項目を組み立てるための語彙であり、非公開トポロジーの代替証拠ではない。