Osprey が推測を拒むこと
私が作ったもののうち最も重要なのは、一連の「拒否」です
Michel Wijnberg
推測するネットワークツールは、無知を認めるツールより劣ります。その理由は哲学的なもの ではなく、運用上のものです。
ツールが「分かりません」と言えば、あなたは自分で調べに行きます。もっともらしい答えを 出せば、あなたはそれに基づいて動きます。そして画面上には、正しい答えと自信のあ る答えを見分けるものが何もありません。ですから障害モードは「ツールが間違っていた」 ではなく、「ツールが間違っていて、しかも確かめる理由が自分になかった」です。
そこで Osprey には、私のあらゆる製品的直感を上書きするルールがあります。**根拠を述べ るか、根拠がないと述べるか。**決して補間しない。データに見えるプレースホルダーを決し て描かない。
実際に出荷している製品でそれがどう見えるかをお見せします。
1.「このパスは良いやり方では計算できません」
前回の記事はホップバイホップの転送チェーンについてでした。 送信元を根とする回廊を 1 本描くのではなく、各ルーター自身のルーティングテーブルをたど るもので、AS 200 の 4,032 のルーターペアすべてに対して厳密に検証されています。
このエンジンは OSPFv2 では動きます。IS-IS では動きません。そして Osprey は黙って フォールバックするのではなく、そう述べます。
4. Hop-by-hop forwarding chain unavailable Showing the source’s own shortest-path view, which every intermediate router may legitimately disagree with. Osprey does not model this protocol’s inter-area reachability hop-by-hop (IS-IS carries inter-level reachability differently from OSPF and has no Type-3 equivalent to persist, so Osprey stores nothing from which L1↔L2 route leaking could be reconstructed. An L1-only source in particular forwards on the attached-bit default toward its nearest L1/L2 router, not by end-to-end cost; EIGRP has its own observed chain).
このメッセージについて 3 点。
答えを出したモデルを名指ししています。送信元自身の最短経路ビューだと分かるので、 2 つのエンジンのどちらを見ているかが分かります。理由を名指ししています。Osprey は L1↔L2 のルートリークを再構成できるものを何も保存していません。これはプロトコルの限界 ではなく Osprey のモデルの限界です。IS-IS に Type-3 の summary LSA がないのは、そもそも 必要なかったからで、レベル間の到達性は L2 の LSP と attached ビットで運びます。そして 具体的な帰結を名指ししています。ここが実際に効いてくる部分です。L1 のみの送信元は、 そもそもエンドツーエンドのコストで転送していません。ISO 10589 に従って attached ビット をたどり、最も近い L1/L2 ルーターへ向かいます。その実際のファーストホップは、描かれた パスとまったく関係がないかもしれません。
パスは今も表示されます。最短経路ビューは本当に有用だからです。ただ、より強い答えのふり をすることは許されていません。
同じ規律は OSPFv3 にも、プロトコルインスタンスのエリアの一部しか含まないスコープにも、 仮想リンクを持つエリアにも、そのアドレスファミリを運べるプロトコルインスタンス 2 つに またがって存在するルーターにも適用されます。それぞれに名前の付いた理由が用意されていま す。どれも古い絵をこっそり復活させたりはしません。
2.「この数字は何も意味しません」
EIGRP はリンクステート型のプロトコルではありません。参加すべきデータベースはなく、走ら せる SPF もなく、そして重要なことに、ホップごとのコストを足し合わせる意味のある方法があ りません。EIGRP の複合メトリックは単一のリンクではなくパス全体を表すからです。
そこで Osprey は合計を印字しません。
Observed EIGRP forwarding chain EIGRP has no link-state database; this path follows the routers’ own DUAL result (per-hop topology tables), so there is no summed cost to show: 3 RIB-installed variant(s) shown alongside (the RIB holds equal next-hops).
代わりに得られるのは、各ルーターが宛先へ向けて自分で計算した距離が、チェーンに沿って 減っていく様子です。712704 → 710144 → 658944 → 556544 → 505344 → 428544 → 223744 → 133120 → 128256。
これらの数字はすべてルーターから取れたものです。導出したものは 1 つもありません。空欄の 「合計コスト」は実装の抜けではありません。存在しない量を正しく描画した結果です。
同じルールは AS 境界をまたぐときにも発火します。そこでは OSPF のコストと IS-IS のコスト が、互いに無関係なメトリック空間の数字だからです。
Per-segment costs (never summed) | 15 hops
3.「セグメントごとに、どれだけ確信しているかを正確にお伝えします」
ドメインをまたぐパスは計算できません。根拠からつなぎ合わせることしかできず、しかも 根拠の質は一様ではありません。そこで Osprey はパス全体に一括の確信度を出すのではなく、 セグメントごとに格付けします。
AS 200 ospfv2/1 cost 20051 は resolved。AS 300 isis/LAB cost 1320 は
inferred。同じパス、同じ画面、異なる認識論的地位、どちらにもラベルが付いています。
これらのバッジの背後には、順に試される厳密なはしごがあります。
| 段 | 根拠 | 確信度 |
|---|---|---|
| a | そのドメインの境界にある、宛先をカバーする RIB の行 | resolved |
| a2 | 自身の BMP RIB が次の AS 経由で宛先をカバーしているルートサーバー | inferred（bmp-rib-rs） |
| b | チェーン上の次の AS へ向けた確立済み eBGP セッション | inferred |
| c | 何もなし | opaque：注記付きのセグメントとして描画し、ホップは一切描かない |
重要なのは (c) の段です。トラフィックがそのドメインにどう入るのかを Osprey が確定できない とき、もっともらしく見えるホップの並びを補間したりはしません。明示的に不透明なセグメントを 描いて自分の状況を説明し、原因に対処できる場合は、一般的な謝罪ではなく対処できる内容を述べ ます。メッセージはこういう形をとります。
AS 65000 has no areas in the selected scope. Include its areas to trace through this domain
これは何か手を打てるメッセージです。「エントリーポイント不明」ではそうはいきません。 （これらの記事のラボのパスはすべて解決するので、その注記自体はここのスクリーンショットには ありません。スコープが本当にトランジット AS を落としているときに発火します。）
(a2) の段が存在するのには、名指しする価値のある具体的な理由があります。透過的なルートサーバ ーは AS_PATH に決して現れません。ルートサーバー自身の RIB を読まない限り、IX を経由した迂回 はそもそも見えません。実際には直結ではないのに、パスは直結に見えてしまいます。
4.「これらのポートは事実 / 推測 / 本当に曖昧、のいずれかです」
Osprey が eBGP のトランジションに物理ポートを注記するとき、4 つの状況をひとつの自信ありげな 答えに潰さず、区別します。
- リンクペアがちょうど 1 組、ファブリックの代替なし → ポートを事実として記述：
jfk1-gw1 Et1/1 → i-jfk1-gw1 Et1/2 - 並列リンク → 集約として示し、不確かさを名指し： “3 parallel L2 links: Gi2↔Et1/0, … (session link undetermined)”
- 両端の境界が共有ブリッジ上にあり、直結リンクはない → 接続ポートを添えたファブリックの 存在、すなわち両者のあいだにブリッジがあるという記述であって、セッションがそこを通ると いう主張は決してしない
- 直結リンクと共有ファブリックの両方がある → 両方を名指ししたうえで、どちらも選ばない という明示的な曖昧さ
さらに補助ルールとして、行は 13 時間より新しくなければならず、6 時間を超えると経過時間を開示 し、sysname だけで一致したブリッジはポートの主張を拒否権で潰しつつ、それ自体が事実として表示 されることは決してありません。
いちばん強い段は推測を事実に格上げします。BGP セッションの両方のアドレスが、機器の IP-MIB の
バインディングを通じて特定のポートに解決されたとき、注記は ip-bound となり、曖昧さのゲート
を上書きします。その時点でもう推論ではないからです。
5.「これらのフィールドは利用できません」
いちばん微妙で、私のお気に入りです。
13382 LSAs reconstructed (LSAge, SeqNo, Checksum not available)
これらの LSA はプロトコル隣接で受信したものではなく SNMP ウォークから再構成したもので、OSPF MIB の SNMP ウォークは LSA の中身は与えますが、ライブのヘッダーフィールドは与えません。
誘惑に負けた実装はゼロの列を 3 つ出します。見た目はきれいで、ソートも問題なく効き、そして嘘 です。しかも検出できない嘘です。エージ 0 の LSA は、欠測ではなく、たった今フラッディング されたばかりの LSA のように見えるからです。
ですから列そのものを出さず、理由をパネルの上部に印字します。
6. 自分のいちばん良いエンジンを使うことを拒む
いちばん満足しているものです。機能をひとつ諦める代償を払ったからです。
Osprey のシミュレーションモードでは、リンクを落とし、ノードを外し、メトリックを変えて、トラ フィックがどう移るかを見られます。当然の一手は、真新しいホップバイホップのチェーンエンジンを 変異後のトポロジーに対して走らせることです。
Osprey は意図的にそうしません。
変異後の転送チェーンは計算できません。各ルーター自身のテーブルをたどるには、変更後に各 ルーターのテーブルがどうなるかを知る必要があり、それは生き残った ABR が再生成するであろ う Type-3 の summary LSA に依存します。その LSA はまだ存在しません。推測なしには合成できませ んし、推測すれば、検証済みエンジンの権威をすべてまといながら検証はまったくない、そういうホッ プバイホップのパスができあがります。
ですからシミュレーションの両側は、はっきりラベルの付いた SPF 投影にとどまり、その旨を通知に 書きます。見栄えのよい答えは手に入りました。ただ、それは本当ではなかったというだけです。
なぜこれが謝罪ではなく機能なのか
私はネットワークトポロジー製品を売っています。上に挙げた振る舞いはどれも、スクリーンショット を競合より少しだけ見栄えの悪いものにします。自信のある答えのほうがデモ映えする、と指摘される 会話も経験済みです。
そのとおりです。そしてそれは、このツールを持つ価値そのものを壊します。
エリアが分断された午前 3 時のエンジニアに必要なのは、美しい絵ではありません。その絵のどの部分 に賭けてよいかを知ることです。自分の根拠を格付けする製品（resolved, inferred, opaque, unavailable, not computable）は、画面上のすべてに疑いを均等にばらまく代わりに、疑うべきところ に疑いを集中させてくれます。
そのような信頼を勝ち取っているのが前回の記事の計測です。ルーターから 読み取った正解に対して、4,032 のルーターペアのうち 4,032 を正確に再現しました。そしてそれを守 っているのが、この記事の拒否です。4,032 回正解して 4,033 回目に黙ってはったりをかますツールは、 自分がいまどちらのケースにいるのかについて、あなたに何ひとつ教えていません。
知っていることを言う。どうやって知ったかを言う。知らないときは、知らないと言う。
これで第 1 シリーズは終わりです。ラボツアーはこちら、パッシブディ スカバリのアーキテクチャはこちら、ホップバイホップのパスエンジンは こちら。複数の真実を同時に抱えること、矛盾する根拠を順位づけること、 自分の製品が間違っていると証明することについての第 2 シリーズは、 同じルーター、3 つの異なる真実から始まります。