これを壊したらどうなる？

信頼できるモデルは、まだ尋ねられたことのない問いを投げられて初めて持つ価値がある

2026年8月22日 Michel Wijnberg

このシリーズの最初の 8 本は、モデルを正しくすることについてでした。ネットワークの一部にならずに発見し、転送をホップごとに再現し、推測を拒み、そして自分のツールが作り話を描いていたと痛い目にあって知る。

そのすべては準備です。単に正確なだけのネットワークモデルは、とても高価な写真にすぎません。その労力を払う理由は、実際のネットワークには投げられない問いを、モデルには投げられるようにするためです。

これを壊したらどうなる？

この問いがメンテナンス窓を決めます。深夜 3 時にカードを抜いて耐えられるかどうかを誰かが言わねばならず、たいていは頭の中のモデルと前回の障害の記憶から答えます。これから述べることが面白いのは、Osprey にシミュレーターがあるからではありません。障害が実際に起きる前に、その障害について考えられるようになるからです。

変更できる 7 つのこと

Osprey のシミュレーションモードは、ライブのモデルを取り、複製し、変異を適用し、再計算します。変更を許すもののリストは短く、その短さは意図的です。

変異	何をするか
`link_failure`	リンクを落とす
`node_failure`	ルーターを落とす
`cost_change`	リンクのメトリックを変える。順方向と逆方向は独立
`hypothetical_link`	存在しないリンクを、コストと速度付きで追加する
`hypothetical_node`	存在しないルーターを追加する
`srlg`	共有リスクグループを落とす。1 操作で N 本の相関したリンク障害
`peer_failure`	BGP セッションを落とす

それ以外はすべて unknown mutation type として拒否されます。エリア再編の変異も、再配布の変異も、カスケード障害の変異もありません。どれもデータをでっち上げずには実装できなかったからです。この点にはあとで戻ります。

ケーブル 1 本と、それに対してネットワークがすること

ラボの実例です。nrt1-cr1 ↔ sea1-cr1 は AS 200 の太平洋横断バックボーンリンクで、OSPFv2 でのコストは 10、Osprey がこのテナントの 2 つの OSPF インスタンスにわたって保持する 275 本のリンクのうちの 1 本です。右クリックして Simulate Failure を選びました。

シミュレーションの Impact タブ：孤立 0、変化したパス 56、新規 SPOF 0

上段の 3 つの数字を読んでください。**到達不能になったものはなし。56 のパスが変化。新しい単一障害点は出現せず。**評価全体はサーバー側で 57 ミリ秒でした。

次に Failed Links の見出しを見てください。ここで見落とされがちなことが起きています。 2 links です。私はケーブルを 1 本クリックしたのに、Osprey はリンクを 2 本落としました。そのケーブルは OSPFv2 と OSPFv3 を2 つの独立したプロトコルインスタンスとして、2 つの独立したコストで運んでいるからです。線を落とせば、両方で落ちます。ケーブル 1 本につきエッジ 1 本をモデル化するツールは、その 2 つの命のどちらを終わらせるかを決めなければなりません。

面白いのは、その 56 の内訳です。

15 が増加：パスが高くつくようになりました。sea1-cr1 → nrt1-cr1 はコスト 1 からコスト 11 へ。直結リンクが 3 ホップの経路に置き換わりました。
41 が迂回：パスはホップが変わり、コストはまったく動きませんでした。

じっと見る価値があるのは 2 つ目の数字です。41 の送信元/宛先ペアがネットワーク内の別の経路を通り、その代償を何も払っていません。等コストの代替がすでにそこにあったからです。冗長性を形容詞ではなく測定値として表すと、こう見えます。「経路は多重化されています」は主張です。「影響を受けた 56 ペアのうち 41 が同一コストで迂回する」は数字であり、メンテナンス作業を午前 3 時にする必要があるかどうかを教えてくれるのはそちらの数字です。

ここではルーターに何も打ち込んでいません。ラボはリンクを 1 本も失っていません。私はモデルに尋ねたのです。

画面上部の拒否

では、最初のスクリーンショットの琥珀色のバナーを見てください。これは告白であり、パネルの残りを私が信用している理由でもあります。

simulated paths are shown as an SPF projection (source-rooted least-cost tree) so before and after stay comparable; the live path panel shows the hop-by-hop forwarding chain, which can differ where an intermediate router’s own routing table disagrees with the source’s view

第 3 回は、送信元を根とする回廊が IP 転送のモデルとして誤りだという主張で、計測がその裏づけでした。エリア間のルーターペア 2,839 のうち 360 で、どのパケットも通らないホップを回廊が含んでいたのです。私はそのエンジンを、各ルーター自身のルーティングテーブルをたどるものに置き換え、4,032 ペアすべてで検証しました。

そして、シミュレーションでは意図的にそれを使いません。

理由はコードにあり、この製品でいちばん誇りに思っている一文です。

