DMVPNの仕組みとPhase 1・2・3

DMVPN は、mGRE と NHRP を使って Hub と Spoke のオーバーレイを作り、必要になった Spoke 間の直接経路を動的に形成する Cisco の VPN 技術である。

DMVPN（Dynamic Multipoint VPN）は、mGRE、NHRP、動的ルーティングを組み合わせる。通常は mGRE パケットを IPsec で保護するが、NHRP による対応付けや経路の選択自体は IPsec の機能ではない。

IPsec、IKE、SA、Cisco IOS の Proposal / Profile / Transform Set は、IPsecを理解するを参照する。

全体像

underlay と overlay は、あるネットワークを支える側と、その上に作られる側を区別する相対的な用語である。

underlay：外側の IP packet を実際に転送する土台のネットワーク
overlay：underlay 上に Tunnel を使って作る論理ネットワーク

DMVPN では、WAN 側の IP ネットワークが underlay、mGRE Tunnel が overlay になる。EIGRP や OSPF は overlay の Tunnel アドレスを使い、mGRE packet は underlay の IP アドレスを使って peer 間を移動する。

UnderlayとNBMAアドレス

underlay は、Hub と Spoke の WAN 側インターフェース間に IP 到達性を提供する。Internet、MPLS、閉域 IP 網などを underlay として利用できる。各ルータが同じ subnet に所属する必要はなく、routing により相互到達できればよい。

この構成では、Hub を 203.0.113.2/30、Spoke1 を 198.51.100.2/30、Spoke2 を 192.0.2.2/30 とし、3 台を別々の WAN access subnet に置く。それぞれの .1 を underlay 側の next hop とし、underlay 内の IP routing により NBMA アドレス間を到達可能にする。

NBMA は Non-Broadcast Multi-Access の略である。

Multi-Access：1 個の mGRE Tunnel インターフェースから複数の peer へ送信できる。
Non-Broadcast：mGRE だけでは、1 回の broadcast / multicast を DMVPN cloud 内の全 peer へ自動複製できない。

NHRP は、ATM や Frame Relay のような NBMA network で、network layer のアドレスから実際の送信先アドレスを解決するために定義された。Cisco DMVPN では、mGRE の外側 IP 宛先として使う underlay 側のアドレスを NBMA アドレスと呼ぶ。

NBMA アドレスという名前は、すべての peer が同じ underlay subnet に所属することを意味しない。NHRP が Tunnel アドレスに対応付ける外側の送信先アドレスを表しており、それぞれが異なる underlay subnet に所属していてもよい。

NBMAアドレスとrouted underlay

flowchart TB
    hub["Hub Gi0/0<br/>NBMA: 203.0.113.2/30"]
    spoke1["Spoke1 Gi0/0<br/>NBMA: 198.51.100.2/30"]
    spoke2["Spoke2 Gi0/0<br/>NBMA: 192.0.2.2/30"]

    subgraph underlay["Routed IP underlay"]
        direction TB
        hubGw["Hub側 next hop<br/>203.0.113.1/30"]
        spoke1Gw["Spoke1側 next hop<br/>198.51.100.1/30"]
        spoke2Gw["Spoke2側 next hop<br/>192.0.2.1/30"]
        routing(("IP routing"))

        hubGw --- routing
        spoke1Gw --- routing
        spoke2Gw --- routing
    end

    hub --- hubGw
    spoke1 --- spoke1Gw
    spoke2 --- spoke2Gw

Hub と各 Spoke は、NBMA アドレスを送信元・宛先とする外側 IP packet を underlay 経由で交換する。

DMVPN overlay

overlay は、各ルータの Tunnel0 に設定した 10.255.0.x で構成する論理ネットワークである。Hub は 10.255.0.1、Spoke1 は .11、Spoke2 は .12 を使用する。

flowchart LR
    spoke1["Spoke1<br/>Tunnel0: 10.255.0.11"]
    hub["Hub / NHS<br/>Tunnel0: 10.255.0.1"]
    spoke2["Spoke2<br/>Tunnel0: 10.255.0.12"]

    spoke1 ==>|"最初はHub経由"| hub
    hub ==>|"最初はHub経由"| spoke2
    spoke1 -.->|"NHRP解決後の<br/>Phase 3 shortcut"| spoke2

