DMVPNフェーズ3：ショートカットを両方向で読む

一本のpingがスポークからスポークへ流れ、ハブ経由の長い道を行き、二本目は直接通るのを見る。その時点でショートカットが機能していると宣言したくなる。その結論は半分正しい。行きの経路がショートカットでも、戻りの経路はまだハブを通っていることがあり、各方向を証明する状態は別の状態だ。両方向を通し、設計を健全と認める前に三つの表を読もう。

実際に見えるパケット経路から始める

直接であるべき宛先を持つスポークから始める。最初のパケットを追う。まだショートカットが存在しないため、スポークのルートに従ってハブへ向かう。ハブはそれを転送し、フェーズ3の設計では、より良い経路があることを伝えるリダイレクトを送信元にも送る。

そのリダイレクトは引き金であり、証明ではない。ハブが最適化できるトラフィックを見たと言っているだけだ。送信元がショートカットを構築したこと、宛先が解決に応答したこと、戻りの経路がそれを使っていることは言っていない。

したがって最初の有用な観察は前後比較だ。ハブ経由の最初のフローと、その後の直接フロー。

一つのトンネルに見える三つの状態

ショートカットは三つの状態要素に依存し、それぞれに独自の寿命と独自のコマンドがある。

NHRPキャッシュエントリはオーバーレイアドレスをNBMAトランスポートアドレスにマッピングする。ルートまたはショートカットは、ある内部宛先をどこへ転送するかを決める。IPsecアソシエーションは結果として生じるトラフィックを保護する。応答の欠落は三つのどれからでも起こり得て、コマンドはどれが欠けているかを教えてくれる。

その順序で読む。マッピングが欠けていれば、残り二つは意味を持たない。

要求と応答を別々にたどる

スポークAから解決を要求し、何が返るかを見る。要求はサポートされたNHRP転送経路を通り、宛先はハブ経由ではなく直接応答できる。この非対称性は正常であり、だからこそ応答がやり取りの興味深い半分になる。

次に役割を逆にする。BからAへ送り、同じ三つの読み取りを繰り返す。片方向だけショートカットする設計は対称ではなく、非対称性は通常、片側で欠けているプレフィックスか、応答を得られなかった解決に由来する。

要求がハブを通ったからといって、相手の応答がハブを通る必要はない。それをエラーと読んで、存在しないルーティング障害を追い始めてはいけない。

ハブのルートだけでなく、リダイレクトを読む

ハブのルートテーブルは、ハブがパケットをどこへ送るかを示す。リダイレクトは、ハブが送信元に何をするよう求めたかを示す。これは別の事実であり、正しいルートを持ちながらリダイレクトを送らないハブは、すべてのフローをいつまでも長い経路に留める。ハブのNHRPイベントを確認し、対象のトラフィックに対してリダイレクトが生成されていることを確かめる。

フェーズ3は集約の意味も変える。ショートカット動作では、スポークはフェーズ2の設計が想定した具体的なリモートルートの全セットを必要としない。したがってスポーク側の集約ルートは、自動的に欠けているネットワークではない。集約を障害と読む前に、フェーズとルーティングポリシーを確認する。

この一つの誤解が、他の何よりも多くのDMVPNチケットを生む。

結論を欠けているオブジェクトとして記録する

許可されたアプリケーションフローとその応答で締めくくり、各方向が直接経路を使ったかどうかを記す。次に、結論を欠けていたオブジェクトとして書く。マッピング、転送ショートカット、保護アソシエーション、またはアプリケーション応答のいずれかだ。

ルーティング隣接と共有セキュリティアソシエーションは健全性の証拠であり、経路の証拠ではない。両方が完璧でも、すべてのパケットが長い回り道をすることがある。まず転送の判断を確認し、次にそれを運ぶアソシエーションを確認する。順序が重要だ。アソシエーションはどちらにせよ形成されるからだ。

その習慣は次のチケットで報われる。「トンネルは上がっているが遅い」は「BにはAのホストへのショートカットがない」になり、後者の表現は五分で直せる。コマンド出力を結論と一緒に残し、ベンダーのフェーズ3の手順もその隣に置いておく。