LINX LON2の2023年障害が突きつけた「ラボから本番へ」の稼働状態責任

要約

LINXの公開記録では、2023年6月20日のダークファイバー障害でLON2の冗長性が低下し、翌日にリンクのフラップ、トラフィック損失、ピアリングLANの到達性問題が発生した。 [1][2]
ラボ使用歴のあるルーターでは設定変更後も稼働中のOSPFプロセスが古いルーターIDを保持し、別の残存ケースではソフトウェアMAC表とハードウェア転送表が一致しなかったため、説明責任は設定意図ではなく実稼働状態の検証に置かれる。 [1]

要旨

LINXが公開した記録で最も重要なのは、単一の設定ミスや特定製品の欠陥を指摘した点ではない。意図された設定、制御プレーンが保持する情報、実際のプロトコルプロセス、そしてパケットを処理するハードウェアの状態が、同時には一致しないことがあると具体的に示した点である。

2023年6月20日、LON2ではダークファイバー接続の障害が発生した。LINXによれば、この段階では会員への直接的な影響はなかったが、ネットワークの冗長性は低下した。翌21日にはFlowmonがドロップを検知し、インタースイッチリンクのフラップ、トラフィック損失、ピアリングLAN全体の到達性問題が観測された。復旧作業では複数のリンクが切り離され、最終的にはコア機器間のリンクアグリゲーションを無効化する回避策が使われた。[1]

22日には広範な問題が収束した一方、特定IPアドレスへの到達性問題が残った。LINXは、対象MACアドレスがエッジ機器のソフトウェアMACテーブルには存在するものの、ハードウェアテーブルには存在しない状態を報告している。影響を受けたVTEP間のL2VPN EVPN BGPセッションをクリアすると、ハードウェアテーブルが再び設定された。[1]

さらに、LINXは新たに設置したルーターが以前ラボで使用されていたこと、その機器が当初、本番環境の別ルーターと同じルーターIDを持っていたことを明らかにした。古いOSPFおよびルーターID設定は削除され、NETCONFを通じて新しいIDが配備されていた。しかしOSPFプロセスがクリアされていなかったため、稼働中のプロセスは古いIDを使い続けたという。[1]

この事実から導かれる結論は明快である。設定データベース、構成管理リポジトリ、デプロイ成功通知は、いずれも重要な記録ではあるが、本番ネットワークの最終的な証拠ではない。説明責任の境界は、実際に動作しているプロセスのID、EVPNが配布する状態、ASICなどの転送ハードウェアに書き込まれたエントリー、そして会員側から確認できる到達性に置かなければならない。

障害は「停止」ではなく冗長性の低下から始まった

6月20日のダークファイバー障害を、直ちにサービス停止と表現するのは正確ではない。LINX自身が、この時点では会員への影響はなく、主な結果はレジリエンスの低下だったと説明している。[1] しかし、トラフィックが流れ続けていたからといって、運用条件が変わらなかったわけではない。

冗長構成では、一つの物理経路を失ってもサービスを継続できることがある。だが、その瞬間から残る経路、リンクアグリゲーション、コア機器、アンダーレイ経路、VTEP間通信にかかる責任は重くなる。平常時には局所的に吸収できる次の異常が、劣化状態では利用者に見える障害へ拡大する可能性がある。

したがって「障害が起きたか」という二値だけでは足りない。運用上は、通常、冗長性低下、部分復旧、残存障害、完全復旧を別々の状態として扱うべきである。6月21日に発生したリンクフラップや到達性問題は、前日に物理経路の余裕が減っていた環境で起きた。この時系列を保つことが重要であり、最初のファイバー障害が直ちに会員影響を生んだと書き換えてはならない。

冗長性も、設計図に描かれた線の本数では測れない。実際に独立した経路が存在し、適切に設定され、監視され、障害時に期待されたトラフィックを運べて初めて、運用上の冗長性となる。LINXはLON1とLON2を含むロンドンのデュアルLAN構成について公開しているが、各会員が両方をどのように利用し、別のIXやトランジットをどの程度併用していたかは公開資料から一律には判断できない。[4][5][6]

このため、物理的に別のプラットフォームが存在することと、個々の会員に実効的なフェイルオーバーが存在することを混同してはならない。契約、ポート、BGPポリシー、ルートサーバー利用、二者間ピアリング、トラフィックエンジニアリングの組み合わせによって、実際の耐障害性は異なるからである。

