DMVPN のルート集約と NHRP サマリーマップは別物: 触るテーブルが違う

誰かがスポークの集約を依頼し、チケットはハブ上のプレフィックスが減った状態で閉じられました。一週間後、以前は直接通っていた拠点間のトラフィックが再びハブを経由するようになり、誰も二つの変更を結び付けません。スポークを集約するという表現は、二つの別のテーブルに触る二つの別の操作を指しています。別の DMVPN の例からコマンドを借りる前に、どちらの状態を減らしているのかを名指ししてください。

症状: 直接通っていたスポーク間トラフィックがハブ経由に戻った

この区別が最も効くのは、フェーズ 2 の議論をフェーズ 3 の設計に当てはめるときです。同じ言葉が両方の会話に現れますが、転送への影響は同じではありません。

レビュー時に変更が正しく見えたのも同じ理由です。レビューはルーティングテーブルを確認しましたが、それは関与する三つの状態のうち一つにすぎません。

一つの集約、二つのテーブル

二つの操作は次のとおりです。

ルート集約は、ハブが何を広告し、受け取るスポークが何をルートとしてインストールするかについての表明です。NHRP サマリーマップは、別のスポークがアドレスへの到達方法を問い合わせたときにスポークが返す応答についての表明です。これは失敗の仕方が異なる別の問いであり、設計は片方を変えてもう片方を以前とまったく同じに保つことができます。両者を一つのつまみとして扱うことが、集約の変更が静かに転送の変更へ変わる道筋です。

どちらの操作も、保護パスについての表明ではありません。保護パスは、実際に解決したピアに対してネゴシエートされるものです。

ハブの集約が実際に変えるもの

スポーク間 NHRP サマリーマップに関する Cisco のガイドは、ハブが集約を広告しつつルーティングの次ホップであり続けるフェーズ 3 の構成を説明しています。その後、リダイレクトと続く NHRP 解決によって、より直接的な転送経路が得られます。したがって集約ルートだけを読んでも転送状態の全体は分からず、すべてのパケットが永久にハブを通らなければならないわけでもありません。集約は到達性についてのもので、経路についてのものではありません。

だからこそ、ルーティングテーブルで止まる設計レビューは、解決の振る舞いを変える変更を承認してしまいます。選択されたルート、NHRP の結果、保護パスを三つの別々の観測として確認してください。

三つのうちどれが変わったのか言えないなら、その変更は終わっていません。

NHRP サマリーマップが変えるもの

複数のより具体的な LAN ルートで 10.32.0.0/19 を保有するスポークを考え、ハブは他のスポークへより大きな集約を広告しているとします。10.32.12.10 への要求は、そうでなければ一致する小さなネットワークの解決情報を受け取っていました。文書化されている NHRP サマリーマップ機能を使うと、スポークは代わりに設定済みのカバープレフィックスを返せます。これにより、そのスポークに属するネットワークの解決作業の繰り返しを減らせます。ただし、ハブのルート集約とスポークの解決集約が同じものになるわけではありません。

そのカバープレフィックスには意図した所有モデルを与えてください。別の場所に属するアドレスを含む広い応答や、到達できない隙間は、以降のトラフィックを不適切なピアへ送ってしまいます。

プレフィックスを広げる前に、実際のルートと想定した拒否ケースを確認してください。後からでは遅いのです。

最初の宛先と集約の内側の宛先を比較する

二つの宛先を選びます。最初に試したものと、提案した集約の内側にあるものです。それぞれについて、選択されたルート、到達に使われた NHRP 状態、実際の応答経路を記録してください。この比較で、ルーティングの規模、解決の規模、転送の誤りのどれを変えたのかが分かり、それが唯一役立つ結論です。プレフィックスが少ない表示は、そのどれの証拠にもなりません。

フェーズ 3 の例を自分のネットワークに当てはめる前に、導入済みのフェーズとルーティングプロトコルの次ホップ挙動を確認してください。短い例は、別の設計が同じ直接スポーク経路を保つ証拠にはなりません。

チケットには、どのテーブルを減らし、どれをそのままにしたかを書くべきです。それに満たないと、一か月後にゼロから再診断されることになります。