階層型DMVPN：トンネル関係ごとに一つのクラウド

支店スポークは地域ハブへの登録に成功しているのに、別の地域のサービスには到達できません。トンネルは稼働し、NHSの状態も正常に見え、障害は層の境界を越える宛先でのみ現れます。このパターンは通常、どの機器がどのDMVPNクラウドに参加するかを設計が明示していなかったことを意味し、層は直感で構築されたため、今では食い違っています。

症状は層の境界に現れる

階層設計では、中央ハブ、複数の地域ハブ、多数の支店スポークがそれぞれ位置を持ちます。地域ハブは複数のトンネル関係を持てますし、支店はすべての中央エンドポイントに登録する必要はありません。重要な経路は、支店から地域サービスへ、支店から承認済みの別の地域スポークへ、支店から中央の宛先へです。

他の経路が機能しているのに一つが失敗する場合、問題はほぼ常にトンネルの故障ではなく、役割定義の欠落または矛盾です。意図した経路を書き出し、機器が実際に構築した内容と比較してください。この比較は一時間で終わり、一週間の推測を防ぎます。設計文書と一緒に保管してください。

一つのクラウド、一つのインターフェース契約

クラウドごとに、トンネルインターフェース、オーバーレイのアドレス指定、ローカルのアンダーレイ送信元、NHSとNBMAの関係、マルチキャスト配信、保護ポリシーを記録し、地域と中央の文脈の間でどのルートが越えるかも明記してください。その一文こそが設計です。

トンネルインターフェースを二つ持つ地域ハブには、二つの住所を持つ一つの契約ではなく、二つの契約が必要です。アンダーレイ送信元、NHRPドメイン、ルートはインターフェースごとに異なり得るため、それらをまとめた文書は二つ目を設定する人を誤らせます。

識別子はローカルの文脈であり、アクセス制御ではない

NHRPネットワークIDとGREキーは、グローバル設定と最も誤解される二つの値です。IOS XEのNHRPガイドはネットワークIDをローカルに意味を持つものと説明しているため、遠隔ルーターで番号が一致しても何も認証されず、一台のルーターのローカル番号を変えてもアクセス境界は生まれません。

GREキーは、設計が使う場合、受信側トンネルの文脈を識別する助けとなり、その文脈を共有するエンドポイント間で合意されます。パスワードではなく、IKE認証やルーティングポリシーを置き換えるものでもありません。両方の値を、関係の中で一致すべき設定の文脈として扱い、地域を分けるセキュリティ制御として扱わないでください。

層の間を意図的にルーティングする

地域ハブが上方向に広告するプレフィックスと、支店に提供する中央の宛先を決めます。次に、集約ルートとショートカットが図の示唆より大きく異なる転送を生むことがあるため、各経路の実際のネクストホップとフェーズ固有のショートカット動作を確認してください。

地域の分離を強制するには、ルーティングとアクセスポリシーを使います。支店が別の地域に直接到達してはならない場合、それを語るのはルートとポリシーであるべきで、強制するために設計されたことのない識別子に頼るべきではありません。ポリシーは識別子の隣に書いてください。そうしなければ、次のエンジニアは番号が仕事をすると想定します。

予期しないショートカットを診断する

支店が中央エンドポイントとの直接関係を作ろうとするとき、識別子を無作為に変える前に、そのルート、NHRPマッピング、選択されたトンネル文脈を調べてください。到達不能、意図しないNHS関係、正当だが承認されていないショートカットは、三つの異なる修正を必要とします。

DMVPN設定ガイドはトンネルとNHRPの設定を並べて示しており、だからこそ範囲をまず紙の上で分ける必要があります。クラウドの契約を記録し、層のルートを明示的に保てば、次の境界障害には指し示す場所があります。