ラボから本番への境界は「設定の削除」では閉じない

ラボは再利用を前提とした環境である。機器は異なる役割を割り当てられ、何度も設定され、別のトポロジーへ接続される。これは検証環境として当然の性質だが、本番投入時には、目に見える設定以外の状態が残る可能性を前提にしなければならない。

残留し得るものには、ルーティングプロセスのIDや隣接関係、転送キャッシュ、起動設定、VTEP情報、VLANやブリッジドメインの対応、管理資格情報、ソフトウェアイメージの差異などがある。すべてがLINXの事例で確認されたわけではない。重要なのは、プラットフォームごとに残り得る状態を定義し、それを投入前に否定する検査が必要だという一般原則である。

LINXが報告した範囲では、古いOSPFとルーターIDの設定は削除され、新しいIDがNETCONFで投入されていた。それでも、稼働中のOSPFプロセスは古いIDを保持した。[1] つまり、設定変更は受理されても、期待した運用上の事後条件は成立していなかった。

ここで自動化を責めるのは筋違いである。NETCONFや構成管理は、変更を再現可能にし、人為的なばらつきを減らす。しかし、自動化の成功を「コマンドが通った」「候補設定がコミットされた」という入力側の結果だけで定義すると、実際のプロセスが新しい状態へ移ったかを見落とす。

本番投入の自動化は、事後条件までを契約に含めるべきである。新しいルーターIDがローカル機器で表示されること、隣接ルーターからも同じIDとして観測されること、対象ドメイン内に重複がないこと、必要なプロセスクリアや再起動が完了したこと、隣接関係が期待どおり再確立されたことまで確認して初めて、変更は成功したといえる。

また、検証は候補機器の自己申告だけに依存できない。ルーター自身が正しいIDを表示しても、隣接機器やリンクステートデータベースが古い状態を保持している可能性がある。ローカル状態、隣接側の観測、運用上の記録を突き合わせる三者照合が必要になる。

OSPFのルーターIDは装飾的な属性ではない

OSPFのルーターIDは、ルーターをルーティングドメイン内で識別する32ビットの値である。RFC 2328は、ルーターを一意に識別するものとしてルーターIDを定義している。[11] これは画面表示を整えるためのラベルではなく、リンクステート情報の生成元を区別する運用資源である。

同一ドメインに重複したIDが現れれば、どのルーターがどの情報を生成したのかという対応関係が損なわれる。Juniperの運用資料も、重複ルーターIDを重大なIGP異常として扱い、一意性確認の重要性を説明している。[18] ただし、この一般的な資料は、LINXで使われたベンダーや製品、障害の責任主体を特定する証拠ではない。

この区別は重要である。RFCやベンダー文書は、プロトコルがどのように動くべきか、どのような異常を監視すべきかを説明できる。しかし、LINXの機器構成、実装上の欠陥、担当者の判断、契約上の責任を明らかにするものではない。事件固有の事実はLINXの公表記録に帰属させ、標準文書は技術的背景の説明に限定すべきである。

ルーターIDの一意性は、ネットワーク識別情報全般に通じる。ASN、ピアリングLAN上のIPアドレス、VTEPアドレス、MACアドレス、インターフェース識別子も、それぞれ異なる範囲で一意性や正確性を要求される。台帳に正しい値が記録されていても、稼働中のプロセスが別の値を使えば、ネットワークにとっての現実は後者である。

だからといって台帳やSource of Truthが不要なのではない。むしろ、その価値を保つには稼働状態との照合が必要になる。割り当て記録、デプロイ記録、機器自身の状態、隣接機器からの観測を関連付け、差異があれば本番投入を止める。記録は運用現実を反映してこそ権威を持つ。

EVPN/VXLANでは制御情報と転送結果を分けて見る

LINXはLON2をEVPN over VXLANの環境として説明している。[3] VXLANは、IPアンダーレイ上でトンネル終端間にイーサネットフレームを運ぶオーバーレイ技術であり、RFC 7348に基本的な仕組みが記述されている。[13] EVPNはBGPを利用してMACやIPの到達性情報を配布する制御プレーンを提供し、RFC 7432およびRFC 8365はそのモデルとネットワーク仮想化オーバーレイへの適用を説明している。[14][15]

この構成では、少なくとも三つの状態を分けて考える必要がある。第一に、VTEP同士が通信できるアンダーレイのIP到達性。第二に、EVPNが配布し、ソフトウェアが保持する制御プレーン上の情報。第三に、実際のパケットを転送するハードウェアへ設定されたエントリーである。

