要約

  • AMS-IXの説明によれば、2023年11月の障害は、ある顧客接続から送出されたリンクローカルなLACPフレームが本来の隣接関係を越え、共有ピアリング・ファブリック上の他参加者のLAG状態とBGPセッションを変動させたことから始まった。
  • 説明責任の核心は、発端となったフレームだけでなく、ポート種別を問わない境界遮断、プロビジョニングの適合性、ベンダー横断試験、警報、ロールバック証拠、そして実際に利用できる代替トランジットまたはリモート・ピアリングを検証できるかにある。

二日間にまたがった事象

AMS-IXが公表した対象範囲は、アムステルダムのピアリング・プラットフォームで2023年11月22日と23日に発生した二つの障害時間帯である。公式に示された最初の影響時間帯は、11月22日19時08分から23時04分までのCET。二度目は、翌23日09時38分から10時25分までのCETだった。この境界を越えて原因や影響を広げて推測するべきではない。

最初の時間帯には、LACPとBGPのセッションが活発にフラップしたとAMS-IXは説明している。プラットフォーム上のトラフィックは最も低い時点で2.1 Tb/sまで低下した。IPv4のBGPセッション数は885から550へ、IPv6は800から450へ減少したと報告された。これらは共有基盤の状態が大きく乱れたことを示す重要な運用指標である。

ただし、数字の意味は限定しなければならない。2.1 Tb/sはプラットフォーム上で観測されたトラフィックの低点であり、失われたデータ量の総計でも、特定の顧客が被った損失でもない。BGPセッション数の減少も、利用者数、障害を起こしたアプリケーション数、到達不能になった企業数を表さない。まして、欧州全域のインターネットが一様に停止したことの証明ではない。

共有交換基盤からトラフィックが減った場合、複数の説明があり得る。経路が利用不能になった可能性もあれば、接続ネットワークが意図的にセッションを停止し、別のトランジットや他のピアリング経路へトラフィックを移した可能性もある。したがって、交換所のグラフだけからエンドユーザー影響を直接算定することはできない。一方で、BGPセッションの急減とトラフィック低下が同時に観測されたという事実は、相互接続の制御面と転送面が同じ時間帯に強い圧力を受けたことを示している。

AMS-IXは最初の事象後に対応を進めたが、翌朝にも二度目の影響時間帯が生じた。この二日目の発生は、単にトラフィックが戻ったことと、問題を生んだ条件が持続的に除去されたことが同義ではないと示す。運用上の回復を評価するには、グラフの反発だけでなく、原因となったフレーム境界、関連ACL、スイッチの実動作、セッション状態、警報、変更履歴まで確認する必要がある。

発端は隣接関係を越えたLACPフレームだった

AMS-IXは、発端となった条件をJuniperのプロバイダーエッジ・スイッチからのLACP漏出と説明した。顧客機器がLACPパケットを生成していた一方、その接続はLACPを使用するポートではなかったとされる。そのリンクローカルな制御フレームをJuniperスイッチが隣接関係の内部に閉じ込めず、共有ファブリック側へ伝搬させたというのが、公式説明の中心である。

LACPは、複数の物理リンクを一つの論理的なリンク集合として扱うため、隣接するシステム間でリンク集約状態を調整する。どのポートが集約に参加し、どのリンクが有効で、どのシステムと組を構成しているかという判断に関与する。したがって、そのフレームが意味を持つ範囲は本来、直接接続された関係の内側に限られる。

この事象で重大なのは、顧客機器が制御フレームを生成したことだけではない。そのフレームが、関係のない他参加者が共有する領域まで到達できたことである。他の参加者の機器が漏出したLACPフレームに反応すると、自らのリンク・アグリゲーション・グループ、すなわちLAGの状態を変更し得る。LAG状態の変化がIP接続へ波及すれば、その上で稼働するBGPセッションも不安定になる。

この因果関係は、一般的な「不正なパケットによる障害」という表現だけでは捉えきれない。リンクローカルな制御フレームには、隣接関係の内側では正当な役割があり得る。共有基盤に求められるのは、フレームの存在そのものを否定することではなく、その意味が及ばない顧客境界を確実に越えさせないことである。

