名前付きと番号付きのDMVPNハブ：FQDNが変えるもの

DMVPNのスポークは、この機能をサポートするプラットフォームではホスト名でハブを特定できます。最初に陥りやすいのは、そのホスト名をハブのトンネルアドレスの別の書き方と読んでしまうことです。そうではありません。名前はトランスポートのエンドポイントに解決され、ハブのプロトコルアドレスはオーバーレイ内部のネクストホップを識別します。この二つの役割は、どの構成形式でも変わりません。この区別が、名前の変更で直せることと直せないことを決めます。

二つのアドレス、二つの役割

宣言された例では、hub.example.net がスポークにトランスポートトラフィックの送信先を伝え、10.90.0.1 がトンネル内のNHSを識別します。検出は前者で働き、登録とルーティングは後者で働きます。名前の変更はエンドポイントへの経路に影響し、プロトコルアドレスの変更はオーバーレイの関係そのものに影響します。

役割を分けておくことが、名前付き形式をデバッグ可能にします。スポークが登録に失敗したとき、二つの別の問いを立てられます。名前は期待したアドレスに解決されたのか、そのアドレスは構成が主張するプロトコルアドレスと一致したのか。どちらの答えも、もう一方を含意しません。

二つの構成形式を比較する

一方の形式は、名前と並べてNHSプロトコルアドレスを明示的に構成します。もう一方は、登録応答からそのプロトコルアドレスをスポークに学習させます。どちらも文書化されており、成功すれば同じ種類のNHS関係に行き着きます。

明示的な形式には覚えておく価値のある制約があります。解決されたトランスポートアドレスが構成済みのプロトコルアドレスにマップされない場合、登録は妨げられます。これはDNSの障害ではありませんが、症状はDNS変更の直後に現れます。名前は正しく解決され、結果は別の理由で拒否されたのです。解決されたアドレスと構成済みのプロトコルアドレスを並べて読んでください。

学習形式は手作業の手順を一つとドリフトの源を一つ取り除く代わりに、マッピングの確立を応答に依存します。ハブアドレスが安定していて、不一致を大きな声で失敗させたいなら明示的な形式を選びます。ハブのプロトコルアドレスが変わりうるのでスポークに追随させたいなら学習形式を選びます。いずれの場合も、設計がどちらの形式を使うかを記録してください。

DNSキャッシュと静的ハブを比較する

静的ハブアドレスは、誰かが構成を編集したときに変わります。名前付きハブはDNSが変わるときに変わり、DNS応答はその有効期間にわたってキャッシュされます。文書には、キャッシュされた情報は期限が切れるまで利用可能であり、その後の問い合わせで新しいアドレスが返りうると記されています。

その違いはタイミングの違いであり、即時の移行ではありません。長いキャッシュ期間は名前を変えたエンドポイントの採用を遅らせ、DNSレコードだけを見ているとその遅延は見えません。すべてのトンネルが一斉に移ると仮定するのではなく、キャッシュ期間と導入済みリリースの登録動作を軸に名前変更を計画してください。

静的形式にももちろん独自の遅れがあります。すべてのスポークが編集されるまで何も変わりません。比較すべきは、調整された構成のプッシュとキャッシュされた検出の更新であり、遅いか即時かではありません。

変わらないものを比較する

ピア認証は動きません。トランスポートのエンドポイントを特定するホスト名は、構成済みのIKE IDやピアを検証する認証ポリシーを置き換えません。IDが誤っていれば、DNS解決が成功しても拒否されたトンネルに早く着くだけです。

保護されたトラフィックも変わりません。NHSが応答しても、顧客ルートが存在することやアプリケーションフローが許可されていることは証明されません。登録、ルーティング、ポリシーは三つの確認であり、名前はそれらを支える最初の段階にしか影響しません。

検証できる比較

CiscoはセッションとNHS関係について別々の観察を文書化しています。ピアとセッションの状態を読むには show dmvpn を、NHS登録ビューを読むには show ip nhrp nhs を使ってください。解決されたトランスポートアドレス、オーバーレイのピア、登録状態の順に比較します。

IOS XE FQDN-DMVPNの章は、この比較の背後にある検出、キャッシュ、制約の動作を文書化しています。名前を変えたハブを番号付きハブの直接の置き換えとみなす前に、導入済みリリースと照らして読んでください。