BGPセッションがEstablishedであることや、ソフトウェアMACテーブルにアドレスが見えることは、必要な証拠ではある。しかし、それだけでパケットが転送されるとは限らない。LINXが22日に観測したのは、まさにソフトウェアテーブルにはMACアドレスがあるのに、対応するハードウェアテーブルにはないという乖離だった。[1]

影響を受けたVTEP間のL2VPN EVPN BGPセッションをクリアした結果、LINXが説明した残存ケースではハードウェアテーブルが再設定された。[1] これは、EVPNやBGPそのものが本質的に危険だという証拠ではない。また、すべての欠落エントリーに同じ原因があったことも証明しない。立証できるのは、当該事例でソフトウェア上の制御情報だけでは転送可能性を証明できなかったという限定的かつ重要な事実である。

RFC 9062が示すEVPNの運用・保守要件は、制御プレーンの見え方とデータプレーンの挙動を照合する仕組みの必要性を理解するうえで有用である。[17] 同RFCはLINX固有の実装障害を説明するものではないが、どの種類の検証が不足を発見し得るかを示す。

BGP自体についてはRFC 4271が基本的な状態機械と経路交換の枠組みを定めており、運用時にはセッション状態、受信・広告経路、ポリシー、タイマーを個別に確認する必要がある。[12] ベンダーのBGPトラブルシューティング資料も、セッションが確立しない場合や期待した経路が交換されない場合の観測面を整理している。[19] ただし、セッション健全性はEVPN転送全体の一部にすぎない。

ソフトウェアテーブルはパケットの証明書ではない

ネットワーク運用では、CLIやAPIに表示される情報が「真実」として扱われやすい。しかし、表示がどの層の状態を反映するかを区別しなければならない。制御プレーンのRIB、ソフトウェアFDB、カーネル、ハードウェアFIB、ASICテーブルは、それぞれ別の更新経路と失敗モードを持ち得る。

あるMACアドレスがソフトウェア上で学習済みでも、ハードウェアに正しくプログラムされていなければ、実際のフレームは期待どおりに転送されない。逆に、古いハードウェアエントリーが残れば、制御プレーンが正しく収束した後も誤った転送が続く可能性がある。したがって復旧確認には、少なくとも代表的なエントリーについて両方の状態を照合する必要がある。

さらに必要なのは、テーブル照合をパケット試験へ接続することである。ハードウェアテーブルの表示が正しくても、別のVLAN、VNI、ブリッジドメイン、リンク、カプセル化処理に問題があれば到達性は失われる。機器内部の状態確認と、会員向けポートに近い観測点からのエンドツーエンド試験を組み合わせなければならない。

この検証は「大半が正常」で終えてはならない。22日に残ったのは、より限定された特定IPへの到達性問題だった。[1] ファブリック全体のトラフィック量、管理面の到達性、多数の正常なMACエントリーが緑色でも、選択的な障害は残り得る。検査の粒度は、障害が発生する粒度まで下げる必要がある。

ルートサーバーのセッションが維持されていても、すべての会員間パケットが正常に転送されるとは限らない。LINXはルートサーバーと自動化の仕組みを公開しているが、ルートサーバーは経路交換を支援するものであり、ピアリングファブリックの全データプレーンを代替するものではない。[7][8][9]

6月と11月を単一原因へ押し込めてはならない

LINXの公開記録には、6月20日から22日の系列だけでなく、6月29日の到達性問題と、11月5日の散発的なフロードロップも含まれている。11月の事象はベンダーによるダークファイバー保守の後に発生したとされ、ハードウェアMACテーブルの挙動に対処するためのソフトウェア変更は障害後にロールバックされた。ベンダーの調査は継続していた。[1]

これらの記録は、再発管理の重要性を高める。一方で、似た症状が現れたからといって、すべてを同じ根本原因で説明することはできない。到達性喪失という外形は、物理経路、IGP、EVPN制御状態、ハードウェアプログラミング、リンクアグリゲーションなど、複数の機構から生じ得る。

6月に報告された古いOSPFルーターIDの残留は具体的な観測である。ソフトウェアとハードウェアのMACテーブル不一致も具体的な観測である。しかし、この二つが6月と11月のすべての症状を単独で説明したとは、公表資料から立証できない。