Spoke1 から Spoke2 への通信は最初に Hub を経由し、NHRP Redirect と NHRP Resolution の完了後は Spoke 間の直接経路へ切り替わる。

Underlayとoverlayを結ぶNHRP

動的ルーティングは、拠点 LAN への経路と overlay 上の next hop を決める。NHRP は、Tunnel アドレスと NBMA アドレスを対応付け、mGRE の外側 IP 宛先を決める。

shortcut形成前

Spoke1 の routing table では、Spoke2 LAN 192.168.2.0/24 の next hop は Hub になっている。最初の packet は Hub の NBMA アドレスへ送られる。

宛先LAN:                   192.168.2.0/24
routing tableのnext hop:  10.255.0.1（Hub）
NHRP mapping:             10.255.0.1 -> 203.0.113.2
mGRE外側IPの宛先:          203.0.113.2

shortcut形成後

Hub から NHRP Redirect を受けた Spoke1 は、Spoke2 の Tunnel / NBMA 対応を解決し、Spoke2 LAN に対する NHRP next-hop override を作る。routing table の next hop が Hub のままでも、実際の転送先は Spoke2 になる。

宛先LAN:                   192.168.2.0/24
routing tableのnext hop:  10.255.0.1（Hub）
NHRP next-hop override:   10.255.0.12（Spoke2）
NHRP mapping:             10.255.0.12 -> 192.0.2.2
mGRE外側IPの宛先:          192.0.2.2

unicast は解決した 1 台の NBMA peer へ送ればよい。一方、mGRE は multicast をどの NBMA peer へ複製するかを自動決定しないため、NHRP multicast mapping を使って配送先を決める。

DMVPNを構成する要素

要素	DMVPNでの役割
mGRE	1 個の Tunnel インターフェースで複数の GRE peer を扱う
NHRP	Tunnel アドレスと NBMA アドレスを対応付ける
動的ルーティング	どの拠点 LAN がどの方向にあるかを広告する
IPsec	mGRE パケットを peer ごとに保護する

動的ルーティングと NHRP は、別の情報を扱う。

EIGRP や OSPF：拠点 LAN の経路と overlay 上の next hop を決める。
NHRP：Tunnel / NBMA 対応を管理し、Phase 3 では remote Spoke への next-hop override を作る。

NHRP はルーティングプロトコルではない。NHRP だけでは、192.168.2.0/24 が Spoke2 側にあることは広告されない。

mGRE

通常の point-to-point GRE では、Tunnel インターフェースに 1 個の tunnel destination を設定する。そのため、Hub が Spoke ごとに point-to-point GRE を作ると、Spoke の増加に合わせて Tunnel インターフェースも増える。

mGRE では、次のように固定の tunnel destination を持たない。

tunnel mode gre multipoint

送信先の NBMA アドレスは NHRP のマッピングから決まる。Hub は 1 個の mGRE インターフェースで複数の Spoke を収容でき、Phase 2 / 3 の Spoke は同じ mGRE インターフェースから別の Spoke へ動的な直接通信を作れる。

multipoint は「常に全 Spoke へ複製して送る」という意味ではない。通常の unicast データは、NHRP で解決した 1 個の NBMA peer へ送られる。

NHRPの登録と解決

NHSとNHC

NHRP には、問い合わせを開始する NHC（Next Hop Client）と、その問い合わせを処理する NHS（Next Hop Server）がある。DMVPN では通常、Spoke が NHC、Hub が NHS になる。

役割	この構成の機器	何をするか
NHC	Spoke	自分の Tunnel / NBMA 対応を登録し、remote peer の NBMA アドレスを問い合わせる
NHS	Hub	Spoke の登録を保持し、NHRP Resolution Request を適切な方向へ処理・転送する

Spoke は NBMA network 上の全 peer を broadcast で自動発見できない。そのため、最初に連絡する既知の相手を NHS として設定し、自分の所在を登録する必要がある。NHS は NHRP における登録・解決の合流点であり、DNS server や DHCP server ではない。また、拠点 LAN の経路を広告する routing server でもない。LAN 経路の交換は EIGRP や OSPF が行う。

