Cisco Live 2009に基づく：DMVPNの高度な概念

VPNに関する一連の記事を続けて、Cisco Live 2009で概説したDMVPNテクノロジーの実装に関する詳細を共有したいと思います。注意、多くの手紙:)



タスクを設定することで伝統に従って始めます 。



そのため、セントラルオフィスと複数のブランチがあり、それらをパブリックコミュニケーションチャネル（インターネット）を使用して共通のネットワークに統合したいと考えています。



説明されているGET VPNテクノロジーとは対照的に、インターネットチャネルを使用するためには、トンネリング（ヘッダーの置換）を使用する必要があります。



ダイナミックマルチポイントVPN（DMVPN）とは何ですか？ 要するに、これはIPSecとのマルチポイントGRE（ mGRE ） アソシエーションです。

mGREは、同じインターフェイス上の複数のネイバーとのトンネルを確立する機能を備えた従来のGREとは異なるトンネリングプロトコルです。 基礎は、そのような接続を動的に確立できるNext-Hop Resolution Protocol（ NHRP ）の使用です。 NHRPと対話するIPSecは、必要に応じてSAを確立し、各接続に個別に暗号化を提供します。



接続トポロジは従来のハブアンドスポークですが、DMVPNを使用すると、スポーク間トンネルを動的に確立できることが重要です。



つまり、NHRPの考え方は、すべてのスポークに対して静的に指定されたハブまたはNHS （ネクストホップサーバー）を指定することです。 各スポークは動的に登録されます（つまり、最初はNHSはスポークアドレスを認識しません）、NHSとの永続的なトンネルを確立し、NHSはそのトンネルアドレスと実際のアドレス（マッピング）をネイバーデータベースに対応させ、必要に応じて他にも通知しますハブを介さずに、直接相互に接続を確立できました。 スポークツースポークは、ハブツースポークとは異なり、永続的ではなく一時的な会話です。 ブランチ間のトラフィックがしばらくなくなると、ブランチ間のトンネルは削除されます。 これにより、スピーカーと同じ数の接続を保持する必要がないため、スポークルータとしてより弱いモデルを使用することが可能になります。 それどころか、ハブとして、すべてのスポークとの接続に耐えるのに十分な強度のルーターを選択する必要があります。



各ブランチは（登録を通じて）ハブの存在を動的に通知するため、ブランチルータを動的NATの背後に隠すことができます。 そして以来 ハブは各ブランチルータで静的に構成され、静的NATの背後にのみ配置できます。



次に、 フェーズDMVPNの概念を紹介します 。 この場合のフェーズは、スポークツースポークまたはスポークツーハブの相互作用のタイプ（またはキャラクター）として理解されます。 合計で3つのフェーズがあります。

フェーズ1 。 ハブツースポークトンネルのみが実装され、スポークツースポークトンネルはインストールされず、すべてのトラフィックはハブを通過します。 この場合、ルーティングプロトコルのネクストホップをNHCアドレスからNHSアドレスに置き換えるのが論理的です。

登録は次のとおりです。



つまり 最初に、IPSecトンネルが確立され、次にNHCがNHRP登録要求メッセージを送信します。

メッセージの間隔は、1/3「ip nhrp registration holdtime」または「ip nhrp registration timeout」です。 NHSが応答しない場合、間隔は1（1、2、4、8 ...、64、...）から始まる指数関数的に増加します。 同時に、3回目の試行後、NHSはダウンとしてマークされ、使用されません。 つまり、登録要求にはキープアライブ機能もあります。

各NHRP登録メッセージには、NHCトンネルアドレスとその実際のアドレス（NBMA）の対応が含まれます。また、認証、NATなどの拡張ヘッダーも含まれる場合があります。



このメッセージに対する答えは、当然、NHRP登録応答です。 NHCとNHSの実際のアドレスとトンネルアドレスの対応、およびすべての同じ拡張ヘッダーが含まれています。 実際、ハブの活力も確認します。

NHCを登録すると、NHRPテーブルの出力は次のようになります。

ハブで ：

HUB#sh ip nhrp