再起動、セッションクリア、リンク切り離し、ソフトウェア変更、ロールバックを同じ復旧時間帯に実施すると、サービスは回復しても、どの操作がどの症状へ効いたのかが不明確になることがある。緊急復旧では複数の措置が必要でも、事後分析では仮説と証拠を切り分けるべきである。

各是正措置には、対象とする故障仮説、期待される状態変化、確認試験を結び付ける必要がある。OSPF IDの仮説なら、プロセスリセット後の一意な実稼働IDをローカル、隣接側、ドメイン全体で確認する。MACプログラミングの仮説なら、ソフトウェアとハードウェア双方のエントリー、および実パケット転送を確認する。

ファイバー経路の仮説では、物理的な多様性が戻ったことだけでなく、片系喪失時に残りの経路が期待どおり動くことを試験する。ソフトウェア変更の仮説では、導入版、発生症状、ロールバック時刻、ロールバック後の試験を同一タイムラインで保存する。復旧したという結果だけで、原因まで確定したと扱わないことが重要である。

劣化状態では変更管理のルールを切り替える

物理経路が一つ失われてもサービスが継続している場合、運用チームは「正常」でも「全面障害」でもない状態を管理することになる。この状態で通常時と同じ変更許容度を維持すると、残っている余裕を別の変更が消費する可能性がある。

第一に必要なのは、劣化状態を運用上のSource of Truthへ反映することである。インシデント用チャットに情報があるだけでは、別の担当者や自動変更システムが名目上のトポロジーを前提に作業を進めかねない。重要経路が失われている間は、予定された機器投入やソフトウェア変更に自動的な再評価を要求すべきである。

第二に、残存経路の依存関係を明示する。ダークファイバー、コア装置、インタースイッチリンク、リンクアグリゲーション、アンダーレイ経路、VTEP、EVPNセッションは、管理主体が違っても同じエンドツーエンドサービスを構成する。どの要素が保護対象トラフィックを引き受け、どの試験がその機能を証明するかを変更記録に結び付ける必要がある。

第三に、カナリア試験は実際の劣化経路を通らなければならない。健全なラボや影響を受けない本番セグメントだけで試すと、代替インタースイッチリンクや別VTEPを通るときに限って現れる問題を見逃す。管理面への接続確認ではなく、制御プレーンの収束とデータプレーンのパケット転送を同時に試すべきである。

第四に、停止条件を事前定義する。ルーターID重複、予期しない隣接関係、ハードウェアテーブル不一致、ドロップ増加、リンクフラップ、会員向けプローブ失敗など、どの証拠が出たら投入を中止またはロールバックするのかを決める。障害進行中に症状の重大性を議論し始めるより、復旧判断を速くできる。

障害検知を高速化する仕組みとしてBFDが利用できる場合もある。RFC 5880は、隣接転送エンジン間の双方向経路障害を低オーバーヘッドで検出するプロトコルを定義している。[16] ただし、高速な障害検知は、誤ったIDや欠落したハードウェアエントリーを自動的に修正するものではない。検知、収束、転送検証は別の責任面である。

本番投入記録に必要な証拠

安全な本番投入記録は、機器がラボを離れる前から始まる。ハードウェア識別、ソフトウェアおよびファームウェアの版、設定の出所、想定する本番役割、使用するネットワークID、消去または再構築の手順を記録する。目的は書類を増やすことではなく、何が投入されたかを別の有資格者が再現できる状態にすることである。

次に、永続状態の境界を明確にする。再起動で消える状態、プロセス再起動が必要な状態、設定削除だけで消える状態、起動媒体やハードウェアに残り得る状態をプラットフォームごとに分類する。投入手順は、対象状態に応じて完全再構築、プロセスクリア、再起動、キャッシュ消去などを選ばなければならない。

ID検証では、意図したOSPFルーターID、稼働プロセスが報告するID、隣接機器が観測するIDを保存する。ドメイン全体に対する重複検査も必要である。ID変更にプロセスクリアや再起動が必要な機種なら、その実行と新しいIDでの隣接再確立までを同じ投入記録に含める。

アンダーレイ検証では、VTEPループバックへの到達性、インターフェース状態、IGPメトリック、リンクアグリゲーション、想定経路を確認する。平常状態だけでなく、設計が耐えるべき経路喪失条件でも試験しなければならない。片方のファイバーが失われたとき、残る経路が隠れた単一障害点にならず、期待トラフィックを運べるかを確かめる。