この構成では Hub の NHRP cache に、たとえば 10.255.0.11 -> 198.51.100.2 が登録される。Spoke の ip nhrp nhs 10.255.0.1 は、「自分をどこへ登録し、最初の NHRP 問い合わせをどこへ送るか」を指定する。

Spokeの登録

Spoke は起動すると、Hub に次の対応を登録する。

Spoke1 Tunnel 10.255.0.11
  ↔ Spoke1 NBMA 198.51.100.2

Hub 側では Spoke の NBMA アドレスを静的に列挙しない。ip nhrp map multicast dynamic により、登録済みの Spoke へ動的ルーティングの multicast / broadcast パケットを複製できる。

SpokeからHubへのマッピング

Spoke は、登録先である Hub の Tunnel / NBMA 対応をあらかじめ知る必要がある。

ip nhrp map 10.255.0.1 203.0.113.2
ip nhrp map multicast 203.0.113.2
ip nhrp nhs 10.255.0.1

unicast マッピングは Hub の Tunnel アドレスを NBMA アドレスへ変換する。
multicast マッピングは EIGRP / OSPF のパケットを Hub へ送る。
NHS は NHRP 登録・解決で問い合わせる Hub を指定する。

DMVPNのPhaseとは

ここでいう Phase は、DMVPN の設計方式を分類する名称である。1 回の通信中に Phase 1、2、3 の順で状態が進むわけではなく、IKEv1 の Phase 1 / Phase 2 とも関係がない。構築時に、Spoke 間の転送方法とルーティング上の next hop の扱いをどの方式にするかを選ぶ。

dmvpn phase 3 のように Phase 番号を直接指定するコマンドはない。mGRE、NHRP mapping、redirect / shortcut、routing protocol の next hop 処理をどう組み合わせたかによって、Phase 1・2・3 のどの方式として動作するかが決まる。

Phase 1

Spoke 間通信を必ず Hub 経由にする方式である。Hub は mGRE で動的に増える Spoke を 1 個の Tunnel に収容できるが、Spoke は通常 point-to-point GRE を使い、remote Spoke へ直接 peer を作らない。構成は単純だが、Spoke 間のデータも Hub の帯域幅と処理能力を消費する。

設定手順は Cisco機器でDMVPN Phase 1を設定するを参照する。

Phase 2

NHRP で remote Spoke の NBMA アドレスを解決し、Spoke 間の直接通信を可能にする方式である。直接通信するため、routing protocol が広告する next hop に remote Spoke の Tunnel アドレスを維持する必要がある。Hub を next hop に書き換えたり、大きく経路集約したりすると、直接相手を解決できなくなる場合がある。

設定手順は Cisco機器でDMVPN Phase 2を設定するを参照する。

Phase 3

最初の packet は Hub 経由で送るが、Hub の NHRP Redirect を契機に Spoke が remote Spoke を解決し、以降を直接通信へ切り替える方式である。routing table 上の next hop が Hub のままでも NHRP shortcut で実際の転送先を上書きできるため、Phase 2 より経路集約と大規模化に適応しやすい。

比較

Phase	Spoke間通信	Spoke側Tunnel	ルーティング上の要点
Phase 1	必ず Hub 経由	point-to-point GRE が典型	next hop は Hub でよい
Phase 2	必要に応じて直接通信	mGRE	remote Spoke の next hop をルーティングで維持する必要がある
Phase 3	最初は Hub 経由、その後直接通信	mGRE	next hop が Hub のままでも NHRP redirect / shortcut で上書きできる

Phase 2 では、Spoke がルーティングテーブルから remote Spoke の Tunnel アドレスを知る必要がある。たとえば EIGRP では、Hub が Spoke から学習した next hop を別の Spoke へ広告するときに維持する設定が必要になる。

Phase 3 では、Hub を next hop とする集約経路やデフォルト経路でも動作させやすい。最初のパケットを受けた Hub が「より短い経路を解決できる」と送信元 Spoke に通知し、NHRP が実際の remote Spoke を解決する。

Interactive topology