10.1.1.2/32 via 10.1.1.2, Tunnel0 created 15:17:10, expire 01:22:43

Type: dynamic, Flags: unique registered

NBMA address: 172.16.2.1

10.1.1.3/32 via 10.1.1.3, Tunnel0 created 15:17:10, expire 01:22:43

Type: dynamic, Flags: unique registered

NBMA address: 172.16.3.1





スポーク1で ：

SPOKE1#sh ip nhrp

10.1.1.1/32 via 10.1.1.1, Tunnel0 created 15:17:45, never expire

Type: static, Flags: used

NBMA address: 172.16.1.1







マッピングの出力に触れたので、これらのマッピングに対応する型とフラグについて説明しましょう。

種類

1. 静的 -インターフェイスがトンネルアドレスと実際のアドレスに明確に一致するレコード（ip nhrp map ...）
2. 動的 -NHRPによって取得されたレコード。 次の2つのタイプがあります。
3. 不完全 -トンネルアドレスがスポークしていることはわかっていますが、NHRP解決要求への応答をまだ受信していません。

旗

1. ユニーク つまり、このマッピングは一意であり、NBMAアドレスが変更された場合、このレコードは更新されません。
2. 登録済み -NHRP登録から取得、通常はハブ上。
3. 学んだ -NHRP登録から取得、反対に、通常話した。
4. 信頼できる 。 NHRP解決要求への応答に使用できます。
5. 使用済み 。 過去60秒間に記録が使用されました。
6. ルーター リモートルーターまたはその背後のネットワークのエントリには、このフラグが付いています。
7. 暗黙的 。 NHRPパケットのソース情報から取得したレコード。
8. ローカル NHRP要求への応答で他のスポークに提供したローカルネットワークに関する情報。 このスポークのNBMAアドレスも保存します。
9. NAT （IOSの12.4（6）Tバージョンで表示され、12.4（15）Tの後に表示されません。リモートピアがNATを介した作業をサポートすることを示します。12.4（15）Tの後、要求されたNBMAアドレスも単にレコードに表示されます。
10. ソケットなし 。 このトンネルを必要とするトラフィックがないため、ルーターがIPSecトンネルを必要としない、または確立したくないレコード。 そのようなトラフィックがその後表示される場合、エントリは「ソケット」に変換され、IPsecトンネルが発生します。 Localやimplicitなどのエントリは、常に最初に「ソケットなし」とマークされます。 さらに、NHRPは、デフォルトでは、NHRP解決要求または応答がルーターを通過するときに、それらからのソース情報をキャッシュします。 このキャッシュを許可するが、IPSecトンネルを上げることはできないため、（ソケットなし）とマークされます。 これを行わないと、ハブからスポークへの不要なIPSecソケットが形成され、使用されません。 トンネルインターフェイスに到達し、そこから出るデータは（ソケットなし）レコードを使用できません。この場合、ルーターは通信する2つの間のパス上の中間ノードであり、中間ポイントを持つ別のトンネルを作成する可能性は低いためです。 ある時点でルーターがトンネルインターフェイスから来ていないデータパケットを受信し、（nmoソケット）レコードを使用する必要がある場合、ルーターはこれを（ソケット）レコードに変換します。この場合、ルーターがこのトンネルへの出口ポイントになるためです。データストリーム。 また、NHRP登録から取得されたレコードのみが（信頼できる）としてマークされるため、これらの（ソケットなし）エントリは（信頼できない）としてマークされます。
11. 負 要求されたマッピングがまだ受信されていないことを意味します。 NHRPがNHRP解決要求を送信すると、この（負の）フラグを不完全なタイプのレコードに設定します。これにより、ルーターは、応答を見込んだり、IPSec接続を確立したりするときにこれらの要求を複数回送信することを防ぎます。

登録後、ルーティング情報の交換が行われ、ハブはそれ自体を各ルートのネクストホップとして設定します。 その後、NHCはハブを介してデータを交換できます。



このテクノロジーの利点の 1つは、各NHCに1つのトンネルしか存在しないことです。これにより、リソースが節約されます。