オーバーレイ検証では、期待したEVPN情報の広告と学習、ルートターゲット、ブリッジドメイン、VNI対応をSource of Truthと照合する。ラボで使われたVTEP、未承認VLAN、予期しないルートターゲット、古いMAC情報があれば、無害な残骸として放置せず投入を止める。

決定的なのは転送状態の照合である。プラットフォームが公開する範囲で、代表的なMACおよびIPエントリーがソフトウェアとハードウェアの双方に存在することを確認する。さらに、対象となるリーフ、VTEP、VNI、会員向けポートの組み合わせを横断する実パケット試験を実施する。

肯定試験だけでは不十分である。「期待した隣接がある」「期待した経路がある」と同時に、「重複IDがない」「予期しない隣接がない」「古いラボVTEPがない」「未承認VLANがない」「ソフトウェアにしか存在しない転送エントリーがない」ことも証明する。危険な残留状態の不在を示す否定試験こそ、本番投入ゲートの中心となる。

監視も、トラフィックを流す前に関連付ける必要がある。フローテレメトリー、リンク状態、制御プレーンセッション、ハードウェアプログラミング警告、会員向けプローブを新規機器と依存経路へ結び付ける。アラートの受信者、判断責任者、ロールバック権限が不明なら、監視設定は完成していない。

投入後のクローズアウトでは、設定チェックサム、ライブ状態、隣接側観測、転送表、プローブ結果、テレメトリー、最終判断を同一変更窓へ束ねる。例外を受容した場合は、責任者、期限、代替統制を残す。これにより「デプロイが成功した」という主張が、監査可能な運用事実へ変わる。

復旧証拠は会員側の境界まで届く必要がある

リンクが安定したこと、EVPN BGPセッションが確立したこと、ハードウェアテーブルにエントリーがあることは、それぞれ重要である。しかし、いずれも単独では会員が期待する宛先と通信できることを証明しない。

復旧試験には外側から内側を見る観測点が必要である。会員向け、または会員通信を代表できる地点から、影響を受けた経路を横断する双方向試験を行う。必要に応じて複数のパケットサイズやプロトコルを使い、一回のping成功だけで広範なピアリングサービスの復旧を宣言しない。

結果は障害の粒度で分類すべきである。22日に特定IPへの問題が残っていたのであれば、ファブリック全体の正常性確認だけでは不十分だったことになる。[1] 該当IP、MAC、ARPまたは近隣状態、EVPN経路、ハードウェア転送、実パケットを一連の証拠として確認する必要がある。

会員からの報告も重要な観測情報である。中央監視が見逃した選択的障害を会員が先に認識することもある。一方、会員側やアプリケーション側の問題がIX障害に見える場合もある。チケット、テレメトリー、経路情報、時刻を突き合わせ、どちらか一方だけを絶対視しないことが必要である。

部分復旧と完全復旧の差も保存しなければならない。LINXの時系列では、リンクの無効化による復旧作業の後も、翌日まで限定的な到達性問題が残っていた。[1] 単一の「復旧時刻」にまとめると、多くの通信は戻ったが一部は依然失敗していた期間が見えなくなる。

公表時には、何が復旧し、どの観測点で確認され、何が調査中なのかを分けて述べるべきである。限られたサンプルから全会員の完全復旧を推定してはならない。この慎重さは広報上の防御ではなく、次の調査で暫定回避策を恒久対策と誤認しないための技術的要件である。

可用性99.997%が示すもの、示さないもの

LINXの2023年年次報告書では、LON2の可用性は99.997%で、内部目標の99.998%を下回ったとされ、その要因として複数の停止が挙げられている。[2] 数字だけを見れば差は小さい。しかし、インフラ運用における問いは、小数点以下がどれほど九に近いかではない。

可用性指標を評価するには、分母、観測期間、除外された保守時間、障害判定の閾値、プローブの位置、対象サービスを知る必要がある。ポートのリンク状態を中心とする指標なら、電気的にはアップしているが特定宛先へ届かない障害を見逃し得る。総トラフィック量なら、正常な多数の会員が少数の選択的障害を覆い隠す可能性がある。

EVPNピアリングファブリックでは、会員間到達性、ルートサーバーへの到達性、二者間セッションの継続、選択したオーバーレイ経路、ソフトウェアとハードウェアのMAC状態など、複数の観測を組み合わせる必要がある。一つの数字でサービス全体を完全には表現できない。