DMVPN Phase経路エクスプローラー

同じSpoke間通信を並べ、データの実経路とNHRP制御の役割をPhaseごとに比較する。JavaScriptが無効な場合は、3つのPhaseを続けて読める。

Hub経由
Spoke間直接
NHRP制御

Phase 1 — Hubが常に中継

Spoke間のデータは、通信開始時から定常時までHubを経由する。NHRPでshortcutは作らない。

比較状態

通信開始時

Data: Hub経由

Data plane

Spoke 1がHubへ送り、HubがSpoke 2へ中継する。

Control plane

SpokeはNHSへ登録するが、remote Spokeへのshortcutは解決しない。

変化なしHub経由を維持

比較状態

定常時

Data: Hub経由

Data plane

以後のデータもHubが中継し続ける。

Control plane

NHRP登録を維持しても、Spoke間の直接マッピングは作らない。

通信が成立するまで

経路を選ぶ
remote subnetのnext hopはHub。
Hubへ転送
Spoke 1はHubのNBMAアドレスを使う。
Hubが中継
Hubが受信し、Spoke 2へ再転送する。

ルーティング上のnext hop: Hub
実際の転送先: Hub
成立条件: Spoke間shortcutを使わず、Hubがすべてのデータを中継する。

Phase 2 — remote Spokeをnext hopに維持

ルーティングでremote SpokeのTunnel next hopを維持し、NHRP解決後のデータをSpoke間で直接転送する。

比較状態

初回通信（NHRP解決後）

Data: Spoke間直接

Data plane

remote SpokeのNBMAアドレスを解決してから、データを直接送る。

Control plane

送信前のNHRP ResolutionはHub/NHSを経由してSpoke 2を解決する。

NHRP解決直接経路を維持

比較状態

定常時

Data: Spoke間直接

Data plane

キャッシュしたNHRPマッピングを使い、直接転送を続ける。

Control plane

有効なマッピングがある間は、データ転送でHubを経由しない。

通信が成立するまで

next hopを確認
ルーティング上のnext hopはremote Spoke。
NHRPで解決
Hub/NHSを介してremote SpokeのNBMAを得る。
直接転送
解決後のデータはSpoke 1からSpoke 2へ送る。

ルーティング上のnext hop: remote SpokeのTunnelアドレス
実際の転送先: NHRPで解決したremote SpokeのNBMAアドレス
成立条件: ルーティング更新時にremote Spokeのnext hopをHubへ書き換えない。

Phase 3 — Redirectでshortcutを学習

最初のデータはHubを経由する。HubのNHRP Redirectを契機にremote Spokeを解決し、以後は直接転送する。

比較状態

最初のデータ

Data: Hub経由

Data plane

ルーティング上のnext hopであるHubへ送り、Hubが中継する。

Control plane

Hubはより適切な転送先を示すNHRP RedirectをSpoke 1へ返す。

Redirect + Resolutionshortcutへ切替

比較状態

shortcut確立後

Data: Spoke間直接

Data plane

NHRP next-hop overrideにより、データをSpoke 2へ直接送る。

Control plane

Spoke 1がResolutionで得たshortcutマッピングをキャッシュする。

通信が成立するまで

Hub経由で転送
最初のデータはルーティングどおりHubへ進む。
Redirectを受信
HubがSpoke 1へ、より直接的な転送先を通知する。
shortcutを作る
Spoke 1がSpoke 2を解決し、以後は直接転送する。

ルーティング上のnext hop: Hubのままでもよい
実際の転送先: NHRP next-hop overrideでremote Spoke
成立条件: Hubでredirect、Spokeでshortcutを有効にする。

Phase 3のredirectとshortcut

Phase 3 では、Hub の ip nhrp redirect と Spoke の ip nhrp shortcut を組み合わせる。

sequenceDiagram
    participant S1 as Spoke1
    participant H as Hub / NHS
    participant S2 as Spoke2

    S1->>H: 宛先LANへの最初のデータ
    H->>S2: 最初のデータを転送
    H-->>S1: NHRP Redirect
    S1->>H: NHRP Resolution Request
    H->>S2: Resolution Requestを転送
    S2-->>S1: Resolution ReplyとNBMAアドレス
    S1->>S2: Spoke間peerを解決してIPsec SAを確立
    S1->>S2: 以降のデータを直接転送