したがって、必要な不変条件は明確だ。顧客向けポートが静的な集約、動的なLACP集約、非集約のいずれであっても、他の顧客関係から見える共有領域へリンクローカルなLACPフレームを転送してはならない。この条件は、ポートの申告状態や台帳上の分類に依存せず、実際の転送動作として成立しなければならない。

非LACPポートが露呈させた適合性の空白

AMS-IXはLACP向けACLによる緩和策が存在していたと説明している。しかし、問題の顧客接続は非LACPリンクだった。ここに、設計意図と適用範囲の間にある重要な空白が見える。

制御が「LACPを使用する」と登録されたポートにだけ生成されるなら、非LACPとして登録されたポートからLACPフレームが到来する異常状態を捕捉できない可能性がある。正常な設定値だけを前提に制御を組み立てると、現実の入力が設定値に反した瞬間、最も必要な遮断機能が存在しないという逆説が生じる。

顧客がどのサービスを契約し、どのAS番号やインターフェースが登録され、ポートがどの方式で構成される予定だったかという記録は、説明責任に不可欠である。それらは期待された関係を示し、異常時の調査範囲を絞り、誰がどの制御面を担当したかを明らかにする。しかし、記録はそれ自体でフレームを止めない。実際のスイッチ転送、適用済みACL、生成された設定、稼働中のソフトウェアが、境界の現実を決める。

このため、プロビジョニングの検証は「期待した設定を生成したか」だけで終えてはならない。生成物が対象機器へ正しく投入され、機器がその構文を受理し、期待する転送動作を示し、再起動やアップグレード後にも維持されているかを確認する必要がある。さらに、非LACPポートでLACPフレームを受信するような不適合入力に対し、デフォルトで閉じる設計が必要になる。

JuniperとExtremeをまたいだ制御面の連鎖

AMS-IXの公表内容では、Juniper側のアウトバウンドLACP ACLが完全には機能していなかった。また、Extreme SLX側のアウトバウンドACLも期待どおりに動作しなかったとされる。SLXの挙動については、ソフトウェア上の不具合だったのか、アップグレード後に構文が変わったためだったのか、AMS-IX自身が不明確だとしている。

この不確実性は残すべきである。公表資料からは、対象機器の正確なソフトウェア・バージョン、完全なACL構文、設定履歴、投入時の応答、ベンダーによる解析結果を確認できない。したがって、一方のベンダーだけに原因を集約したり、特定の既知不具合を推定したりする根拠はない。

一方で、運用上の教訓は具体化できる。共有基盤の安全性が複数ベンダーのフィルタ実装に依存するなら、同じポリシー文を設定台帳に置くだけでは足りない。各プラットフォームで同じ入力を与え、同じ境界結果が得られることを試験しなければならない。構文の生成、機器への適用、コンパイル後のフィルタ、実際のパケット転送までを一つの適合性チェーンとして扱う必要がある。

アップグレードも同様である。設定ファイルが移行後に存在していても、その意味が同じとは限らない。構文の解釈、既定動作、フィルタ方向、例外条件、ハードウェアへの展開方法が変われば、見かけ上同じポリシーでも実際の境界は変化する。変更後の検証には、設定差分だけでなく、禁止フレームが本当に通過しないことを示す回帰試験が求められる。

LAGとBGPのフラップから資源圧力へ

漏出したLACPフレームに他参加者の機器が反応すると、LAGの構成や転送可能性が変動する。物理リンクが存在していても、論理的な集約状態が揺れれば、その上に置かれたIP隣接性は安定しない。BGPセッションが切断と再確立を繰り返せば、経路撤回と再広告、転送先の再計算、キューの変化が重なる。

AMS-IXの説明では、このLACPとBGPのフラップに伴う資源枯渇とバッファの飽和が、さらにRSVPのタイムアウト・エラーを生じさせた。影響を受けたJuniper機器から送信されたRSVP Path Errorメッセージが、Extreme SLXスイッチ上で追加の問題を引き起こしたともされる。

