← 記事一覧

ネットワークには記憶がある

14:02 にネットワークが信じていたものを再構成する。そして、何が変わったのかと、何を知ったのかの違い

Michel Wijnberg

このシリーズのここまでのツールは、すべていまについての問いに答えます。しかしエンジニ アがいちばん助けを必要とする 2 つの瞬間について、その時制は間違っています。

1 つ目は障害の最中です。ネットワークの挙動がおかしく、必要なのは現在の状態ではなく、誰か が直し始める前の 20 分前の状態です。2 つ目は障害のあとです。ネットワークは復旧し、全員が 仮説を持っていて、そして壊れた時点のトポロジーを誰も出せません。

Osprey の答えは時計です。

7 月 29 日 14:02 のトポロジー。下部にタイムトラベルのスクラバー
7 月 29 日 14:02 のトポロジー。下部にタイムトラベルのスクラバー

これは録画の再生ではありません。このキャンバス上のすべての要素が、あるタイムスタンプに対 して再構成されたものです。デバイス、リンク、そのコストと状態、エリア所属。下のスクラバー には Jul 29, 14:02(30/36) とあります。選択した 24 時間の窓における、36 個の異なる トポロジー状態のうちの 30 番目という意味です。

そのトラック上の点はどれも、ネットワークが本当に別物だった瞬間です。

どの監視ツールも履歴を保持しています。だからこの一文にはもっと鋭い縁が要ります。彼らが保持して いるのは測定値です。CPU は 83% だった、インターフェースは 4 Gbit 出ていた、ポーリングは成功 した。これらはネットワークに対して取った読み値であり、14:02 の時点で機器が忙しかったことを教 えてくれます。その機器が何を信じていたかは教えてくれません。Osprey が保持するのは状態で す。どの隣接が存在したか、どの経路がどのメトリックで導入されていたか、ルーターがどのエリアに属 していたか、どの BGP パスが選ばれ、なぜ選ばれたか。違いは、本物の問いを立てた瞬間に現れます。 測定値の履歴は、14:02 にリンクが飽和していたことを教えられます。状態の履歴は、その 4 分前に ABR が summary を取り下げ、地域の半分が突然遠回りを始めたから飽和したのだ、と教えられます。前者は タイムスタンプ付きの症状です。後者は、ネットワーク自身の推論が保存されたものです。


何かが起きたときにだけ存在するスナップショット

素朴な実装はタイマーでスナップショットを書きます。5 分ごとにトポロジーをダンプする。単純 ですが、同一のコピーでほぼ埋め尽くされたデータベースと、その先が見えない解像度の限界がで きあがります。

Osprey はトポロジーが変化したときにスナップショットを書き、それ以外では決して書きません。

コレクターから来たトポロジーイベントは、まずハッシュされます。

// computeTopologyHash computes an FNV-64a hash over the topology snapshot data.
// Uses addition accumulation of per-element hashes for order-independence.

デバイスは router ID と ABR/ASBR ビットを、リンクは方向を正規化したルーターの組と両側のコ ストおよび状態を、スタブネットワークとインターフェースはそれぞれの内容を寄与します。累積は 加算なので、ハッシュは要素が到着した順序に依存しません。2 つのコレクターが同じエリアを別々 の順序で報告しても同じハッシュにならなければ、あらゆるポーリングが変化に見えてしまいます。

ハッシュはそのエリアの直前のものとメモリ上で比較されます。同じなら何も書きません。異なれば、 スナップショットの行が 1 つ挿入されます。

その結果、構造上、情報密度の高いタイムラインができます。私のラボはこの 30 日間で、 51 エリアにわたる 478 件のスナップショットを生成しました。環境全体で 1 日およそ 16 件、そのひとつひとつが実際の差分です。スクラバー上の点はサンプルではありません。イベン トです。

これはまた、安定したエリアは何時間も行を持たないことがある、ということでもあります。それは 欠落ではなく正しい状態です。何も起きなかったので、記録すべきものが何もないのです。選んだタ イムスタンプ以前で最も近いスナップショットが、そのタイムスタンプにおける状態そのもので す。


タイムトラベルは 1 つの機能ではありません

時計は見えている部分です。それを有用にしているのは、およそ 20 個の API エンドポイントが同じ at= パラメーターを受け取り、その時点として答えることです。トポロジーグラフ、LSDB ブラウザ、 パス計算、SPF ツリー、ルーターごとの RIB、エリア間経路と外部経路、ASBR エントリー、インター フェース、スタブネットワーク、BGP ピア、BGP のベストパス、ピアごとの受信経路。