99.997%という値は、インシデントが運用実績に影響したことを裏付ける。しかし、影響を受けた会員数、プレフィックス、セッション、パケット、売上損失を導き出すものではない。この集計値から顧客別の損害額や契約違反を推計するのは、公開証拠の範囲を超える。

詳細なトポロジーや会員情報をすべて公開する必要もない。セキュリティや守秘義務との両立は可能である。測定対象、障害範囲、期間、確度、未解決事項を限定的に公開し、詳細証拠は監査可能な形で内部保存することができる。

責任を配分しても、単一犯人を作る必要はない

LINXはピアリングファブリックと、ルーターを本番へ投入するプロセスを管理していた。そこには構成自動化、監視、保守順序、リンク切り離し、セッションクリア、会員への連絡が含まれる。これらは、機器やファイバーを外部ベンダーが提供していても、交換事業者が直接管理する責任面である。

ファイバー事業者は、契約範囲内の物理修理や保守を管理する。機器・ソフトウェアベンダーは、製品調査、欠陥分析、修正版の提供を担当することがある。だが、LINXがベンダー調査の継続を報告したというだけで、特定企業の過失や法的責任が確定するわけではない。

会員は、自らの接続、BGPセッション、ルーティングポリシー、継続性設計を管理する。ルートサーバー、二者間ピアリング、複数LAN、別IX、トランジットをどう組み合わせていたかは会員ごとに異なり、公開記録はその全体を示していない。全会員が同じ影響を受けたとも、第二の接続契約が必ず独立した有効経路を提供したとも断定できない。

責任が複数組織へ分かれることと、責任が曖昧であることは同じではない。誰が経路劣化を把握したか。誰が変更延期を決められたか。誰が実稼働ルーターIDを検証したか。誰がプロセスをクリアできたか。誰がソフトウェアとハードウェアのテーブルを比較したか。誰が会員側到達性を確認したか。それぞれに所有者を割り当てられる。

この制御マトリクスは、過失認定をせずに運用責任を明確にできる。逆に、エンドツーエンド試験の所有者が存在しなければ、物理層、制御プレーン、機器、会員対応の各担当が自分のチケットを閉じても、サービス障害が残る可能性がある。

再発管理には版管理された証拠モデルが要る

再発を判断するには、症状の名称だけでなく、内部機構を比較する必要がある。「到達性問題」という同じ表現が使われても、物理経路の喪失、IGP IDの衝突、EVPNセッション、ASICプログラミングの不一致では、必要な対策が異なる。

各インシデントについて、観測時刻、実際の発生時刻、操作時刻を区別する。機器、テレメトリー、チケットシステムの時計も同期させる。時刻が不正確なら、トラフィックドロップより後に起きた制御プレーンイベントを原因と誤認することさえある。

修正前後の証拠には、構成だけでなく稼働状態を含める。ルーターID、隣接関係、VTEP到達性、EVPN経路、ソフトウェアおよびハードウェアMAC表、インターフェース、リンクアグリゲーション、パケット試験を、同じ変更識別子と時刻軸へ結び付ける。

11月に6月と同じハードウェアテーブル不一致が同じ条件下で再現されたなら、共通機構への確信は高まる。利用者から見た症状だけが似ており、内部証拠が異なるなら、確信度は低く保つべきである。再発分析は、確定していないものを確定したように見せる作業ではない。

ロールバックも証拠の一部である。ソフトウェア変更後に障害が発生し、その変更を戻して状況が改善したとしても、それだけで全症状の原因を立証するわけではない。版、導入時刻、症状、ロールバック時刻、再試験結果を保存し、どの仮説をどの程度支持するかを記録する。

ネットワークを映す運用指標

デプロイ成功率や平均復旧時間は有用だが、それだけでは今回の種類の不一致を測れない。自動化システム上では成功していても、古いプロセス状態が残る可能性がある。全体の復旧時間が短く見えても、一部の会員や宛先だけが長く到達不能である可能性もある。

ラボから本番への管理では、事後条件の不一致を測るべきである。意図したIDと実稼働IDが異なった回数、予定外のプロセスクリアや再起動が必要になった回数、古い隣接・経路・転送エントリーを投入前に発見した回数、ソフトウェアとハードウェアのテーブルが一致しなかった回数を追跡する。