Spoke1 のルーティングテーブルでは、Spoke2 LAN の next hop が Hub になっている。
最初のデータは Hub に届き、Hub が Spoke2 へ転送する。
Hub は Spoke1 に NHRP Redirect を返す。
Spoke1 は Spoke2 LAN の実際の next hop を解決するため、NHRP Resolution Request を送る。
Spoke2 の Tunnel アドレスと NBMA アドレスを含む Resolution Reply が Spoke1 に返る。
Spoke1 は動的 NHRP entry と next-hop override を作る。
以降の通信は Spoke1 と Spoke2 の間を直接流れる。Tunnel protection が設定されていれば、peer 間の IPsec SA も動的に作られる。GRE 自体は接続確立型の protocol ではない。

ルーティングテーブルに表示される next hop が Hub のままでも、CEF / NHRP の next-hop override によって実際の転送先が Spoke2 へ変わる場合がある。そのため、Phase 3 の確認では show ip route だけでなく、show ip nhrp shortcut と show ip route next-hop-override も確認する。

ICMP RedirectとNHRP Redirectは別物

ICMP Redirectとは

ICMP（Internet Control Message Protocol）は、IPv4 の通信状態やエラーを通知するための制御 protocol である。ICMP Redirect（ICMP Type 5）は、ルータが packet の送信元へ「同じ IP ネットワーク上に、より適切な next hop がある」と通知する message である。

送信元は、別ネットワーク宛ての packet を通常は default gateway へ送る。しかし、その gateway が packet を受信した interface と同じ interface から別のルータへ転送する場合、送信元からそのルータへ直接送った方が短い経路になることがある。gateway は ICMP Redirect で転送先とより適切な next hop を通知し、受信側は実装や設定に応じて、その情報を route cache などへ反映する。

DMVPN Hub では、Spoke1 から届いた packet が Tunnel0 に入り、Spoke2 へ向けて同じ Tunnel0 から出る。複数の peer が 1 個の mGRE interface を共有するため、IPv4 の転送処理から見ると ICMP Redirect の送信条件に該当し得る。

`no ip redirects`

Cisco IOS / IOS XE の interface で no ip redirects を設定すると、その interface からの IPv4 ICMP Redirect 送信を無効化する。

ICMP Redirect は IP next hop を通知するが、Tunnel アドレスから NBMA アドレスへの変換や NHRP shortcut の作成は行わない。DMVPN では NHRP が peer を解決するため、Hub と Spoke の Tunnel0 で通常の ICMP Redirect を無効化する。

`ip nhrp redirect`

ip nhrp redirect は NHRP Redirect を有効化する。Hub が送信元 Spoke に対し、「remote Spoke を NHRP で解決できる」と通知し、NHRP Resolution と Phase 3 shortcut を開始する契機になる。

no ip redirects：通常の IPv4 ICMP Redirect を送信しない。
ip nhrp redirect：Hub から送信元 Spoke へ NHRP Redirect を送信する。

二つは別の protocol を制御するコマンドであり、通常の ICMP Redirect は全ルータの Tunnel0 で無効化し、NHRP Redirect は Hub で有効化する。

network-id、tunnel key、NHRP authentication

network-id、tunnel key、NHRP authentication は、いずれも 100 や DMVPN100 のような値を使うが、存在する層と目的が異なる。

設定	機能する層	必須性
`ip nhrp network-id 100`	NHRP interface	必須
`tunnel key 100`	GRE header	単一 cloud では任意
`ip nhrp authentication DMVPN100`	NHRP message	任意

ip nhrp network-id 100

その Tunnel で NHRP を有効化する。値は local significance であり、peer 認証には使われない。この例では追跡しやすいよう全台を 100 にそろえる。

tunnel key 100

GRE header 内で論理 cloud を識別する。同じ underlay / tunnel source 上に複数の mGRE Tunnel があるとき、受信 packet を正しい Tunnel へ振り分けるために使う。同じ cloud の全 peer で一致させるが、暗号鍵ではない。