欠点は明らかです。ハブを介してルーティングすると、ハブがロードされるだけでなく、大幅な伝送遅延が発生します。



フェーズ2 。 ここでは、CEFトリックを使用するスポーク間トンネルを既に構築できます。 すべてのブランチは、同じネクストホップで完全なルーティング情報を受け取ります（これを行う方法については後で説明します）。



NHSからそのようなルートを受信したNHCは、そのルートに「無効」とマークされた対応するCEFレコードを配置し、次ホップアドレス（つまり、別のNHCのアドレス）に、収集タイプレコード（つまり、L3アドレスがアドレスL2に解決済み）。 この許可は、最初のパケットがこのルートで送信されるときにNHRPによって付与されます。



そのようなエントリの例：



SPOKE1#sh ip cef 192.168.2.0

192.168.2.0/24, version 27, epoch 0

0 packets, 0 bytes

via 10.1.1.3, Tunnel0, 0 dependencies

next hop 10.1.1.3, Tunnel0

invalid adjacency

SPOKE1#sh ip cef 10.1.1.3

10.1.1.0/24, version 20, epoch 0, attached, connected

0 packets, 0 bytes

via Tunnel0, 0 dependencies

valid glean adjacency







NHRPレベルでは、第2フェーズに対応する3種類のレコードもあります。

1. エントリーなし。 すべてが透過的であり、トラフィックはNHSに送信され、その後NHRP解決要求が送信されます。
2. タイプレコード（ソケットなし）。 送信する相手はわかっているようですが、IPSec接続は確立されていません。 トラフィックはまだNHSに飛んで、別のNHCに接続します
3. タイプレコード（ソケット）。 トラフィックは、IPSecトンネルを介して別のNHCに送られます。

最初のパケットは、プロセススイッチングを使用してNHS経由で送信されます。 NHCはNHS NHRP解決要求を送信します。NHSは、CEFエントリを補充できるアドレスでNHSに応答します。



機能 iOS 12.4.5aより前では、要求と応答はNHSチェーン全体を通過していました。 （6500および7600ではなく）NHRP解決要求への応答機能が、興味のあるNHC自体に転送されました。 新しいフェーズの実装の相互作用スキームを図に示します。





フェーズ2のデバッグnhrpパケットコマンドの出力例

SPOKE1#ping 192.168.2.1



Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 8/41/72 ms

SPOKE1#

*Mar 1 00:30:01.367: NHRP: Send Resolution Request via Tunnel0 vrf 0, packet size: 81

*Mar 1 00:30:01.367: src: 10.1.1.2, dst: 10.1.1.3

*Mar 1 00:30:01.371: (F) afn: IPv4(1), type: IP(800), hop: 255, ver: 1

*Mar 1 00:30:01.371: shtl: 4(NSAP), sstl: 0(NSAP)

*Mar 1 00:30:01.371: (M) flags: "router auth src-stable", reqid: 4

*Mar 1 00:30:01.371: src NBMA: 172.16.2.1

*Mar 1 00:30:01.371: src protocol: 10.1.1.2, dst protocol: 10.1.1.3

*Mar 1 00:30:01.375: (C-1) code: no error(0)

*Mar 1 00:30:01.375: prefix: 0, mtu: 1514, hd_time: 7200

*Mar 1 00:30:01.375: addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 0

*Mar 1 00:30:01.375: NHRP: Send Resolution Request via Tunnel0 vrf 0, packet size: 81

*Mar 1 00:30:01.379: src: 10.1.1.2, dst: 10.1.1.1

*Mar 1 00:30:01.379: (F) afn: IPv4(1), type: IP(800), hop: 255, ver: 1

*Mar 1 00:30:01.379: shtl: 4(NSAP), sstl: 0(NSAP)

*Mar 1 00:30:01.383: (M) flags: "router auth src-stable", reqid: 4

*Mar 1 00:30:01.383: src NBMA: 172.16.2.1

*Mar 1 00:30:01.383: src protocol: 10.1.1.2, dst protocol: 10.1.1.3