劣化状態への露出も指標になる。設計された経路多様性を欠いた時間、その間に実施された変更件数、明示的にリスク受容された変更、実トポロジーを通るカナリア試験とロールバック証拠の有無を測る。

会員側検証については、代表観測点から試験したサービス範囲、広範な復旧と残存ケース解消の時間差、失敗プローブと成功した再試験の保存状況を確認する。中央監視だけを改善しても、選択的な転送障害を検出できなければ十分ではない。

ただし、チェック項目の完了数を目的化してはならない。形式上すべての欄が埋まっても、実際のパケット経路を試していなければ統制は空洞化する。無作為抽出、独立確認、実際のインシデント結果との照合を使い、指標が運用上の現実を反映しているかを検証すべきである。

公開記録から結論できないこと

公開資料は、影響を受けた全会員、プレフィックス、セッション、拠点、トラフィック量を示していない。各6月・11月事象の正確な継続時間や顧客別影響も完全には分からない。非公開の機器設定、プロセス状態、自動化トランザクション、ベンダーの欠陥記録も確認できない。

古いOSPFルーターIDが、6月と11月のすべての症状を単独で引き起こしたとは立証されていない。EVPN、VXLAN、OSPF、BGP、自動化、ディスアグリゲーテッド型ハードウェアが本質的に危険だともいえない。問題はアーキテクチャの名称ではなく、実装された状態をどのように検証したかである。

LINXの可用性数値から、顧客ごとの損害、サービスクレジット、契約違反、規制上の判断を導くこともできない。公表された技術情報は統制設計を考えるには十分に有用だが、法的過失を認定するための完全な事件記録ではない。

また、特定ベンダーが障害を引き起こしたと断定する根拠もない。標準文書や一般的なベンダー資料を使ってプロトコル挙動を説明することと、その企業を事件の原因主体として名指しすることは別である。

これらの制約は記事末尾の但し書きではない。分析全体の確度を決める境界である。LINXの技術更新と年次報告書から直接確認できる事項は明確に帰属させ、標準文書は一般原則の説明に使い、非公開の因果関係や損害については不確実性を残すべきである。

最終記録は稼働中のネットワークにある

LON2の事例が残す教訓は、ラボが危険だということでも、現代的なEVPNファブリックが複雑すぎるということでもない。意図した状態から稼働状態への移行を、運用証拠で閉じなければならないということである。

構成リポジトリには新しいルーターIDが記録され得る。NETCONFはその変更を正常に受理し得る。インベントリには正しい機器とポートが表示され得る。EVPN制御プレーンにはMAC情報が見え得る。年間可用性は100%に近い値を示し得る。それでも、パケット経路だけが誤っている可能性は残る。

最終的な運用記録は、ドメイン全体で観測された一意なプロトコルID、最新の隣接関係、整合したEVPN状態、ハードウェアに設定された転送情報、利用可能な物理経路、そして完了した会員向け到達性試験で構成される。これらを変更と障害のタイムラインへ結び付けることで、説明責任は抽象的な理念ではなく検証可能な仕組みになる。

この基準は自動化の価値も守る。自動化が事後条件を確認し、意図と稼働状態の不一致で停止するなら、手作業より強い統制になり得る。古いプロセス状態への対策は、自動化を捨てることではない。どの変更でプロセスクリアや再起動が必要かを契約化し、実際の結果を機械的に証明することである。

IXPは独立したネットワーク同士を接続する共有基盤である。交換事業者は各会員のポリシーを支配できないが、共有ファブリックの状態は証明できる。冗長性低下を明示し、重複IDを拒否し、制御プレーンと転送プレーンを照合し、代表的な会員経路を試験し、分からないことを正直に残せる。

LINXの公開記録は、この実務に有用な材料を提供した。光経路の劣化、残留したOSPF ID、ソフトウェアとハードウェアのMAC状態不一致、復旧措置、後日の類似症状、継続中の調査が公表されている。[1][2] これを単純な犯人探しへ変換するべきではない。次の本番投入を止め、確認し、再開するためのゲートへ変換すべきである。

未試験の冗長経路は設計上の約束にすぎない。設定ファイルにしか存在しない新しいIDも約束である。ソフトウェアにしか存在しないMACエントリーも約束である。説明責任が成立するのは、それらが実際のパケット転送として機能していることを、運用者が稼働中のネットワークから示したときである。

LINX LON2の2023年障害が突きつけた「ラボから本番へ」の稼働状態責任

なぜ重要か

要約

要旨