DMVPNフェーズ3マルチサブネット設計の実装

概要

このドキュメントでは、直接スポーク間トンネルが正しく構築されるように、DMVPNフェーズ3マルチサブネット設計のルーティングに関する考慮事項について説明します。 

前提条件

要件

次の項目に関する知識があることが推奨されます。

• ダイナミックマルチポイントVPN(DMVPN)に関する基本的な知識
• ネクストホップ解決プロトコル(NHRP)に関する基本的な知識

使用するコンポーネント

このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

背景説明

DMVPNフェーズ2とフェーズ3の両方の実装により、スポークデバイスはスポーク間の直接トンネルを構築でき、ハブを経由する必要はありません。ただし、DMVPNフェーズ3では、スポークがNHRPを介してリモートネットワークを動的に検出し、その後NHRP(H)ルートをルーティングテーブルにインストールするNHRPリダイレクトメカニズムによって、スケーラビリティが大幅に向上しています。これにより、各スポークのルーティングテーブルにリモートネットワーク用の特定のネットワークプレフィックスを含める必要があるというphase2の制限が排除されます。フェーズ3では、ターゲットスポーク（NBMA出口ポイント）からのNHRP解決応答は、直接スポーク間トンネルを通過する必要があります。ただし、スポークツースポークトンネルを正しく構築できるように、マルチサブネットのphase3設計には特別な考慮が必要です。この記事では、これらの要件について詳しく説明します。

問題

DMVPNフェーズ3は、シングルサブネットオーバーレイまたはマルチサブネットオーバーレイのいずれかに実装できます。単一サブネットオーバーレイトポロジでは、ハブとすべてのスポークルータのトンネルアドレスは、単一の論理IPサブネットから割り当てられます。マルチサブネット設計では、スポーク間トンネルは、異なるIPサブネットにあるトンネルのアドレスを持つスポーク用に構築される必要があります。後者は、次の図に示す階層型DMVPN設計で使用される一般的なシナリオです。

DMVPNフェーズ3マルチサブネットトポロジ

問題の詳細

DMVPNフェーズ3では、NHRP解決要求を受信すると、ターゲットスポークが送信元スポークへのIPsecトンネルを開始し、続いてそのトンネルを介して解決応答を送信することが一般的に理解されています。ただし、これは単一のサブネットオーバーレイの場合のみです。スポークのトンネルインターフェイスが異なるIP論理サブネットにある場合、NHRP制御パケットは、スポーク間の直接トンネルではなく、スポーク – ハブ – スポークのパスを通過できます。Spoke1がHub1からNHRPリダイレクトを受信した後にSpoke2に解決要求を送信するときのイベントのシーケンスを次に示します。

1. Spoke2が解決要求を受信する
   
   

   *Feb  7 20:57:22.272: NHRP: Receive Resolution Request via Tunnel0 vrf global(0x0), packet size: 144
   *Feb  7 20:57:22.272:  (F) afn: AF_IP(1), type: IP(800), hop: 252, ver: 1
   *Feb  7 20:57:22.272:      shtl: 4(NSAP), sstl: 0(NSAP)
   *Feb  7 20:57:22.272:      pktsz: 144 extoff: 52
   *Feb  7 20:57:22.272:  (M) flags: "router auth src-stable nat ", reqid: 5 
   *Feb  7 20:57:22.272:      src NBMA: 172.16.1.1
   *Feb  7 20:57:22.272:      src protocol: 10.0.1.101, dst protocol: 192.168.101.1
   *Feb  7 20:57:22.272:  (C-1) code: no error(0)
   *Feb  7 20:57:22.272:        prefix: 32, mtu: 17912, hd_time: 900
   *Feb  7 20:57:22.272:        addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 255
   