*Mar 1 00:30:01.383: (C-1) code: no error(0)

*Mar 1 00:30:01.387: prefix: 0, mtu: 1514, hd_time: 7200

*Mar 1 00:30:01.387: addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 0

*Mar 1 00:30:01.415: NHRP: Receive Resolution Reply via Tunnel0 vrf 0, packet size: 109

*Mar 1 00:30:01.415: (F) afn: IPv4(1), type: IP(800), hop: 255, ver: 1

*Mar 1 00:30:01.415: shtl: 4(NSAP), sstl: 0(NSAP)

*Mar 1 00:30:01.415: (M) flags: "router auth dst-stable unique src-stable", reqid: 4

*Mar 1 00:30:01.419: src NBMA: 172.16.2.1

*Mar 1 00:30:01.419: src protocol: 10.1.1.2, dst protocol: 10.1.1.3

*Mar 1 00:30:01.419: (C-1) code: no error(0)

*Mar 1 00:30:01.423: prefix: 32, mtu: 1514, hd_time: 6089

*Mar 1 00:30:01.423: addr_len: 4(NSAP), subaddr_len: 0(NSAP), proto_len: 4, pref: 0

*Mar 1 00:30:01.423: client NBMA: 172.16.3.1

*Mar 1 00:30:01.423: client protocol: 10.1.1.3







src NBMAフィールドの存在により、NHC宛先はハブをバイパスして応答できます。

備考

• 一見ネクストホップアドレスを保存することは、論理的で正しい解決策のように思えます。 ただし、欠点が1つあります。各NHCは、合計を使用せずに、NHSからルーティングテーブル全体を受信する必要があります。 これにより、1レベルのNHSのみを使用できます。 NHCの半分を1つのNHSで処理し、残りの半分をもう1つのNHSで処理できますが、それらを互いにNHSとして接続する必要があります。 これは、NHRP解決要求がすべての潜在的なNHSを通過できるようにするために必要です。 また、静的表示により、全体的な信頼性が低下します。
• また、最初のパケットはCEF経由ではなく、プロセススイッチング経由で送信されます。

フェーズ3 。

このフェーズでは、NHCがNHRP解決要求への応答に参加できるようにし、この「利点」をNHSから取得します。



手順を検討してください。

1. NHCは伝統的にNHSに登録されており、NHSはルーティングプロトコルに従ってNHCと近隣を確立し、ルーティング情報を交換できます。 同時に、NHSは元の形式でルーティング情報を保存する義務がありません。それは、ネクストホップを自身と交換し、同時に要約することもできます。 さらに、NHCに返送するルートがより一般的であるほど、簡単になります:)
2. NHCはルーティング情報を受信し、CEFテーブルに入力します。 ネクストホップからNHS自体ができたので、「無効な」または「無駄のない」エントリはありません。 言い換えれば、このルートの最初のパケットはCEFを使用して送信されます...ここで... ...正しく、ハブに！ しかし、これは、とりわけ、CEFに「誤った」エントリがなくてもNHRP解決要求がトリガーされないことを意味します！ そして、ここでNHRPリダイレクトメッセージがアリーナに入ります ！
3. ステップ3は、2番目のステップの直接の継続です。 そのため、スポークから別のスポークに送信される最初のパケットはNHSを通過します。 NHSがmGREトンネルを介してパケットを受信し、同じインターフェイスを介して（ただし、別のNHCに）強制的に送り返すと、NHSはそのようなパケットのソースに第3フェーズの主要な「トリック」、NHRPリダイレクトメッセージを送信します。 このメッセージは、パケットルーティングで「正しくない」:)パスを使用していることをNHCに伝えます。 そして、彼は、NHRPの解決策を使用してNHCのパスを明確にするとよいと「示唆」しています。 それにもかかわらず、最初のパケット自体はNHSに送信されます。
4. また続けます。 これで、最初のパケットを送信したNHCは、その最初のパケットの宛先アドレスを含むリダイレクトメッセージを受信します。 このNHCは、同じIPに対してNHRP解決要求を送信しますが、（注意!!!）NHSには送信せず、同じアドレスに送信します 。 つまり NHCは別のNHCに実際の住所を尋ねます。 繰り返しますが、NHRP解決要求の宛先アドレスはNHSではなく、（最初のパケットのように）NHSを介して到達しますが、関心のあるNHCです。 NHSは、意図したとおりに送信します（つまり、パケットはハブを通過しますが、最適ではありません）。
5. デカップリング:)これで、宛先NHC（NHSではなく!!）が解決要求に応答しています。 要求に添付された実際のアドレスを使用して、このNHCはNHSをバイパスして送信者に直接応答します。 この場合、応答には、要求されたアドレスだけでなく、RIBで見つかったネットワーク全体（ルート、プレフィックス）が含まれます。 NHCリクエスト送信者がそのような応答を受信すると、そのアドレスの実際のネクストホップを見つけ、NHRPテーブルに入力し、CEFのエントリを修正します（または新しいエントリを作成します）。