// The panel shows the hop-by-hop forwarding chain (path_chain.go): every
// router's OWN routing table, read from the per-area LSDBs. A what-if topology
// has no such tables. The Type-3 summaries the surviving ABRs would
// re-originate after the mutation are exactly the thing that cannot be
// synthesised, and inventing them would make the simulation's numbers agree with
// nothing. So both simulation sides stay on the source-rooted SPF projection,
// consistently with each other, and say so. A labelled projection is honest; a
// baseline that disagrees with the baseline is not.

各ルーター自身のテーブルをたどるには、変更後に各ルーターのテーブルがどうなるかを知る必要があります。OSPF ではそれは、生き残った ABR が再生成するであろう Type-3 の summary-LSA に依存します。障害はまだ起きていないので、その LSA は存在しません。推測することはできます。正しく推測することはできません。そして推測した summary の上に組み立てたホップバイホップのチェーンは、検証済みエンジンの権威をすべてまといながら、検証はまったくないものになります。

ですから比較の両側とも、はっきりラベルの付いた投影にとどまります。「変更前」の絵は、「変更後」の絵と噛み合い続けるために、意図的に精度を落としてあります。「56 パスが変化」の中身が実は「本物の変化 36 と、両側が別エンジンを使ったことによる見かけ上の差 20」だとしたら、それは差分ではありません。数字の付いたノイズです。

EIGRP：天井はプロトコルではなく、私のデータです

EIGRP テナントで何かを落とすと、Osprey は投影する代わりに立ち止まります。

the simulated change affects the observed EIGRP chain (forward and reverse). Osprey cannot predict DUAL re-convergence: the topology tables it reads carry the DUAL distances, not the metric components (bandwidth, delay) a recomputation needs. After a real event the live view shows the new chain.

EIGRP には、再計算の土台になるリンクステートデータベースがありません。Osprey が持っているのは、 CISCO-EIGRP-MIB から読み取った各ルーター自身のトポロジーテーブルであり、その 12 列が運ぶのは DUAL の距離（feasible distance、computed distance、reported distance）であって、その距離が組み立てられた構成要素ではありません。

変更後に DUAL を再計算するには、最小帯域、総遅延、信頼性、負荷、MTU、ホップ数が必要です。それらは実機には存在します。e-ams1-cr1 で show ip eigrp topology 10.64.0.0/15 を実行して確認しました。ただ、Osprey が読む MIB テーブルには入っていないというだけです。

この区別は意図的にコードコメントに書き込んであります。

// Scoped to what Osprey READS, deliberately not to what SNMP can carry: … A future
// CLI enricher could lift part of this ceiling, so the sentence must not read as a
// permanent property of the protocol.

**「このプロトコルはシミュレートできない」と「今はその入力を収集していない」**のあいだには本物の違いがあり、その両者をぼかす製品は、二度と聞かなくていいですよ、と暗に言っているのと同じです。これはデータ収集の天井であり、持ち上げられます。持ち上げたとき、このメッセージは消えます。

その下には、もっと小さく鋭いルールがあります。変異が純粋な除去（リンクまたはノードの障害）であり、除去されたものが観測されたチェーン上に存在しないと証明できる場合、Osprey は実際のチェーンを表示し続け、その理由を述べます。“observed live EIGRP chain: the simulated failure does not touch it (EIGRP re-convergence itself is not modelled)“。どこか別の場所で容量を取り除いても、それを使っていなかったディスタンスベクターの経路が良くなることは決してありません。しかしコスト変更や新しいリンクは、どこからでも経路を引き寄せうるので、そちらは常に「触れている」と数えます。このエンジンは、拒否しなければならないときにきっちり拒否するのであって、一律に拒否するのではありません。

変異のリストに入っていないもの、そしてその理由

7 つの変異は、入力をでっち上げずに実装できたものです。欠けているものは、理由を明示したうえで欠けています。

**エリアの再編。**ABR を移動したりエリア境界を引き直したりすると、そもそもどの summary-LSA が存在するかが変わります。それはトポロジーの変異ではなく、別のトポロジーです。
**再配布の変更。**それらは route-map や prefix-list に依存しますが、Osprey にはそれらが見えません。読めないポリシーをモデル化することになります。
**カスケード障害。**2 番目の障害を予測するにはキューと TCP のダイナミクスが必要で、トポロジーツールがそれをモデル化できると主張する筋合いはありません。リスクを示すこと。カスケードを予測しないこと。

どれもデモ映えは見事でしょう。どれも、裏に何もない数字になるでしょう。

要点

シミュレーションは、トポロジー製品がモデリングの労力を回収するか、それとも露呈させるかの場所です。データモデルで取ったあらゆる近道が、ここでは自信ありげな誤答として現れます。what-if には照合すべき正解が存在しないからです。障害は起きていないので、誰もあなたに反論できません。だからこそ、これはいちばん慎重であるに値する機能なのです。

正直なバージョンは、スクリーンショット 1 枚あたりの見栄えでは劣り、午前 3 時にはかなり役に立ちます。変更できる 7 つのもの、出てくる 4 つの数字、そしてそれをどのエンジンが出したかを説明するバナー。

次回：リンクが 1 本落ちる。では、ネットワークのどの部分が実際にそれに依存していたのか？影響範囲。