ip nhrp authentication DMVPN100

異なる文字列を持つ NHRP message を受け入れないことで、別 cloud 用ルータの誤設定による混入を減らす。全 peer で一致させるが、文字列は暗号化されず、機器の正当性を保証する認証ではない。

単一 cloud の最小構成は tunnel key と NHRP authentication がなくても成立し得る。この例では、cloud の境界を設定上で明示し、誤設定を発見しやすくするために両方を入れている。値が偶然同じでも相互に代用はできない。

EIGRPを載せる場合

EIGRP 自体の設定は Cisco機器でEIGRPを設定するを参照する。DMVPN で追加して考える点は次の二つである。

Hubのsplit horizon

split horizon は、「ある interface から学習した経路を、同じ interface から広告しない」という loop 防止規則である。通常の interface では、学習元へ経路をそのまま返すことを防ぐ合理的な動作である。

DMVPN Hub では複数の論理 peer が 1 個の Tunnel0 を共有するため、次の問題が起きる。

Hub は Spoke1 の 192.168.1.0/24 を Tunnel0 から学習する。
Spoke2 にその経路を伝える場合も、送信 interface は同じ Tunnel0 になる。
split horizon が有効だと、同じ interface からの再広告として止められる。
Spoke2 は Spoke1 LAN の経路を学習できない。

そこで Hub の Tunnel0 にだけ no ip split-horizon eigrp 100 を設定する。これは「split horizon は不要」という意味ではなく、1 個の multipoint interface の先に複数の別 peer がいるため、既定規則が topology を正しく表せないことへの例外である。Spoke は別 Spoke の経路を中継広告しないため、この無効化は不要である。

next-hop-selfを残す

Phase 3 では、Hub が EIGRP next hop を自分に変更したままでよい。Spoke はまず Hub へ送り、NHRP Redirect を受けて remote Spoke の next-hop override を作る。

Phase 2 で使われる no ip next-hop-self eigrp を Phase 3 の基本構成へ入れると、Phase ごとの仕組みが混ざる。この設定は Phase 3 の必須条件ではない。

OSPFを載せる場合

OSPF network type の一般的な動作は OSPF network type を参照する。router ospf と ip ospf の役割は router ospfとip ospfの役割、ip ospf network の役割は OSPF network typeの設定を参照する。

DMVPN の mGRE は multipoint であるため、全ルータの Tunnel0 を OSPF point-to-multipoint にそろえる。この network type では DR / BDR を必要とせず、Hub と各 Spoke が隣接関係を作れる。

Tunnel subnetの/32 host routeとdistribute-list

point-to-multipoint では、OSPF が Tunnel peer のアドレスを /32 host route として扱う。たとえば Spoke1 に、Spoke2 の Tunnel address へ Hub 経由で到達する次の経路が作られることがある。

O 10.255.0.12/32 via 10.255.0.1, Tunnel0

この /32 は connected route の 10.255.0.0/24 より prefix が長いため、10.255.0.12 宛ての検索で優先される。remote Tunnel address を Hub 向きに固定する OSPF route が NHRP shortcut の解決と競合しないよう、Tunnel subnet 内の OSPF /32 をローカルのルーティングテーブルから除外する。

ip prefix-list BLOCK-DMVPN-HOSTS seq 5 deny 10.255.0.0/24 ge 32
ip prefix-list BLOCK-DMVPN-HOSTS seq 10 permit 0.0.0.0/0 le 32

1 行目は 10.255.0.0/24 に含まれる /32 だけを拒否する。IPv4 の最大 prefix length は /32 なので、ge 32 が一致するのは host route だけである。2 行目はそれ以外の IPv4 route を許可する。この行がないと、prefix-list 末尾の暗黙の deny により LAN route なども拒否される。

router ospf 10
 distribute-list prefix BLOCK-DMVPN-HOSTS in

in は packet の受信方向を表していない。OSPF が LSDB から計算した route をローカルの RIB へインストールするときに、prefix-list を適用する方向である。

LSAをLSDBへ格納 → SPFでrouteを計算 → distribute-list in → RIBへインストール