借方記入出力の例：

SPOKE2#ping 192.168.1.1



Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 32/51/84 ms

SPOKE2#

*Mar 1 00:07:57.151: NHRP: Receive Traffic Indication via Tunnel0 vrf 0, packet size: 97

*Mar 1 00:07:57.155: (F) afn: IPv4(1), type: IP(800), hop: 255, ver: 1

*Mar 1 00:07:57.155: shtl: 4(NSAP), sstl: 0(NSAP)

*Mar 1 00:07:57.159: (M) traffic code: redirect(0)

*Mar 1 00:07:57.159: src NBMA: 172.16.1.1

*Mar 1 00:07:57.159: src protocol: 10.1.1.1, dst protocol: 10.1.1.3

*Mar 1 00:07:57.163: Contents of nhrp traffic indication packet:

*Mar 1 00:07:57.167: 45 00 00 64 00 00 00 00 FE 01 EF EB 0A 01 01 03

*Mar 1 00:07:57.171: C0 A8 01 01 08 00 36 7F 00 00 00

*Mar 1 00:07:57.211: NHRP: Send Resolution Request via Tunnel0 vrf 0, packet size: 85

*Mar 1 00:07:57.215: src: 10.1.1.3, dst: 192.168.1.1

*Mar 1 00:07:57.219: (F) afn: IPv4(1), type: IP(800), hop: 255, ver: 1

*Mar 1 00:07:57.219: shtl: 4(NSAP), sstl: 0(NSAP)

*Mar 1 00:07:57.219: (M) flags: "router auth src-stable nat ", reqid: 5

*Mar 1 00:07:57.219: src NBMA: 172.16.3.1

*Mar 1 00:07:57.219: src protocol: 10.1.1.3, dst protocol: 192.168.1.1

*Mar 1 00:07:57.219: (C-1) code: no error(0)

*Mar 1 00:07:57.219: prefix: 0, mtu: 1514, hd_time: 7200

*Mar 1 00:07:57.219: addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 0

*Mar 1 00:07:57.247: NHRP: Receive Resolution Request via Tunnel0 vrf 0, packet size: 105

*Mar 1 00:07:57.251: (F) afn: IPv4(1), type: IP(800), hop: 254, ver: 1

*Mar 1 00:07:57.251: shtl: 4(NSAP), sstl: 0(NSAP)

*Mar 1 00:07:57.255: (M) flags: "router auth src-stable nat ", reqid: 6

*Mar 1 00:07:57.255: src NBMA: 172.16.2.1

*Mar 1 00:07:57.259: src protocol: 10.1.1.2, dst protocol: 10.1.1.3

*Mar 1 00:07:57.263: (C-1) code: no error(0)

*Mar 1 00:07:57.263: prefix: 0, mtu: 1514, hd_time: 7200

*Mar 1 00:07:57.263: addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 0

*Mar 1 00:07:57.271: NHRP: Send Resolution Reply via Tunnel0 vrf 0, packet size: 133

*Mar 1 00:07:57.275: src: 10.1.1.3, dst: 10.1.1.2

*Mar 1 00:07:57.279: (F) afn: IPv4(1), type: IP(800), hop: 255, ver: 1

