VPNバックアップがEIGRPの実行可能後継者にならない理由

二本目のトンネルが上がり、ルーティングテーブルは依然として一つの経路しか示していない、という明白な結論はプロトコルが気づいていないというものだ。通常は気づいて拒否している。EIGRPがバックアップを導入するのは、特定のループフリー試験に合格した場合だけであり、トンネルが上がっていることは、隣接の報告距離がその試験に合格するかどうかを何も語らない。その区別が答えのすべてであり、タイマーではなく算術である。

条件を正確に述べる

RFC 7868 は、隣接のループフリー経路に対する十分な検査として実行可能性条件を定義している：宛先に対する隣接の報告距離は、ローカルの実行可能距離より厳密に小さい必要がある。厳密に。以下でも等しいでもない。

その一つの不等式が、代替経路を実行可能後継者にする。ここでの他のすべては、その周りの記帳である。

役割の異なる二つの距離

報告距離とは、隣接が宛先について広告する値である。実行可能距離とは、最後のACTIVE–PASSIVE遷移以降に知られた最小の総メトリックの記録であり、そのため現在の最良経路のメトリックと異なることがある。この二つを混同すると、自信に満ちた誤った結論が生まれる。

運用画面では、距離らしい列がいくつか並んでいる。使用している列の見出しを読み、隣接の完全に計算された経路メトリックは、それがあなたに報告した距離と同じ量ではないことを覚えておく。

一つの計算例

実行可能距離が1000の宣言された例を取る。900を報告する隣接は試験に合格し、実行可能後継者になれる。1000を報告する隣接は、条件が厳密な不等式であり等しいだけでは足りないため不合格になる。

それらの数値は算術であり、リンク速度ではない。特定のルーターについての予測や推奨メトリックとして読んではならない。

検出は適格性ではない

仕組みが死んだピアを素早く検出しても、EIGRPにはまだ適格な代替がないことがある。検出は一つの段階であり、協調的な経路計算は別の段階で、実行可能後継者が存在しないときにだけ始まる。条件に失敗することは、代替経路が物理的にループしていることを証明しない。ローカルの近道試験が保証を確立しなかったという意味であり、計算はその結果を扱わなければならない。

生存タイマーを短縮しても、決して存在しなかった到達性を作り出すことはできず、設定された帯域幅や遅延の値を変えることは容量の測定ではない。

フィールドを読み、次にアプリケーションを試す

宛先、現在の後継者、候補の隣接、その報告距離、実行可能距離、結果の経路状態を記録する。 show ip eigrp topology 10.10.10.0/24 は単一のプレフィックスについてその大半を与える。次に、次のホップを実際に運ぶトンネル経路に判断を結びつけるのは、ルーティングテーブルとトンネルテーブルは、どのインターフェースが使われているかで食い違うことがあるからだ。

承認された観察のもとで、検出、経路選択、アプリケーション自身の回復という三つを別々に追う。その順序は、欠けている部分が適格なバックアップなのか、その下のVPN経路なのか、ワークロードの再接続なのかを教えてくれる——すべての遅い回復に別のタイマーが必要だと決めつける代わりに。

有用な習慣は、他の何かに触れる前に不等式を確認することだ。コマンド一つで済み、議論が決着する。