拒否された /32 も LSA として LSDB には残るため、distribute-list ... in は LSA flooding を止めない。各ルータが自分の RIB への投入を判断するため、Hub とすべての Spoke で同じ filter を設定する。out は outbound filtering を表し、ローカル RIB への投入を止める in の代わりにはならない。

MTUとMSS

DMVPN のデータは、内側 IP、GRE、外側 IP、ESP など複数のヘッダーを持つ。underlay の MTU が 1500 byte の場合、内側でも 1500 byte を許可すると断片化や Path MTU Discovery の問題が発生しやすい。

MTU 1500 byte の underlay に対する開始値として、次の値を使用できる。

ip mtu 1400
ip tcp adjust-mss 1360

ip mtu 1400 は Tunnel0 が受け付ける内側 IP packet の MTU を下げる。
ip tcp adjust-mss 1360 は Tunnel を通る TCP SYN の MSS を調整する。

1400 / 1360 はすべての underlay に対する絶対値ではない。NAT-T、追加カプセル化、実際の path MTU に応じて確認する。

bandwidth 1000 はインターフェースの物理速度を制限しない。EIGRP metric などが参照する論理帯域幅を設定する。

NATとPAT

Spoke の NBMA アドレスが NAT される構成では、Hub が NHRP 登録から変換後の NBMA 情報を学習できる場合がある。IPsec 側では NAT-T が使われることもある。

ただし、異なる Spoke がそれぞれ別の NAT 装置の PAT 配下にいる場合、Spoke 間の直接 session を確立できないことがある。Hub-Spoke の成立だけで、Phase 3 の直接通信も成立すると判断してはいけない。

ip nhrp registration no-unique は、同じ NBMA アドレスから複数の NHRP 登録を許可する必要がある NAT 構成で使用する。NAT 装置の変換方式と NHRP 登録要件を確認して有効化する。

よくある誤解

誤解	実際
DMVPN は IPsec の別名	mGRE と NHRP が overlay を作り、IPsec は通常そのパケットを保護する
NHRP が LAN 経路を広告する	LAN 経路の広告は EIGRP / OSPF などが行う
`network-id` が一致すれば安全	network-id は対向認証ではない
Phase 3 は最初から常に直接通信	shortcut がない最初の通信は Hub を経由し、NHRP 解決後に直接経路へ変わる
`show ip route` の next hop だけで転送先が分かる	Phase 3 では NHRP next-hop override も確認する必要がある

通常推奨される構成

多数の Spoke で同じ wildcard PSK を共有すると、1 台の侵害が cloud 全体へ影響する。管理可能な環境では IKEv2 証明書認証を検討する。
Hub 障害に備える場合は、複数 NHS や dual-hub / dual-cloud を設計する。
GRE keepalive は DMVPN の mGRE で使用せず、NHRP、IKE DPD、DMVPN tunnel health monitoring など対応機能で障害を検出する。
NHRP 登録数、動的 peer、IKE / IPsec SA、shortcut の生成・期限切れを監視する。
対応機器では AES-GCM や ECDH を検討する。暗号方式の考え方は PRFとAEAD を参照する。

DMVPNの仕組みとPhase 1・2・3

全体像

UnderlayとNBMAアドレス

NBMAアドレスとrouted underlay

DMVPN overlay

Underlayとoverlayを結ぶNHRP

shortcut形成前

shortcut形成後

DMVPNを構成する要素

mGRE

NHRPの登録と解決

NHSとNHC

Spokeの登録

SpokeからHubへのマッピング

DMVPNのPhaseとは

Phase 1

Phase 2

Phase 3

比較

通信が成立するまで

通信が成立するまで

通信が成立するまで

Phase 3のredirectとshortcut

ICMP RedirectとNHRP Redirectは別物

ICMP Redirectとは

no ip redirects

ip nhrp redirect

network-id、tunnel key、NHRP authentication

EIGRPを載せる場合

Hubのsplit horizon

next-hop-selfを残す

OSPFを載せる場合

Tunnel subnetの/32 host routeとdistribute-list

MTUとMSS

NATとPAT

よくある誤解

通常推奨される構成

関連

参考リンク

`no ip redirects`

`ip nhrp redirect`