*Mar 1 00:07:57.279: shtl: 4(NSAP), sstl: 0(NSAP)

*Mar 1 00:07:57.283: (M) flags: "router auth dst-stable unique src-stable nat ", reqid: 6

*Mar 1 00:07:57.283: src NBMA: 172.16.2.1

*Mar 1 00:07:57.287: src protocol: 10.1.1.2, dst protocol: 10.1.1.3

*Mar 1 00:07:57.291: (C-1) code: no error(0)

*Mar 1 00:07:57.291: prefix: 32, mtu: 1514, hd_time: 7200

*Mar 1 00:07:57.295: addr_len: 4(NSAP), subaddr_len: 0(NSAP), proto_len: 4, pref: 0

*Mar 1 00:07:57.299: client NBMA: 172.16.3.1

*Mar 1 00:07:57.299: client protocol: 10.1.1.3

*Mar 1 00:07:57.323: NHRP: Receive Resolution Reply via Tunnel0 vrf 0, packet size: 153

*Mar 1 00:07:57.331: (F) afn: IPv4(1), type: IP(800), hop: 254, ver: 1

*Mar 1 00:07:57.331: shtl: 4(NSAP), sstl: 0(NSAP)

*Mar 1 00:07:57.331: (M) flags: "router auth dst-stable unique src-stable nat ", reqid: 5

*Mar 1 00:07:57.335: src NBMA: 172.16.3.1

*Mar 1 00:07:57.339: src protocol: 10.1.1.3, dst protocol: 192.168.1.1

*Mar 1 00:07:57.343: (C-1) code: no error(0)

*Mar 1 00:07:57.343: prefix: 24, mtu: 1514, hd_time: 7200

*Mar 1 00:07:57.343: addr_len: 4(NSAP), subaddr_len: 0(NSAP), proto_len: 4, pref: 0

*Mar 1 00:07:57.347: client NBMA: 172.16.2.1

*Mar 1 00:07:57.347: client protocol: 10.1.1.2







NHRPリダイレクトの受信を強調した下線付き。



3番目のフェーズを要約するには ：

1. CEFに無効なエントリはありません。 すべてのパケットはCEFを使用し、NHRP要求はCEFの無効なエントリではなく、NHSからの明示的な指示によって呼び出されるようになりました。
2. NHSがNHRP情報の唯一のソースではなくなりました。 残りのNHCも関与していました。 peer2peerに似ています。
3. NHC NHRP応答には、ネクストホップだけでなくプレフィックス全体が含まれます。 ところで、これにより、NHSからNHCへの一般的なルートを送信できます。 宛先のNHCは、それに属するプレフィックスを返します。これは、NHSから最初に受信したプレフィックスよりもプライベートな場合があります。
4. 初期パケットはハブを通過します。
5. 答えはNHSではなくNHCであるため、トポロジには複数のレベルのハブが存在する可能性があります。

次に、フェーズの知識を備えたルーティングを少し要約します 。



仮定1 。 NHCは、NHSとのみルーティングプロトコルネイバーフッドを確立し、NHCとは決して確立しません。 NHCは、ローカルNHSネットワークを発表します。

仮定2 。 NHSはすべてのNHCと近隣を確立します。 同時に、彼は他のNHCと彼のローカルネットワークから学習したすべてのネットワークについてNHCに通知します。

さらに、フェーズに関係なく、RIPとEIGRPのスプリットホライズンをオフにする必要があります。

ただし、フェーズによって機能に違いがあります。

1. フェーズ1およびフェーズ3では、ハブはルーティング情報にネクストホップ（たとえば、BGPネクストホップセルフ、OSPFネットワークポイントツーマルチポイント）を格納できません。これにより、要約を適用できます。 さらに、ハブの数は制限されておらず、同じレベルである必要はありません。
2. 反対に、フェーズ2では、ハブはルーティング情報（EIGRP no ip next-hop-self 、BGPデフォルト、OSPFネットワークブロードキャスト）にネクストホップを保存する必要があります。使用できるハブは2つまでです。