2. Spoke2は、Resolution Requestパケットをスヌーピングすることによって、10.0.1.101の暗黙のNHRPキャッシュエントリを追加します。
3. Spoke2は、Spoke1のNBMAアドレスを持つTunnel0の10.0.1.101の隣接関係を追加します。
4. Spoke2は解決応答で応答します。この時点で、要求側のスポークトンネルアドレスのルートがHub2を指していることに注意してください。
   
   

   Spoke2#show ip route 10.0.1.101
   Routing entry for 10.0.1.0/24
     Known via "eigrp 1", distance 90, metric 3609600, type internal
     Redistributing via eigrp 1
     Last update from 10.0.2.1 on Tunnel0, 00:17:44 ago
     Routing Descriptor Blocks:
     * 10.0.2.1, from 10.0.2.1, 00:17:44 ago, via Tunnel0
         Route metric is 3609600, traffic share count is 1
         Total delay is 41000 microseconds, minimum bandwidth is 1000 Kbit
         Reliability 255/255, minimum MTU 1400 bytes
         Loading 1/255, Hops 3
   Spoke2#
   Spoke2#
   Spoke2#show ip cef 10.0.1.101
   10.0.1.0/24
     nexthop 10.0.2.1 Tunnel0
   

   NHRP制御パケットはルーテッドパスに沿って転送されるため、新しく作成されたスポーク間トンネルではなく、Spoke1に対してHub2に送信されます。
   
   

   *Feb  7 20:57:22.360: NHRP: Send Resolution Reply via Tunnel0 vrf global(0x0), packet size: 172
   *Feb  7 20:57:22.360:  src: 10.0.2.101, dst: 10.0.1.101
   *Feb  7 20:57:22.360:  (F) afn: AF_IP(1), type: IP(800), hop: 255, ver: 1
   *Feb  7 20:57:22.360:      shtl: 4(NSAP), sstl: 0(NSAP)
   *Feb  7 20:57:22.360:      pktsz: 172 extoff: 60
   *Feb  7 20:57:22.360:  (M) flags: "router auth dst-stable unique src-stable nat ", reqid: 5 
   *Feb  7 20:57:22.360:      src NBMA: 172.16.1.1
   *Feb  7 20:57:22.360:      src protocol: 10.0.1.101, dst protocol: 192.168.101.1
   *Feb  7 20:57:22.360:  (C-1) code: no error(0)
   *Feb  7 20:57:22.360:        prefix: 24, mtu: 17912, hd_time: 900
   *Feb  7 20:57:22.360:        addr_len: 4(NSAP), subaddr_len: 0(NSAP), proto_len: 4, pref: 255
   *Feb  7 20:57:22.360:        client NBMA: 172.16.2.1
   *Feb  7 20:57:22.360:        client protocol: 10.0.2.101
   *Feb  7 20:57:22.360: NHRP: Encapsulation succeeded.  Sending NHRP Control Packet  NBMA Address: 172.17.0.5

理論的には、すべての中間ハブがNHRP制御パケットをSpoke1のトンネルに戻すことができる限り、すべてが動作する必要があります。しかし、必ずしもそうとは限りません。解決応答をSpoke1に戻すことができない場合は、直接スポーク間トンネルを構築できません。 

単一のサブネットオーバーレイでは、各スポークにトンネルネットワークへの直接接続ルートがあるため、これは問題になりません。その結果、解決応答が返信される前に、要求元のスポークトンネルアドレスの隣接関係ルックアップが行われます。マルチサブネットオーバーレイネットワークでは、スポークのトンネルアドレスが同じIPサブネット上にないので、直接スポーク間トンネル経由でのResolution Reply(RFP)パケットの送信は保証されません。

解決方法

マルチサブネットDMVPNフェーズ3設計の場合、スポークにルーティングエントリを設定し、スポーク間の直接トンネルを構築する必要があるリモートスポークトンネルサブネットのトンネルインターフェイスを指定することをお勧めします。以下に、いくつかの例を示します。

Spoke2#show run | in ip route
ip route 10.0.101.0 255.255.255.0 Tunnel0

これにより、スポークは要求側のスポークトンネルアドレスの隣接関係の解決を試行し、その後、スポークからスポークトンネルに解決応答を送信できます。 

または、解決応答はスポークハブスポークトンネルを通過できます。このような場合、NHRP制御パケットがエンドツーエンドで確実に配信されるように、すべての中間ハブに要求側のスポークトンネルサブネットへのルートが必要です。

注：バグの機能拡張が行われ、明示的なスタティックルートがなくても直接トンネル経由で解決応答を送信するオプションが検討されました。Cisco Bug ID CSCvo02022：拡張：マルチサブネットDMVPNでは、NHRPがスポーク間トンネル経由で解決応答を送信する必要があります。

注：シスコの内部バグ情報およびツールにアクセスできるのは、登録されているシスコのクライアントだけです。

関連情報

• シスコテクニカルサポートおよびダウンロード