BGP はスナップショットより強い扱いを受けます。BGP はトポロジーよりはるかに頻繁に変わるからで す。BGP はバイテンポラルな変更履歴として保存されます。すべてのベストパス、ピアセッション、 そして(オプションで)受信したすべての RIB エントリーが、valid_fromvalid_to を持つ区間 であり、valid_to が開いていれば「まだ真」を意味します。時刻 T の問い合わせは、再構成ではなく 述語になります。valid_from <= T AND (valid_to IS NULL OR valid_to > T)

そこにある 2 つの細部が、正しくするのにいちばん時間がかかったところで、どちらも何かを記録し ないことについての話です。

  • 区間の乱立は属性ハッシュによって抑えられており、そのハッシュは IGP メトリックと解決済みの ネクストホップデバイスを意図的に除外しています。これらは IGP が再収束するたびに変わるので、 もしそれで新しい区間が開いてしまえば、無関係なリンクコストが動くたびにネットワーク中の BGP プレフィックスがフラップしているように見えてしまいます。
  • ピアのダウンは大量の経路取り消しではなく、監視のギャップとして記録されます。BMP セッショ ンが切れたとき、ルーターは 10 万本のプレフィックスを取り消したわけではありません。私が知らさ れなくなっただけです。それを取り消しとして書けば、監視セッションがしゃっくりをするたびに、そ のネットワーク史上最大のルーティングイベントを製造することになります。

どちらも、安易な実装がイベントを捏造してしまうケースです。イベントを捏造する履歴は、履歴がない より悪い。あなたがそれを調査してしまうからです。


過去でシミュレーションする

2 つのモードは組み合わせられます。これが私の、この製品でいちばん好きなところです。

タイムトラベルに入り、時計を合わせ、そのうえでシミュレーションに入れます。キャンバスには SIMULATION @ <timestamp> のウォーターマークが載り、what-if はその瞬間に存在していたトポロジー に対して走ります。

つまり、こう尋ねられるということです。

14:02 の時点で実際にあったネットワークで、この障害は乗り切れただろうか。

今日のトポロジーに対してではありません。今日のものは、その後修理され、メトリックを付け替えられ、 拡張されています。本当にそこにあったものに対して、です。障害の事後分析にとって、それは「弁明でき る答え」と「もっともらしい答え」の違いです。

自分の限界も守ります。過去の時点での BGP ピア障害分析は、そのスコープについてフル RIB の履歴が記録 されていることを要求します。記録されていなかった場合、結果は黙った近似ではなく、明示されたスキップ です。

BGP effects (peer failure, hot-potato exit shifts, BGP traffic) are not evaluated at this time: no full-RIB history (history_mode=‘full’) is recorded for the scope. Enable full history mode on a BMP target to time-travel BGP.

このメッセージは、欠けている入力と、それを与える設定を名指ししています。行動に移せるメッセージです。


過去にないものを、はっきり口に出す

いくつかのものには本当に履歴がありません。それらに触れるエンドポイントは、ライブのデータを履歴デー タの装いで黙って出す代わりに、そう述べます。

LSDB ブラウザに過去の時点を尋ねると、レスポンスにはこう付きます。

Topology and route LSAs reflect the selected time; LSA header metadata (age/seq/ checksum) is not historized and shows live values.

過去の時点のドメイン間パスを尋ねると、答えが実際にライブの根拠に寄りかかった場合にかぎり、説明 にステップが増えます。

Time travel: L2 detail is live: L2/port annotations on this path reflect current LLDP/CDP wiring, not the selected time. L2 adjacency is not historized.

Time travel: entry resolved via current router-id: identity attributes (router-id, local address) are not historized and were borrowed from the live session record.

条件付きであることが重要です。完全に履歴から証明されたつなぎ合わせにはどちらの注記も付かないので、注 記が現れたときにはそれが意味を持ちます。すべての履歴ビューに「一部のデータはライブかもしれません」と いう包括的な断り書きを出せば、技術的には正しく、恒久的に無視され、そして役に立ちません。

もうひとつ、はっきり述べておく限界があります。そうしないと、あなたは戸惑いながら自力で見つけることに なるからです。**タイムトラベル中はリンク使用率の色分けがオフになります。**トラフィックのヒートマップ は、履歴のトポロジーの上にライブの負荷を表示する代わりに空白になります。それは安全な振る舞いであり、 間違った振る舞いです。空白は「この時刻には利用できません」と読まれるべきところを「トラフィックなし」 と読まれてしまいます。それを直すリーダーは予定済みで、未実装です。