仮定3 。 NHSは、他のNHSとのルーティングプロトコルネイバーフッドを確立します。 同時に

1. フェーズ1およびフェーズ3では、ハブ間のルーティングプロトコルは、ハブとNHC間のルーティングプロトコルと異なる場合があります。
2. フェーズ2では、同じプロトコルを使用するためにハブが必要です。

-DMVPNの動作の理論的基礎を検証したので、CiscoルータでDMVPNを設定する方法を確認します。

設定は、目的のフェーズとルーターの役割（ハブまたはスポーク）によって異なります。



順番に：



ハブは 、フェーズ1とフェーズ2のNHRPで同じように構成されます。違いは、ルーティングプロトコルの構成です。



トンネルインターフェイスを作成し、アドレスを割り当てます。

Hub(config)# interface Tunnel0

Hub(config-if)# ip address 10.1.1.1 255.255.255.0







ソースインターフェイスとモードの定義-GREマルチポイント

Hub(config-if)# tunnel source FastEthernet0/0

Hub(config-if)# tunnel mode gre multipoint







次に、NHRPプロトコル設定を実際に設定します。

ネットワークID：

Hub(config-if)# ip nhrp network-id 123







オプションの認証：

Hub(config-if)# ip nhrp authentication cisco







マルチキャストメーリングの動的に認識されるアドレスへのマッピングを構成します

Hub(config-if)# ip nhrp map multicast dynamic







フェーズ3。フェーズ2が存在する場合のみ異なる

Hub(config-if)# ip nhrp redirect







スポーク



フェーズ1。

トンネルインターフェイスを作成し、アドレスを割り当てます。

Spoke1(config)# interface Tunnel0

Spoke1(config-if)# ip address 10.1.1.2 255.255.255.0







ソースインターフェイスを定義する

Spoke1(config-if)# tunnel source FastEthernet0/0







ハブとのみ通信する予定であるため、宛先アドレスとトンネルのタイプを明示的に設定できます-通常のGRE IP（デフォルト）

Spoke1(config-if)# tunnel destination 172.16.1.1







なぜなら それでもNHRPを使用して登録する必要がある場合は、ネットワーク識別子を設定します。

Spoke1(config-if)# ip nhrp network-id 123







オプションの認証：

Spoke1(config-if)# ip nhrp authentication cisco







そして、マルチキャストメーリングのハブアドレスへのマッピングを構成します（注意、トンネルではなく実際）

Spoke1(config-if)# ip nhrp map multicast 172.16.1.1







NHSトンネルアドレスを指定します。

Spoke1(config-if)# ip nhrp nhs 10.1.1.1







そして、このトンネルアドレスのマッピングを実際のアドレスに作成します。

Spoke1(config-if)# ip nhrp map 10.1.1.1 172.16.1.1







フェーズ2。

ほぼ同じことです。トンネルモードを設定するだけで、トンネルの宛先を指定しないでください。

Spoke1(config)# interface Tunnel0

Spoke1(config-if)# ip address 10.1.1.2 255.255.255.0

Spoke1(config-if)# tunnel source FastEthernet0/0

Spoke1(config-if)# tunnel mode gre multipoint

Spoke1(config-if)# ip nhrp network-id 123

Spoke1(config-if)# ip nhrp authentication cisco

Spoke1(config-if)# ip nhrp map multicast 172.16.1.1

Spoke1(config-if)# ip nhrp nhs 10.1.1.1

Spoke1(config-if)# ip nhrp map 10.1.1.1 172.16.1.1







フェーズ3。フェーズ2が存在する場合のみ異なる

Spoke1(config-if)# ip nhrp shortcut

Spoke1(config-if)# ip nhrp redirect







そこで、mGREをセットアップしました。 IPSecを接続するために残ります。 設定はすべてのルーターで同じです。



ISAKMPポリシーを作成する

Router(config)#crypto isakmp policy 10

Router(config-isakmp)# encr aes

Router(config-isakmp)# authentication pre-share

Router(config-isakmp)# group 2







説明を簡単にするために、共有キー認証を使用します