ここでは順序を崩してはならない。RSVPは、AMS-IXの説明における最初の原因ではない。先にLACPフレームの境界漏出があり、他参加者のLAGとBGPセッションがフラップし、資源圧力とバッファ問題が生じ、その後の制御面メッセージがクロスベンダー環境で障害を増幅したという構図である。

また、この正確な連鎖をすべてのMPLSネットワークへ一般化することもできない。MPLSやRSVPを使うネットワークは、トポロジー、ベンダー、ソフトウェア、タイマー、帯域、保護方式、制御面の分離が異なる。この事象が示すのは、特定の共有基盤で、資源圧力下の制御面相互作用が二次的な増幅要因になったということだ。

技術標準は、LACP、BGP、RSVP-TE、MPLSのシグナリングや回復概念を理解する助けになる。しかし、標準文書だけでは、2023年11月22日にどのACLがどの機器でどのように適用され、どのメッセージがどれだけ生成されたかは分からない。一般的なプロトコル意味論と、当日の実装証拠を区別する必要がある。

プラットフォーム安定化と顧客回復は同じではない

障害対応を評価するとき、「回復」を一つの時刻で表すと重要な違いが失われる。少なくとも、共有プラットフォームの安定化、接続ネットワークによるトラフィック退避、個々のサービスのエンドツーエンド回復は別々に確認しなければならない。

プラットフォームのトラフィックやBGPセッション数が戻ることは、交換基盤の状態が改善した証拠になり得る。しかし、その前に一部の接続ネットワークがAMS-IXへのセッションを停止し、別経路へトラフィックを移していれば、グラフの変化には顧客側の防御行動も含まれる。共有基盤が完全に直ったから通信が戻ったのか、損傷箇所を避けたから通信が維持されたのかは分けて考える必要がある。

さらに、上流の経路が再確立しても、すべての下流サービスが同時に回復するとは限らない。経路収束、キャッシュ、セッション再確立、アプリケーションのタイムアウト、顧客側の手動復旧などが残り得る。公開資料には、すべての参加ネットワークと利用者についての完全な回復時刻は示されていない。

したがって、説明責任のある障害報告では、「ファブリックが安定した時刻」「BGPセッションが戻った時刻」「主要な代替経路が利用可能になった時刻」「顧客が通常経路へ戻した時刻」を可能な範囲で分離することが望ましい。単一の復旧宣言は、異なる制御主体が行った回避と修復を混同させる。

接続ネットワークが示した退避能力

凍結された資料には、Total Uptime、NFOrce、EDPnetによる同時期の観測が含まれている。これらは全参加者を代表する統計ではなく、それぞれのネットワークが公表した範囲の運用証拠として扱うべきである。

Total Uptimeの記録は、トラフィックを別経路へ移し、その後に復旧を追跡した事例を示す。NFOrceの記録は、問題のあるセッションを停止し、パケット損失を抑える方向で対応したことを示す。EDPnetの記録は、サービス影響の時系列と代替容量に関する自社の説明、回復更新を提供している。

これらの事例から、AMS-IX参加者全体の影響率を算出することはできない。各社のネットワーク設計、接続容量、トランジット契約、自動化、判断権限が異なるからだ。また、一社が効果的に迂回できたことは、他社にも同じ容量と選択肢があったことを意味しない。

それでも、これらの観測は重要な違いを示す。共有交換基盤の障害が、そのまま同じ規模のエンドユーザー障害になるとは限らない。十分な代替トランジット、別の交換所、リモート・ピアリング、利用可能な容量、経路を止める権限があれば、接続ネットワークは影響を局所化できる。逆に、代替経路が名目上存在しても、容量不足、設定不備、運用権限の遅れがあれば実用的な逃げ道にはならない。

冗長性の説明責任は、契約や構成図に線が二本描かれていることでは満たされない。障害時に本当にトラフィックを移せたか、移動後も必要な容量を維持できたか、BGPポリシーが意図どおりに収束したか、担当者が時間内に操作できたかという実動証拠が必要である。

RIPE Atlasが見せるもの、見せないもの

RIPE Atlasによる分析は、インターネットが損傷をどの程度迂回したかを、複数地点からの測定を通じて検討する。凍結資料の範囲では、一部の経路が障害部分を避けるように変化した一方、失敗した経路や異なる変化を示した経路もあった。