何が変わったのかと、何を知ったのかの違い

タイムトラベルには相棒のレポートがあります。2 つの時点を比較して差分を並べるものです。

Topology Diff:デバイスとリンクの変化はなし、24 時間で 56 のスタブネットワークが追加
Topology Diff:デバイスとリンクの変化はなし、24 時間で 56 のスタブネットワークが追加

AS 200 の過去 24 時間:デバイスの追加も削除も変更もなし。リンクの追加も削除もなし。そしてスタブネッ トワークが 56 件追加、そのすべてが IPv6 の /128 ループバックです。

これはネットワークの変化のように見えます。違います。

それら 56 のプレフィックスが最初にデータベースへ入った時刻を調べたところ、すべてが今朝の 10:00:49 から 10:01:14 のあいだに到着していました。25 秒の窓です。64 台のルーターにまたがる 56 のループ バックを 25 秒で再設定するネットワークはありません。実際に起きたのはディスカバリの一巡です。それらの プレフィックスはずっと OSPFv3 のデータベースにあり、これは Osprey が記録し始めた瞬間なのです。

この区別には名前を付ける価値があります。両者を混同すると、起きてもいない変化を人に探させることになる からです。

トポロジーの差分が教えてくれるのは、モデルが何を知ったかです。ネットワークが何をしたかと同 じものではありません。

一致することもあります。リンクが落ち、モデルがリンクの落下を記録する。一致しないこともあり、その手がか りはたいていタイムスタンプの形にあります。本物のネットワークの変化はプロトコル収束のタイミングで到着し、 モデルの変化はポーリング周期のタイミングで到着します。25 秒で 56 の同一プレフィックスは、変化の服を着た ポーリング周期です。

いま見ているのがそのどちらなのかを教えられないオブザーバビリティ製品は、いずれ誰かの午後を奪います。 Osprey はそれを自動でラベル付けしません。差分はモデルが記録したものを示し、上の推論は私のものであってツ ールのものではありません。しかしすべての行には、あなた自身が判断するために必要なタイムスタンプが載って います。誠実なツールが最低限あなたに負うものは、それだと私は考えています。


このシリーズが終わる場所

3 つのシリーズ、そして実のところひとつの主張に、3 つの方向からたどり着きました。

シリーズ 1 はモデルが真であるかについてでした。ネットワークをありのままにモデル化し、その一部 にならずに観測し、転送をホップごとに再現し、推測を拒む。

シリーズ 2 は根拠が順位づけ可能かについてでした。複数の真実を同時に抱え、矛盾する情報源を格付け し、顧客より先に自分の間違いを見つける。

シリーズ 3 は、それで何が手に入るかについてでした。それを使って推論できるほど正しいモデルです。 何かを壊してどうなるか見る。何が何に依存しているか尋ねる。測れないものを推定し、推定していると述べる。壊 れる 1 時間前にネットワークが信じていたものを尋ねる。

信用していないモデルの上では、そのどれも機能しません。シリーズ 1 のすべての正直な拒否と、シリーズ 2 のす べての格付けされた根拠は、シリーズ 3 の答えが意味を持つために存在します。9% が作り話のトポロジーの上に建 てた what-if は計画ツールではありません。きれいなキャンバスの付いた乱数生成器です。

第 8 回は、その主張を最短の形で述べました。トポロジーエンジンとは ネットワーク状態のコンパイラである。雑然として矛盾した入力、決定論的なモデルの出力、そしてルーター自身が オラクル。コンパイラはもっともらしさではなく適合性で判断され、この 12 本の記事のすべての拒否は、答えが手 に入らない場合に適合性が要求する代償です。

モデルを正しくすること。どうやって知ったかを述べること。そして、そのうえで初めて、問いを投げ始めること。


シリーズ全体:信頼3 つの IGP、1 枚の地図 · ゼロフットプリント · ホップバイホップの真実 · Osprey が推測を拒むこと真実を組み立てる同じルーター、3 つの異なる真実 · ネットワークが自分自身と食い違うとき · トポロジーに嘘をつかれた日 · ネットワークエンジニアのユニットテスト見ることから、推論することこれを壊したらどうなる? · 影響範囲 · 測れないものを推定する · そして本稿。

Osprey は自社運用型のネットワーク可視化・エンジニアリング基盤です。32 台まで無料でお試しいただけます。他の記事を読むこともできます。