Router(config-isakmp)#crypto isakmp key cisco address 0.0.0.0 0.0.0.0







キープアライブをオンにする

Router(config)#crypto isakmp keepalive 10 3 periodic







トランスフォームセットを作成し、 IPSecプロファイルにバインドします 。

Router(config)#crypto ipsec transform-set IPSEC_SET esp-aes esp-sha-hmac

Router(cfg-crypto-trans)#crypto ipsec profile IPSEC_PROFILE

Router(ipsec-profile)# set transform-set IPSEC_SET







プロファイルをトンネルインターフェイスにしがみつきます

Router(config)#interface tunnel 0

Router(config-if)#tunnel protection ipsec profile IPSEC_PROFILE







次に、 ルーティングプロトコルの設定について説明します 。 簡単にするために、2つの最も一般的なIGPであるOSPFとEIGRPに制限します。さらに、それらの1つはリンク状態、もう1つの距離ベクトルです。



したがって、すでにわかっているように、 フェーズ1および3では、 ハブがルーティング情報のネクストホップをそのアドレスに変更する必要があるため、

OSPF： Hub(config-if)# ip ospf network point-to-multipoint





EIGRPの場合、次ホップはデフォルトで変更され、追加の作業は必要ありません。

さらに、EIGRPおよびRIPの場合、スプリットホライズンを無効にする必要がありますHub(config-if)#no ip split-horizon eigrp AS_NUMBER







スポークでは、すべてが単純です。OSPFネットワークのタイプを設定し、スポークをDRまたはBDRにすることを強制的に禁止します。

OSPF： Spoke(config-if)# ip ospf network point-to-multipoint

Spoke(config-if)# ip ospf priority 0



Spoke(config-if)# ip ospf network point-to-multipoint

Spoke(config-if)# ip ospf priority 0







フェーズ2では、少し異なります。



ハブでは、ネクストホップを変更する必要はなくなりましたが、スプリットホライズンは依然として気になります。 だから

OSPF： Hub(config-if)# ip ospf network broadcast



（timers to taste）

EIGRP： Hub(config-if)#no ip next-hop-self eigrp AS_NUMBER

Hub(config-if)#no ip split-horizon eigrp AS_NUMBER



Hub(config-if)#no ip next-hop-self eigrp AS_NUMBER

Hub(config-if)#no ip split-horizon eigrp AS_NUMBER







スポークでは 、OSPFネットワークタイプもブロードキャストとして設定します。ハブに近接するだけでよいため、スポークをDRまたはBDRにすることは禁止されています。

OSPF： Spoke(config-if)# ip ospf network broadcast

Spoke(config-if)# ip ospf priority 0



Spoke(config-if)# ip ospf network broadcast

Spoke(config-if)# ip ospf priority 0







技術を要約します。

• DMVPNは、多くの参加者とVPNを構築できるテクノロジーです。 メイントポロジはハブアンドスポークですが、動的なスポークツースポークトンネル、さらにはハブの階層さえも可能です。
• これはmGREに基づいており（NHRPに基づいています）、保護はIPSecと密接に関係しており、IPSecはそれと密接に対話します。
• 一般に、ハブの負荷はスポークよりも大きくなります。 これにより、特定のブランチのニーズに応じて、パフォーマンスが異なる機器を使用できます。
• 作業の性質は、構成されたフェーズによって異なります。
• ルーティングプロトコルの構成にも注意が必要です。
• 欠点の中で、マルチキャストのサポートが制限されていることと、Cisco ASA（sob ...）のサポートが不足していることに注意してください。

シムのために私は私の休暇を取ることができます:)もちろん、再び、私は技術のすべての側面を明らかにしたことを望んでいません。 少なくとも舞台裏では、多くのハブなどの構成がありました。 しかし、私は技術の一般的なアイデアを提示できたことを願っています。



私はあらゆる方法で建設的な批判を望みます。 記事は大規模であり、ほとんどの場合、不正確、エラー、タイプミスでいっぱいです。



Podkopaev Ilya、インストラクター



UPD。 見つかったエラーのクイックシューターに感謝します:)