この種の測定は、交換所内部のトラフィックグラフとは異なる視点を提供する。交換所の統計が共有基盤上の集約状態を示すのに対し、測定プローブは特定の観測地点から特定の宛先へ到達できたか、経路がどう変わったかを示す。両者を組み合わせることで、プラットフォーム内部の不安定性と外部の到達性変化を比較できる。

ただし、RIPE Atlasもインターネット全体を完全に観測するものではない。プローブの配置、測定対象、測定間隔、経路上で応答する機器、ICMP応答の扱いによって可視範囲は制約される。経路が変化したことから障害回避を推定できる場合があっても、その経路を通った全アプリケーションの品質や、全利用者の体験を直接示すわけではない。

測定証拠の役割は、万能な影響算定ではなく、異なる説明を照合することにある。AMS-IXのプラットフォーム指標、接続事業者の運用記録、外部の経路測定が同じ時間帯に異なる側面を示せば、どこで状態が変わり、誰が回避行動を取り、どの範囲がなお不明なのかをより明確にできる。

説明責任は制御可能性に沿って配分される

この事象には少なくとも四つの制御層があった。第一に、特定されていない顧客側の機器がフレームの発生源を制御していた。第二に、AMS-IXがプロビジョニング、許可フレームの方針、ACL生成、共有ファブリックの境界を制御していた。第三に、JuniperとExtremeの実装がフィルタや制御面メッセージを処理した。第四に、接続ネットワークが代替トランジット、リモート・ピアリング、余剰容量、セッション撤回の自動化と権限を制御していた。

エンドユーザーはこれらの層を直接制御していない。利用者が選択できない内部境界で障害が増幅する以上、運用主体には、どの制御を保有し、それが当日どう機能したかを説明する責任がある。ただし、制御を保有していたことと、法的責任が確定したことは同じではない。

公開証拠だけから、過失、違法行為、契約違反、悪意、法的責任を断定することはできない。顧客の身元、契約条件、機器、設定変更、内部判断、ベンダー所見、損害配分が公開されていないためである。本件で可能なのは、技術的な制御境界、観測された挙動、未公開の証拠、今後検証すべき修復項目を明確にすることだ。

説明責任は、誰か一者を抽象的に非難することではない。どの層がどの失敗を防げたか、どの証拠を保存しているか、どの修復を約束したか、現時点で何が検証済みなのかを分離する作業である。

発表された修復策と検証済みの修復

AMS-IXは、非LACPリンクへのACL適用、プロビジョニング・スタックにおけるACL作成の強化、JuniperおよびExtreme上のアウトバウンドLACP ACLの確認、Slow Protocol BPDUに対する警報の調査、技術メーリングリストでの連絡規則の見直しを挙げた。

これらは、障害で露呈した制御点に対応する具体的な約束である。しかし、公表された行動項目は、そのまま持続的な修復の独立した証明にはならない。「適用する」「強化する」「確認する」「調査する」という将来または進行中の行為と、現在の全対象ポートで期待する不変条件が成立しているという検証結果は区別しなければならない。

耐久性を示すには、少なくとも、非LACPを含む全ポート種別への現在の設定適合性、プロビジョニング出力と実機状態の一致、JuniperとExtremeの双方での禁止フレーム試験、アップグレード後の回帰結果、警報が実際に作動した訓練記録、失敗した変更を戻せるロールバック証拠が必要になる。

さらに、同種の入力を再現した試験で、一つの顧客ポートからのリンクローカル・フレームが他の顧客関係へ到達しないことを観測すべきである。設定ファイルの存在だけではなく、パケット・キャプチャ、フィルタ・カウンター、LAG状態、BGPセッション、制御面負荷を同時に確認することが重要だ。

画像について

本稿の掲載画像は、一般的な光ファイバー・パッチ接続を写した説明用画像である。AMS-IXの施設、当該障害の現場、関係したスイッチ、顧客接続を撮影したものではない。物理的な相互接続を視覚的に示すための一般的な図像であり、事故現場の証拠として扱うべきではない。