ちらりんブログ ロゴ ちらりんブログ
STUDY · NETWORK GUIDE

6-7 DMVPN (実践) — 宛先を書かないトンネルと、問い合わせて解決する NHRP

DMVPN は mGRE と NHRP で拠点間のトンネルを必要になったときに張ります。csr1000v 4 台で Phase 1 / 2 / 3 を組み替え、登録と解決、EIGRP の next-hop、redirect と近道の経路、MTU 1400 を実測します。

1. 前節の振り返りと本節の内容

前節 6-6 SD-Access の LISP コントロールプレーン では、ファブリックの制御が LISP (Locator/ID Separation Protocol)、転送が VXLAN (Virtual Extensible LAN) であること、端末が EID (Endpoint Identifier) として map-server へ登録されること、リモートの端末の居場所は経路表ではなく map-cache に載るので消せば引き直されること、そしてオーバーレイを通る最大サイズが、10 バイト刻みの掃引で確認できた範囲で 1450 であったことを扱いました。舞台はキャンパスの内側に閉じており、装置のあいだの経路は最初から OSPF で通っていました。

本節は WAN を挟んだ拠点間を扱います。DMVPN (Dynamic Multipoint VPN) は mGRE (multipoint GRE) と NHRP (Next Hop Resolution Protocol) を組み合わせ、拠点間のトンネルを必要になったときに張る仕組みです。6-6 の末尾は、この「問い合わせて解決する」という形が LISP の map-request に似て見えるが同じものではない、と予告しました。違う点として名指しされたのは 3 つです。以下のとおりです。

6-6 が名指しした軸LISP の map-request（6-6）NHRP の resolution-request（本節）
解決する対象EID（端末そのものを識別するアドレス）に対応する RLOC（端末を収容している装置のアドレス）トンネル側の next-hop アドレス、または宛先プレフィックスに対応する NBMA アドレス（相手のルータが WAN 側に持つ実アドレス）
答えを持つ装置control plane node。map-server と map-resolver を兼ね、ETR が自分の EID を登録するNHS (Next Hop Server)。DMVPN では hub がこれにあたり、spoke が自分の実アドレスを登録する
キャッシュの置き場所map-cache。リモートの端末は経路表には載らないNHRP キャッシュ。加えて本ラボの Phase 3（集約を配る構成）では経路表にも H の経路として載る（§10 / §11。同一プレフィックスの経路が既に在る構成では別の形になる）

3 番目の差が本節の主題です。6-6 のファブリックでは、リモートの端末の居場所は経路表に現れないことが機構でした。DMVPN の近道は逆に、経路表に NHRP の経路として現れます。答え合わせは §13 で行います。

もう 1 つ、2 章ぶん越しの予告があります。4-8 サイト間 VPN は、static VTI が 1 対向 1 であることの限界に触れたうえで、DMVPN は mGRE と NHRP を組み合わせて 1 つのトンネルインタフェースで多数の拠点を収容すること、そしてそれを第 6 章で扱うことを書きました。本節がその回収です。4-8 が実機で組んだ Tunnel0 は tunnel destination を持っていました。ここで引き継ぐのは「相手が 1 台に決まっているから宛先を書ける」という形だけです（4-8 の Tunnel0 は tunnel mode ipsec ipv4 の sVTI で GRE ではないので、宛先の 1 行を落とせば mGRE になる、という関係ではありません）。mGRE そのものは §2 で p2p GRE と並べて見ます。

本節は出典に基づく部分と、本ラボの実測に基づく部分をはっきり分けます。

層どこ何を根拠にしているか
出典層§2 の GRE の定義 / §3 / §10 の後半 / §12 の推奨値 / §14 の一部RFC 2332 (NHRP)、RFC 2784・RFC 1702 (GRE)、Cisco の DMVPN / NHRP 設定ガイド (IOS-XE 17.x)、Cisco の Phase 3 構成例、Cisco の GRE / MTU 解説
実測層§2 と §4〜§12 の show 出力と config / §13 の右列（出典によると明記した項目を除く） / §14 の残りCML 上の csr1000v 17.03.08a 4 台と alpine 2 台で 2026 年 9 月 21 日に取得した 23 ファイル（§14 だけは 23 ファイルの外に出る記述が 2 点あります。CDP の既定値は同じイメージで先に回した事前検証ラボの記録、show running-config all interface Tunnel0 が拒否された応答は別の実行の記録で、いずれも本文にその旨を書いています）
測っていないこと§15—

以下に貼る実機出力は改変していません。長い出力から必要な行だけを抜き出した箇所には … を置いてありますが、抜き出した行そのものは実機が印字したままです。ただしプロンプトと投入コマンドを 1 行にまとめた表記だけは本節の組み立てで、実機はこの 2 つを別の行に印字します。

6-3 / 6-4 の SD-WAN との関係も先に置いておきます。SD-WAN が解いているのも「拠点間をオーバーレイで結ぶ」という同じ問題で、 違うのは誰が決めるかです。SD-WAN はコントローラ（vSmart）が方針を配って各拠点がそれに従う形で、 6-4 で見たとおり経路の配布と暗号鍵の配布がコントローラ経由に寄っています。 本節の DMVPN は装置どうしが直接やりとりして決める形で、拠点の実アドレスは NHRP の登録と解決で集め、 経路は EIGRP が運びます。中央の頭脳はありません。 どちらが新しいという話ではなく、hub が単一障害点になる範囲と設定の置き場所が違います。 SD-WAN を先に見てから DMVPN の CLI を見るのは、コントローラが肩代わりしている仕事の中身を、 1 つずつ手で組んで確かめるためです。

2. 宛先を書かないトンネル

GRE (Generic Routing Encapsulation) は、あるネットワーク層のパケットを別のネットワーク層のパケットで包む仕組みです。RFC 2784 は目的を 1 行で書いています。

This document specifies a protocol for encapsulation of an arbitrary network layer protocol over another arbitrary network layer protocol.

包んだあとのパケットは三層になります。同じ RFC が図で示しているのは次の 3 つです。

snippet 
    ---------------------------------
    |                               |
    |       Delivery Header         |
    |                               |
    ---------------------------------
    |                               |
    |       GRE Header              |
    |                               |
    ---------------------------------
    |                               |
    |       Payload packet          |
    |                               |
    ---------------------------------

外側の配送用ヘッダが IPv4 のとき、その protocol 番号は 47 です。

IP as a delivery protocol GRE packets which are encapsulated within IP will use IP protocol type 47.

4-8 の Tunnel0 も tunnel source と tunnel destination の対を持っていました（あちらは tunnel mode ipsec ipv4 の sVTI で、GRE ではありません。ここで見ているのは暗号化の有無やモードではなく、宛先を書くか書かないかの 1 点です）。相手が 1 台に決まっているからこそ、宛先をあらかじめ書けます。mGRE はこの tunnel destination を書かないトンネルです。Cisco は mGRE を DMVPN の構成要素の 1 つとして次のように定義します。

mGRE tunnel interface –Allows a single GRE interface to support multiple IPsec tunnels and simplifies the size and complexity of the configuration.

1 つのインタフェースで複数の相手を収容する、という部分が要点になります。本ラボの hub の Tunnel0 は次のとおりです。

snippet 
HUB# show running-config interface Tunnel0
Building configuration...

Current configuration : 250 bytes
!
interface Tunnel0
 ip address 10.99.0.1 255.255.255.0
 no ip redirects
 ip mtu 1400
 no ip split-horizon eigrp 100
 ip nhrp network-id 1
 ip nhrp holdtime 300
 ip tcp adjust-mss 1360
 tunnel source GigabitEthernet2
 tunnel mode gre multipoint
end

tunnel source GigabitEthernet2 はありますが、tunnel destination の行がありません。代わりに tunnel mode gre multipoint が入っています。同じ時刻の spoke 側（Phase 1 の状態）を並べます。

snippet 
SPOKE1# show running-config interface Tunnel0
Building configuration...

Current configuration : 264 bytes
!
interface Tunnel0
 ip address 10.99.0.2 255.255.255.0
 ip mtu 1400
 ip nhrp map 10.99.0.1 203.0.113.2
 ip nhrp network-id 1
 ip nhrp holdtime 300
 ip nhrp nhs 10.99.0.1
 ip tcp adjust-mss 1360
 tunnel source GigabitEthernet2
 tunnel destination 203.0.113.2
end

tunnel destination 203.0.113.2 があり、tunnel mode の行がありません。既定値まで表示させると、この spoke の Tunnel0 は GRE のままであることが分かります。

snippet 
SPOKE1# show running-config all | section interface Tunnel0
…
 tunnel source GigabitEthernet2
 tunnel mode gre ip
 tunnel destination 203.0.113.2
…

tunnel mode gre ip が既定値として印字されています。mGRE と p2p GRE を分けているのは tunnel destination を書くかどうかと、tunnel mode gre multipoint を入れるかどうかの 2 点です。

ただし上の 2 つの出力を並べて見ると、違いはその 2 行だけではありません。アドレスのほかに、hub 側には no ip redirects と no ip split-horizon eigrp 100 が、spoke 側には ip nhrp map と ip nhrp nhs が出ています。前者は mGRE にしたことに伴って現れたもの（§14）と EIGRP のために入れたもの（§6）、後者は spoke が NHS を知るために要る行（§3）です。トンネルの形を決める 2 行と、その周りに要る行は別物なので、この 2 行だけを写しても動く構成にはなりません。

この差は show dmvpn detail の表示にも現れます。spoke 側を先に見ます。

snippet 
SPOKE1# show dmvpn detail
…
Interface Tunnel0 is up/up, Addr. is 10.99.0.2, VRF "global" 
   Tunnel Src./Dest. addr: 198.51.100.2/203.0.113.2, Tunnel VRF "global"
   Protocol/Transport: "GRE/IP", Protect "" 
   Interface State Control: Disabled
   nhrp event-publisher : Disabled
…

Tunnel Src./Dest. addr が 198.51.100.2/203.0.113.2 と 2 つのアドレスの組になり、Protocol/Transport は "GRE/IP" です。hub 側は違います。

snippet 
HUB# show dmvpn detail
…
Interface Tunnel0 is up/up, Addr. is 10.99.0.1, VRF "global" 
   Tunnel Src./Dest. addr: 203.0.113.2/Multipoint, Tunnel VRF "global"
   Protocol/Transport: "multi-GRE/IP", Protect "" 
   Interface State Control: Disabled
   nhrp event-publisher : Disabled
…

宛先の側が Multipoint と印字され、Protocol/Transport は "multi-GRE/IP" になります。同じ interface Tunnel0 でも、宛先を書いた側と書かなかった側では印字そのものが違います。

宛先を書かないということは、パケットを出すときに相手の実アドレスを別の手段で知らなければならない、ということでもあります。その手段が NHRP です。

3. NHRP とは何か

NHRP (Next Hop Resolution Protocol) は、RFC 2332 が NBMA 網のために定めたプロトコルです。NBMA (Non-Broadcast Multi-Access) は、複数の装置が同じ網に繋がっているのにブロードキャストが使えない網を指します。RFC の冒頭はこうです。

The NBMA Next Hop Resolution Protocol (NHRP) allows a source station (a host or router), wishing to communicate over a Non-Broadcast, Multi-Access (NBMA) subnetwork, to determine the internetworking layer addresses and NBMA addresses of suitable “NBMA next hops” toward a destination station.

解決の対象は、この一文の後半が名指ししています。 the internetworking layer addresses and NBMA addresses of suitable "NBMA next hops" の部分です。

求めるのは「次に渡すべき相手の NBMA アドレス」です。6-6 の LISP が端末の識別子から収容装置のアドレスを求めたのに対し、NHRP が求めるのはトンネルの相手そのものの実アドレスになります。

答えを持つ側と尋ねる側には名前が付いています。

The term “server”, unless explicitly stated to the contrary, refers to a Next Hop Server (NHS). An NHS is an entity performing the Next Hop Resolution Protocol service within the NBMA cloud.

The term “client”, unless explicitly stated to the contrary, refers to a Next Hop Resolution Protocol client (NHC). An NHC is an entity which initiates NHRP requests of various types in order to obtain access to the NHRP service.

NHS の役割は、解決要求に答えることです。

Such stations which are capable of answering NHRP Resolution Requests are known as “Next Hop Servers” (NHSs).

DMVPN ではこの 2 つが hub と spoke に対応します。Cisco は 1 行で言い換えています。

NHRP–A client and server protocol where the hub is the server and the spokes are the clients.

NHRP のメッセージは、本節の範囲では 2 種類に整理できます。登録 (Registration) と解決 (Resolution) で、向きも目的も違います。

種類向き何をするか
Registration Requestspoke → NHSspoke が自分のトンネル側アドレスと NBMA アドレスの対応を NHS に預ける
Registration ReplyNHS → spoke預かったことを返す
Resolution Request要求元 → NHSある宛先へ向かう相手の NBMA アドレスを問い合わせる
Resolution Reply→ 要求元問い合わせへの答えを返す

RFC の定義はこうです。

The NHRP Registration Request is sent from a station to an NHS to notify the NHS of the station’s NBMA information.

The NHRP Registration Reply is sent by an NHS to a client in response to that client’s NHRP Registration Request.

Cisco の設定ガイドは、この 2 つが DMVPN のどの場面に当たるかを 1 文で並べています。

Each spoke registers its real address when it boots and queries the NHRP database for real addresses of the destination spokes to build direct tunnels.

起動したときに登録し、宛先が必要になったときに問い合わせる、という 2 段構えです。hub が持つデータベースの中身も明記されています。

The hub maintains an NHRP database of the public interface addresses of each spoke.

解決の引き金は、通信が発生した瞬間です。

When a spoke needs to send a packet to a destination (private) subnet on another spoke, it queries the NHRP server for the real (outside) address of the destination (target) spoke.

The spoke-to-spoke links are established on demand whenever there is traffic between the spokes. Thereafter, packets can bypass the hub and use the spoke-to-spoke tunnel.

hub との関係だけは常設である、という非対称も同じ資料が書いています。

Each spoke has a permanent IPsec tunnel to the hub, not to the other spokes within the network.

本節のラボは IPsec を外した平文の mGRE で組んでいます。DMVPN 自体は GRE と IPsec と NHRP の組み合わせとして定義されているので、その点は出典の構成と違います。

The Dynamic Multipoint VPN feature combines GRE tunnels, IPsec encryption, and NHRP routing to provide users an ease of configuration via crypto profiles–which override the requirement for defining static crypto maps–and dynamic discovery of tunnel endpoints.

暗号化の側は 4-8 が IKEv2 と sVTI を実機で扱っており、本節で重ねても新しく見えるものがありません。IPsec を外した状態でも mGRE と NHRP の動きはそのまま観測できるため、本節は暗号を外した構成を選びました。この選択で観測できなくなったものは §15 に挙げます。

4. 本ラボの構成

この図を大きく開く ↗

3 拠点は ISP と 1 本ずつ繋がっているだけで、拠点間の直結ケーブルはありません。underlay と overlay と拠点 LAN が別の経路空間であることを示します。

本ラボは csr1000v 4 台と alpine 2 台で組みました。ルータは HUB / SPOKE1 / SPOKE2 と、その 3 台を収容する ISP の 4 台です。版数は次のとおりです。

snippet 
HUB# show version | include IOS XE Software|Cisco IOS Software
Cisco IOS XE Software, Version 17.03.08a
Cisco IOS Software [Amsterdam], Virtual XE Software (X86_64_LINUX_IOSD-UNIVERSALK9-M), Version 17.3.8a, RELEASE SOFTWARE (fc3)

インタフェースは設計どおり up/up です。hub は WAN 側の GigabitEthernet2 と、拠点 LAN の代わりに置いた Loopback10 を持ちます。

snippet 
HUB# show ip interface brief | exclude unassigned
Interface              IP-Address      OK? Method Status                Protocol
GigabitEthernet1       172.16.1.231    YES TFTP   up                    up      
GigabitEthernet2       203.0.113.2     YES TFTP   up                    up      
Loopback10             192.168.10.1    YES TFTP   up                    up

ISP は 3 つの拠点を別々の /30 で収容しています。

snippet 
ISP# show ip interface brief | exclude unassigned
Interface              IP-Address      OK? Method Status                Protocol
GigabitEthernet1       172.16.1.234    YES TFTP   up                    up      
GigabitEthernet2       203.0.113.1     YES TFTP   up                    up      
GigabitEthernet3       198.51.100.1    YES TFTP   up                    up      
GigabitEthernet4       192.0.2.1       YES TFTP   up                    up

拠点側の WAN インタフェースには、RFC 5737 が文書用に予約したアドレスを割り当ててあります。

snippet 
SPOKE1# show running-config | section interface GigabitEthernet2
interface GigabitEthernet2
 description WAN (NBMA side) toward ISP
 ip address 198.51.100.2 255.255.255.252
 negotiation auto
 cdp enable
 no mop enabled
 no mop sysid

配線は CDP で照合しました。アドレスの打ち間違いと配線の取り違えは別の事故なので、経路が通ったことだけでは配線の正しさを確かめたことになりません。

snippet 
ISP# show cdp neighbors
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                  S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone, 
                  D - Remote, C - CVTA, M - Two-port Mac Relay 

Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
HUB.lab.local    Gig 2             144              R I   CSR1000V  Gig 2
HUB.lab.local    Gig 1             138              R I   CSR1000V  Gig 1
SPOKE1.lab.local Gig 3             132              R I   CSR1000V  Gig 2
SPOKE1.lab.local Gig 1             132              R I   CSR1000V  Gig 1
SPOKE2.lab.local Gig 4             177              R I   CSR1000V  Gig 2
SPOKE2.lab.local Gig 1             126              R I   CSR1000V  Gig 1

Total cdp entries displayed : 6

ISP から見て HUB が Gig 2、SPOKE1 が Gig 3、SPOKE2 が Gig 4 に繋がっています。管理用の Gig 1 は 4 台とも同じ管理スイッチに載せてあるため、そちら側でも互いに隣接として見えます。

この ISP は拠点の LAN もトンネルのアドレスも知りません。

snippet 
ISP# show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, m - OMP
       n - NAT, Ni - NAT inside, No - NAT outside, Nd - NAT DIA
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       H - NHRP, G - NHRP registered, g - NHRP registration summary
       o - ODR, P - periodic downloaded static route, l - LISP
       a - application route
       + - replicated route, % - next hop override, p - overrides from PfR
       & - replicated local route overrides by connected

Gateway of last resort is not set

      192.0.2.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.0.2.0/30 is directly connected, GigabitEthernet4
L        192.0.2.1/32 is directly connected, GigabitEthernet4
      198.51.100.0/24 is variably subnetted, 2 subnets, 2 masks
C        198.51.100.0/30 is directly connected, GigabitEthernet3
L        198.51.100.1/32 is directly connected, GigabitEthernet3
      203.0.113.0/24 is variably subnetted, 2 subnets, 2 masks
C        203.0.113.0/30 is directly connected, GigabitEthernet2
L        203.0.113.1/32 is directly connected, GigabitEthernet2

connected の /30 が 3 本あるだけで、192.168. も 10.99. も 1 件も現れず、Gateway of last resort is not set です。これが「トンネルの外側と内側は別の経路空間である」ことの正の根拠になります。

一方、NBMA アドレスどうしは ISP を経由して届きます。トンネルの土台は、トンネルを張る前から整っている必要があります。

snippet 
SPOKE1# ping 192.0.2.2 repeat 5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.0.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms

SPOKE1 から SPOKE2 の WAN 側アドレスへ 5 発とも通っています。ところが同じ Phase 0 の一連の取得の中で、拠点の LAN どうしは通りません（この 2 つは別ファイルに撮っていますが、あいだで設定は変えていません）。端末は alpine を 2 台置いてあり、PC1 が 192.168.11.10、PC2 が 192.168.12.10 です。本節の ping と traceroute は、拠点ルータの LAN 側インタフェースを送信元にして対向拠点の端末へ向けています。

snippet 
SPOKE1# ping 192.168.12.10 source 192.168.11.1 repeat 5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.12.10, timeout is 2 seconds:
Packet sent with a source address of 192.168.11.1 
.....
Success rate is 0 percent (0/5)
snippet 
SPOKE2# ping 192.168.11.10 source 192.168.12.1 repeat 5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.11.10, timeout is 2 seconds:
Packet sent with a source address of 192.168.12.1 
.....
Success rate is 0 percent (0/5)

どちらの向きも Success rate is 0 percent (0/5) です。これは「出力が無い」のではなく、機器が 0 パーセントと印字した正の逐語です。

overlay の上で動かす経路プロトコルには EIGRP を使います。EIGRP 自体は 3-4 EIGRP の複合メトリック で扱ったので、本節では設定だけを示します。

snippet 
HUB# show running-config | section router eigrp 100
router eigrp 100
 network 10.99.0.0 0.0.0.255
 network 192.168.10.0

spoke 側も同じ形です。

snippet 
SPOKE1# show running-config | section router eigrp 100
router eigrp 100
 network 10.99.0.0 0.0.0.255
 network 192.168.11.0

3 台とも overlay の 10.99.0.0/24 と自分の LAN を対象にしているだけで、EIGRP 側に DMVPN 固有の設定はありません。DMVPN のための EIGRP の細工は、すべて Tunnel0 のインタフェース設定として入ります（§6 / §7）。

以降の §5 から §10 は、このトポロジのまま設定だけを 3 回変えます。Phase 1 / 2 / 3 の差は、機器の台数でも結線でもなく、Tunnel0 に入っている行の差です。

ここから Phase 1 / 2 / 3 を順に組んでいきます。「Phase」は Cisco が DMVPN の構成を呼び分けるための言い方で、 プロトコルの版数ではありません。先に三相の差を並べておきます。

Phase 1（§5・§6）Phase 2（§7・§8）Phase 3（§10）
spoke の Tunnel0p2p GRE（tunnel destination あり）mGREmGRE
hub の next-hopip next-hop-self eigrp（既定）で hub に書き換えるno ip next-hop-self eigrp 100 で対向 spoke のまま配る同左 + 集約 1 本だけ配る
hub に足すもの——ip nhrp redirect
spoke が受け取る経路対向拠点の /24（next-hop は hub）対向拠点の /24（next-hop は対向 spoke）集約 192.168.0.0/16 1 本
拠点間の traceroute3 ホップ（hub を折り返す）2 ホップ（直接）2 ホップ（直接）
近道の作られ方作られない経路の next-hop が既に対向 spoke なので、通信時に NHRP が実アドレスを解決hub が Traffic Indication を返し、spoke が解決して経路表に NHRP の経路として足す

3 つとも同じトポロジのまま、設定だけを足して撮っています。 表の内容はすべて本ラボの実測で、根拠は各節の show 出力です。

5. Phase 1 — 登録は起きるが、通信は hub を折り返す

Phase 1 の構成は §2 で見たとおりです。hub だけが mGRE で、spoke は hub 1 点を宛先に持つ p2p の GRE になっています。この状態で spoke は hub へ登録を送ります。

hub のキャッシュには両方の spoke が載りました。

snippet 
HUB# show ip nhrp
10.99.0.2/32 via 10.99.0.2
   Tunnel0 created 00:02:07, expire 00:07:52
   Type: dynamic, Flags: registered nhop 
   NBMA address: 198.51.100.2 
10.99.0.3/32 via 10.99.0.3
   Tunnel0 created 00:01:36, expire 00:08:23
   Type: dynamic, Flags: registered nhop 
   NBMA address: 192.0.2.2

Type: dynamic, Flags: registered nhop と印字されています。registered は、この項目が登録によって作られたことを示します。後述する解決由来の項目（§8）とは文字列が違うので、どちらの経路で作られた項目かを出力から区別できます。

hub 側のカウンタも見ます。

snippet 
HUB# show ip nhrp traffic
Tunnel0: Max-send limit:10000Pkts/10Sec, Usage:0%
   Sent: Total 2
         0 Resolution Request  0 Resolution Reply  0 Registration Request  
         2 Registration Reply  0 Purge Request  0 Purge Reply  
         0 Error Indication  0 Traffic Indication  0 Redirect Suppress  
   Rcvd: Total 2
         0 Resolution Request  0 Resolution Reply  2 Registration Request  
         0 Registration Reply  0 Purge Request  0 Purge Reply  
         0 Error Indication  0 Traffic Indication  0 Redirect Suppress

受信が 2 Registration Request、送信が 2 Registration Reply で、いずれも合計 2 と一致します。解決に関わるカウンタはすべて 0 です。spoke 側から見た NHS の状態も対になっています。

snippet 
SPOKE1# show ip nhrp nhs detail
Legend:	E=Expecting replies, R=Responding, W=Waiting, D=Dynamic
Tunnel0:
10.99.0.1  RE  priority = 0 cluster = 0  req-sent 1  req-failed 0  repl-recv 1 (00:02:12 ago)

req-sent 1 / req-failed 0 / repl-recv 1 で、RE は凡例の E=Expecting replies, R=Responding に対応します。

show dmvpn detail の全文を hub 側で見ます。

snippet 
HUB# show dmvpn detail
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
	N - NATed, L - Local, X - No Socket
	T1 - Route Installed, T2 - Nexthop-override, B - BGP
	C - CTS Capable, I2 - Temporary
	# Ent --> Number of NHRP entries with same NBMA peer
	NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting
	UpDn Time --> Up or Down Time for a Tunnel
==========================================================================

Interface Tunnel0 is up/up, Addr. is 10.99.0.1, VRF "global" 
   Tunnel Src./Dest. addr: 203.0.113.2/Multipoint, Tunnel VRF "global"
   Protocol/Transport: "multi-GRE/IP", Protect "" 
   Interface State Control: Disabled
   nhrp event-publisher : Disabled
Type:Hub, Total NBMA Peers (v4/v6): 2

# Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb    Target Network
----- --------------- --------------- ----- -------- ----- -----------------
    1 198.51.100.2          10.99.0.2    UP 00:01:57     D       10.99.0.2/32
    1 192.0.2.2             10.99.0.3    UP 00:01:26     D       10.99.0.3/32


Crypto Session Details: 
--------------------------------------------------------------------------------

Pending DMVPN Sessions:

Type:Hub, Total NBMA Peers (v4/v6): 2 で、両方の spoke が D（Dynamic）として載っています。spoke 側は非対称です。

snippet 
SPOKE1# show dmvpn detail
…
IPv4 NHS:
10.99.0.1  RE  priority = 0 cluster = 0
Type:Spoke, Total NBMA Peers (v4/v6): 1

# Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb    Target Network
----- --------------- --------------- ----- -------- ----- -----------------
    1 203.0.113.2           10.99.0.1    UP 00:01:53     S       10.99.0.1/32
…

Type:Spoke, Total NBMA Peers (v4/v6): 1 で、その 1 本の Attrb は S（Static）です。この行は ip nhrp map 10.99.0.1 203.0.113.2 として設定に書いた静的な対応づけで、問い合わせて得たものではありません。hub 側は登録によって集まり、spoke 側は設定に書いたものしか持たないという非対称が、Phase 1 の時点で既に出力に現れています。

6. Phase 1 の経路と、Split Horizon の評価の反転

mGRE のインタフェースは 1 枚で複数の相手を収容します。EIGRP の隣接も、その 1 枚の上に複数立ちます。

snippet 
HUB# show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(100)
H   Address                 Interface              Hold Uptime   SRTT   RTO  Q  Seq
                                                   (sec)         (ms)       Cnt Num
1   10.99.0.3               Tu0                      12 00:00:52    6  1362  0  4
0   10.99.0.2               Tu0                      14 00:01:08    4  1362  0  5

hub の Tu0 に隣接が 2 本あります。spoke 側は 1 本です。

snippet 
SPOKE1# show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(100)
H   Address                 Interface              Hold Uptime   SRTT   RTO  Q  Seq
                                                   (sec)         (ms)       Cnt Num
0   10.99.0.1               Tu0                      13 00:01:10   13  1398  0  6

ここで、3-3 RIP の Split Horizon で扱った規則を思い出す必要があります。Split Horizon は「ある IF から学んだ経路は、同じ IF からは広告しない」という規則で、距離ベクトル型のループ防止策として 3-3 では一貫して善として扱いました。

ところが mGRE の上では、この規則が spoke どうしの経路を消します。hub は SPOKE1 の LAN を Tunnel0 から学び、SPOKE2 へ広告しなければなりませんが、その出口も同じ Tunnel0 だからです。Cisco の設定例は、この理由を config のコメントとして自分で書いています。

! Turns off split horizon on the mGRE tunnel interface; otherwise, EIGRP will not advertise routes that are learned via the mGRE interface back out that interface.

3-3 で守るべき規則として学んだものが、ここでは切らなければならない規則になります。規則そのものは変わっていません。Split Horizon は対向が 1 台であることを前提とする規則ではなく、複数のルータがぶら下がる共有セグメントにも同じように適用されます。変わったのは構成のほうです。3-3 の三角構成では隣どうしが別々の IF に居たので、「同じ IF から広告し返さない」が必要な広告を止めることはありませんでした。mGRE では全拠点が 1 本の Tunnel0 に集まるため、hub が SPOKE1 から学んだ経路を SPOKE2 へ渡す動作そのものが、同じ IF への再広告に当たってしまいます。本ラボは Phase 1 の時点から hub の Tunnel0 に no ip split-horizon eigrp 100 を入れてあります（§2 の hub の config を参照）。外した状態がどうなるかは本ラボでは測っていません（§15）。

この状態で spoke が受け取る経路を見ます。

snippet 
SPOKE1# show ip route eigrp
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, m - OMP
       n - NAT, Ni - NAT inside, No - NAT outside, Nd - NAT DIA
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       H - NHRP, G - NHRP registered, g - NHRP registration summary
       o - ODR, P - periodic downloaded static route, l - LISP
       a - application route
       + - replicated route, % - next hop override, p - overrides from PfR
       & - replicated local route overrides by connected

Gateway of last resort is 198.51.100.1 to network 0.0.0.0

D     192.168.10.0/24 [90/27008000] via 10.99.0.1, 00:01:14, Tunnel0
D     192.168.12.0/24 [90/28160256] via 10.99.0.1, 00:00:57, Tunnel0

hub の LAN（192.168.10.0/24）も対向拠点の LAN（192.168.12.0/24）も、どちらも via 10.99.0.1、つまり hub を next-hop としています。詳細はこうです。

snippet 
SPOKE1# show ip route 192.168.12.0
Routing entry for 192.168.12.0/24
  Known via "eigrp 100", distance 90, metric 28160256, precedence routine (0), type internal
  Redistributing via eigrp 100
  Last update from 10.99.0.1 on Tunnel0, 00:00:59 ago
  Routing Descriptor Blocks:
  * 10.99.0.1, from 10.99.0.1, 00:00:59 ago, via Tunnel0
      Route metric is 28160256, traffic share count is 1
      Total delay is 100010 microseconds, minimum bandwidth is 100 Kbit
      Reliability 255/255, minimum MTU 1400 bytes
      Loading 2/255, Hops 2

* 10.99.0.1, from 10.99.0.1 で、学んだ相手も next-hop も hub です。メトリックの 28160256 は、同じ出力が印字している Total delay is 100010 microseconds, minimum bandwidth is 100 Kbit から出ています。3-4 の式（( 10^7 / min(BW) + Σ delay / 10 ) × 256）に当てはめると 256 × (10^7 / 100 + 100010 / 10) = 28160256 で一致します。帯域も遅延もトンネルの既定値のままで、本ラボは触っていません（§12 / §14）。

経路が hub を指しているのですから、通信も hub を通ります。

snippet 
SPOKE1# ping 192.168.12.10 source 192.168.11.1 repeat 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 192.168.12.10, timeout is 2 seconds:
Packet sent with a source address of 192.168.11.1 
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 2/2/4 ms
snippet 
SPOKE1# traceroute 192.168.12.10 source 192.168.11.1 probe 1 timeout 2
Type escape sequence to abort.
Tracing the route to 192.168.12.10
VRF info: (vrf in name/id, vrf out name/id)
  1 10.99.0.1 2 msec
  2 10.99.0.3 2 msec
  3 192.168.12.10 4 msec

3 ホップで、1 番目が hub です。拠点間は疎通しますが、直接ではありません。4-8 が「スポーク間の通信は必ずハブを経由する」と書いた形が、そのまま overlay の上に現れています。

7. Phase 2 — hub が next-hop を書き換えるのをやめる

Phase 1 から Phase 2 への差分は、spoke 側の mGRE 化と、hub 側の 1 行だけです。

まず spoke の Tunnel0 から tunnel destination を外し、tunnel mode gre multipoint に切り替えます。

snippet 
SPOKE1# show running-config interface Tunnel0
Building configuration...

Current configuration : 312 bytes
!
interface Tunnel0
 ip address 10.99.0.2 255.255.255.0
 no ip redirects
 ip mtu 1400
 ip nhrp map 10.99.0.1 203.0.113.2
 ip nhrp map multicast 203.0.113.2
 ip nhrp network-id 1
 ip nhrp holdtime 300
 ip nhrp nhs 10.99.0.1
 ip tcp adjust-mss 1360
 tunnel source GigabitEthernet2
 tunnel mode gre multipoint
end

tunnel destination が消え、tunnel mode gre multipoint が入りました。もう 1 つ、ip nhrp map multicast 203.0.113.2 が増えています。これは hub の NBMA アドレスを指すマルチキャスト用の対応づけで、本ラボは mGRE 化と同時に投入しました（この行を入れなかった場合の挙動は測っていません。§15）。

hub 側の差分は次の 1 行です。

snippet 
HUB# show running-config interface Tunnel0
Building configuration...

Current configuration : 281 bytes
!
interface Tunnel0
 ip address 10.99.0.1 255.255.255.0
 no ip redirects
 ip mtu 1400
 no ip next-hop-self eigrp 100
 no ip split-horizon eigrp 100
 ip nhrp network-id 1
 ip nhrp holdtime 300
 ip tcp adjust-mss 1360
 tunnel source GigabitEthernet2
 tunnel mode gre multipoint
end

no ip next-hop-self eigrp 100 が増えています。Cisco の設定例は、この行の目的をやはり config のコメントで書いています。

! Enables dynamic, direct spoke-to-spoke tunnels when using EIGRP.

EIGRP は既定では、自分が再広告する経路の next-hop を自分自身に書き換えます。その書き換えをやめさせると、hub が SPOKE2 から学んだ経路を SPOKE1 へ渡すときに、next-hop が SPOKE2 のまま残ります。実測がこれです。

snippet 
SPOKE1# show ip route 192.168.12.0
Routing entry for 192.168.12.0/24
  Known via "eigrp 100", distance 90, metric 28160256, precedence routine (0), type internal
  Redistributing via eigrp 100
  Last update from 10.99.0.3 on Tunnel0, 00:00:15 ago
  Routing Descriptor Blocks:
  * 10.99.0.3, from 10.99.0.1, 00:00:15 ago, via Tunnel0
      Route metric is 28160256, traffic share count is 1
      Total delay is 100010 microseconds, minimum bandwidth is 100 Kbit
      Reliability 255/255, minimum MTU 1400 bytes
      Loading 2/255, Hops 2

Routing Descriptor Blocks の行が * 10.99.0.3, from 10.99.0.1 になっています。hub から学んだ経路（from 10.99.0.1）でありながら、指している先は対向の spoke（10.99.0.3）です。§6 の同じコマンドの出力と比べると、アドレスが変わったのは Last update from の行と * で始まる行の 2 か所で、メトリックは 28160256 のまま変わっていません。

hub の側では、両方の spoke が dynamic として載った状態が続いています。

snippet 
HUB# show dmvpn detail
…
Type:Hub, Total NBMA Peers (v4/v6): 2

# Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb    Target Network
----- --------------- --------------- ----- -------- ----- -----------------
    1 198.51.100.2          10.99.0.2    UP 00:04:01     D       10.99.0.2/32
    1 192.0.2.2             10.99.0.3    UP 00:03:30     D       10.99.0.3/32
…

ここまでで「SPOKE1 は 10.99.0.3 へ送れと言われている」状態ができました。ところが SPOKE1 は、10.99.0.3 がどの実アドレスに居るかをまだ知りません。次の §8 が、その食い違いが解消される瞬間になります。

ここは 2 つの主張に分けて読む必要があります。

経路表の next-hop が変わったことは、hub 側の 1 行に帰属させられます。EIGRP が広告する経路の next-hop を書き換えるかどうかを決めるのは hub の no ip next-hop-self eigrp 100 だけで、spoke 側の mGRE 化はこの広告の中身に関与しません。§6 で見た no ip split-horizon eigrp 100 は Phase 1 から既に入っており、2 つを混同すると Phase の切り分けを誤ります。

一方、spoke どうしの直接トンネルが立ったことは、この 1 行だけに帰属させられません。この Phase では spoke の mGRE 化と hub の next-hop-self 解除を同時に投入しており、2 つの設定が同時に変わっています。片方だけを変えた対照（spoke を mGRE にしたまま next-hop-self を戻す、など）を組んでいないためです（§15）。§10 の Phase 2 から Phase 3 への変更にも同じ交絡があります。

8. 問い合わせて解決する瞬間

この図を大きく開く ↗

Phase 2 の登録と解決。起動時に登録しておき、端末の通信が起きてから相手の実アドレスを問い合わせて直接トンネルを立てます。

通信を流す前の SPOKE1 を撮ります。

snippet 
SPOKE1# show dmvpn detail
…
IPv4 NHS:
10.99.0.1  RE  priority = 0 cluster = 0
Type:Spoke, Total NBMA Peers (v4/v6): 1

# Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb    Target Network
----- --------------- --------------- ----- -------- ----- -----------------
    1 203.0.113.2           10.99.0.1    UP 00:00:50     S       10.99.0.1/32
…

peer は hub の 1 本だけです。カウンタも見ます。

snippet 
SPOKE1# show ip nhrp traffic
Tunnel0: Max-send limit:10000Pkts/10Sec, Usage:0%
   Sent: Total 3
         0 Resolution Request  0 Resolution Reply  3 Registration Request  
         0 Registration Reply  0 Purge Request  0 Purge Reply  
         0 Error Indication  0 Traffic Indication  0 Redirect Suppress  
   Rcvd: Total 3
         0 Resolution Request  0 Resolution Reply  0 Registration Request  
         3 Registration Reply  0 Purge Request  0 Purge Reply  
         0 Error Indication  0 Traffic Indication  0 Redirect Suppress

送信の合計 3 はすべて Registration Request、受信の合計 3 はすべて Registration Reply で、Resolution Request も Resolution Reply も 0 です。登録は済んでいるが、解決はまだ 1 度も起きていない状態になります。

ここで端末どうしの通信を流します。

snippet 
SPOKE1# ping 192.168.12.10 source 192.168.11.1 repeat 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 192.168.12.10, timeout is 2 seconds:
Packet sent with a source address of 192.168.11.1 
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 2/2/5 ms

直後の SPOKE1 です。

snippet 
SPOKE1# show dmvpn detail
…
IPv4 NHS:
10.99.0.1  RE  priority = 0 cluster = 0
Type:Spoke, Total NBMA Peers (v4/v6): 2

# Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb    Target Network
----- --------------- --------------- ----- -------- ----- -----------------
    1 203.0.113.2           10.99.0.1    UP 00:01:03     S       10.99.0.1/32
    1 192.0.2.2             10.99.0.3    UP 00:00:08     D       10.99.0.3/32
…

peer が 2 本になり、増えた行の Attrb は D です。静的に書いた hub の行が S のまま残り、その下に問い合わせて得た 192.0.2.2 / 10.99.0.3 の行が加わっています。キャッシュの側も見ます。

snippet 
SPOKE1# show ip nhrp
10.99.0.1/32 via 10.99.0.1
   Tunnel0 created 00:01:08, never expire 
   Type: static, Flags: used 
   NBMA address: 203.0.113.2 
10.99.0.3/32 via 10.99.0.3
   Tunnel0 created 00:00:12, expire 00:04:47
   Type: dynamic, Flags: router nhop 
   NBMA address: 192.0.2.2

hub を指す 10.99.0.1/32 は Type: static, Flags: used で never expire、対向 spoke を指す 10.99.0.3/32 は Type: dynamic, Flags: router nhop で寿命が付いています。§5 の hub 側の項目が registered nhop だったのに対し、こちらは router nhop です。同じ dynamic でも、登録で作られた項目と解決で作られた項目は文字列で区別できます。

カウンタを見ると、往復が 1 回だけ起きたことが分かります。

snippet 
SPOKE1# show ip nhrp traffic
Tunnel0: Max-send limit:10000Pkts/10Sec, Usage:0%
   Sent: Total 4
         1 Resolution Request  0 Resolution Reply  3 Registration Request  
         0 Registration Reply  0 Purge Request  0 Purge Reply  
         0 Error Indication  0 Traffic Indication  0 Redirect Suppress  
   Rcvd: Total 4
         0 Resolution Request  1 Resolution Reply  0 Registration Request  
         3 Registration Reply  0 Purge Request  0 Purge Reply  
         0 Error Indication  0 Traffic Indication  0 Redirect Suppress

送信の 1 Resolution Request と受信の 1 Resolution Reply が増え、合計は 3 から 4 になりました。この宛先に対する解決は 1 往復で済んでいます。

ここで数え方に注意が要ります。 上に貼った 10 発の ping は、解決を起こしたパケットではありません。本ラボの取得スクリプトは、まず記事に出していない 3 発の ping を打ち、show dmvpn に対向 spoke の行が現れるまで待ってから、掲載用の 10 発を撮っています。実際 show dmvpn detail の対向 spoke の行は UP 00:00:08 と出ており、10 発を撮った時点で peer は 8 秒前から立っていました。つまり掲載した 10 発は近道が立った後の疎通確認で、解決の引き金になったのは出していない 3 発のほうです。カウンタの増分が数えているのも、その 3 発を含む区間になります。引き金になったパケットそのものは切り分けていません（§15）。

誰が応答を返したかについては、同じ取得の SPOKE2 側に手がかりがあります。上の show dmvpn detail を SPOKE2 でも撮っており、そこには自分自身を指す行が DLX という属性で並んでいます。この L は Local で、Cisco の資料が意味を定義しています。

These entries are created when this router answers an NHRP resolution request with this information and is used to store the tunnel IP address of all of the other NHRP nodes to which it has sent this information.

つまり SPOKE2 側に「自分が解決要求に答えた」ことを示す項目が作られています。Cisco の Phase 3 構成例も、宛先を収容する側の spoke が応答を組み立てて要求元へ送ると書いています。

Spoke 2 is the exit point and it generates the resolution reply for 192.168.18.10, prefix /24 Spoke 2 inserts the NHRP cache entry for 10.0.1.11 (Spoke 1) using information from NHRP resolution request.

撮れていないのは、要求が hub をどう転送されたかのほうです（§15）。応答を返した装置については、上の Local の項目が正の逐語になります。

対向の SPOKE2 も同じ時刻に撮りました。件数が違います。

snippet 
SPOKE2# show dmvpn detail
…
IPv4 NHS:
10.99.0.1  RE  priority = 0 cluster = 0
Type:Spoke, Total NBMA Peers (v4/v6): 3

# Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb    Target Network
----- --------------- --------------- ----- -------- ----- -----------------
    1 203.0.113.2           10.99.0.1    UP 00:00:50     S       10.99.0.1/32
    1 198.51.100.2          10.99.0.2    UP 00:00:10     D       10.99.0.2/32
    1 192.0.2.2             10.99.0.3    UP 00:00:10   DLX       10.99.0.3/32
…

Total NBMA Peers (v4/v6): 3 で、3 行目の Attrb は DLX です。凡例によれば D は Dynamic、L は Local、X は No Socket で、この行の Peer Tunnel Add は 10.99.0.3、つまり SPOKE2 自身を指しています。「spoke の peer は 2 本になる」と一般化すると誤りになります。何本になるかは、その機体がどの役回りで解決に関わったかで変わります。

9. overlay と underlay は別の経路

直接トンネルが立ったあと、同じ時刻に 2 本の traceroute を撮りました。1 本目は overlay 側、つまり拠点 LAN 宛です。

snippet 
SPOKE1# traceroute 192.168.12.10 source 192.168.11.1 probe 1 timeout 2
Type escape sequence to abort.
Tracing the route to 192.168.12.10
VRF info: (vrf in name/id, vrf out name/id)
  1 10.99.0.3 2 msec
  2 192.168.12.10 4 msec

2 ホップで、hub の 10.99.0.1 は現れません。2 本目は underlay 側、つまり対向 spoke の NBMA アドレス宛です。

snippet 
SPOKE1# traceroute 192.0.2.2 probe 1 timeout 2
Type escape sequence to abort.
Tracing the route to 192.0.2.2
VRF info: (vrf in name/id, vrf out name/id)
  1 198.51.100.1 2 msec
  2 192.0.2.2 38 msec

こちらは ISP の 198.51.100.1 を通っています。同じ 2 台のあいだの通信でありながら、通る経路が違います。overlay の 1 ホップは、underlay では ISP を挟んだ 2 ホップです。§4 で見たとおり ISP は 192.168. の経路を 1 件も持っていないので、overlay 側の traceroute に現れたホップは ISP が転送したものではなく、トンネルの内側で数えられたホップになります。

トンネルの本数が「必要になったときだけ」増えるのは、この overlay の側の話です。underlay のケーブルは Phase 1 のときから 3 本のまま変わっていません。

10. Phase 3 — 集約しか配らず、hub が教える

この図を大きく開く ↗

Phase 3 の redirect と近道。hub は集約だけを配り、通信を見て Traffic Indication を返し、spoke は近道を経路表に足します。

Phase 2 には前提があります。spoke の経路の next-hop が対向 spoke になっていること、つまり拠点の数だけ個別の経路を配ることです。拠点が増えると spoke の経路表も増えます。Cisco の NHRP の資料は、Phase 3 がこの前提を外すものだと書いています。

The spokes no longer need to have an individual route with an IP next hop of the tunnel IP address of the remote spoke for the networks behind all the other spokes.

The spoke can use summarized routes with an IP next hop of the tunnel IP address of the hub and still be able to build spoke-to-spoke tunnels.

Phase 2 から Phase 3 への差分は、hub 側の 2 行です。

snippet 
HUB# show running-config interface Tunnel0
Building configuration...

Current configuration : 353 bytes
!
interface Tunnel0
 ip address 10.99.0.1 255.255.255.0
 no ip redirects
 ip mtu 1400
 no ip next-hop-self eigrp 100
 no ip split-horizon eigrp 100
 ip nhrp network-id 1
 ip nhrp holdtime 300
 ip nhrp redirect
 ip summary-address eigrp 100 192.168.0.0 255.255.0.0
 ip tcp adjust-mss 1360
 tunnel source GigabitEthernet2
 tunnel mode gre multipoint
end

ip nhrp redirect と ip summary-address eigrp 100 192.168.0.0 255.255.0.0 が増えています。spoke 側には ip nhrp shortcut を投入しましたが、running-config は 1 行も変わりませんでした。

snippet 
SPOKE1# show running-config interface Tunnel0
Building configuration...

Current configuration : 312 bytes
!
interface Tunnel0
 ip address 10.99.0.2 255.255.255.0
 no ip redirects
 ip mtu 1400
 ip nhrp map 10.99.0.1 203.0.113.2
 ip nhrp map multicast 203.0.113.2
 ip nhrp network-id 1
 ip nhrp holdtime 300
 ip nhrp nhs 10.99.0.1
 ip tcp adjust-mss 1360
 tunnel source GigabitEthernet2
 tunnel mode gre multipoint
end

Current configuration : 312 bytes は Phase 2 の spoke の出力と同じ値で、行も同じです。既定値まで表示させると、理由が見えます。

snippet 
SPOKE1# show running-config all | section interface Tunnel0
…
 ip nhrp cache non-authoritative
 ip nhrp shortcut
 ip nhrp path preference 255
…

これは Phase 2 の時点の spoke の出力です。ip nhrp shortcut が既に入っています。同じラボの Phase 1 の時点では、まだ p2p GRE だった同じ spoke はこうでした。

snippet 
SPOKE1# show running-config all | section interface Tunnel0
…
 ip nhrp cache non-authoritative
 no ip nhrp shortcut
 ip nhrp path preference 255
…

no ip nhrp shortcut です。そして hub は一度も投入していないのに、Phase 1 の時点から ip nhrp shortcut を持っています。

snippet 
HUB# show running-config all | section interface Tunnel0
…
 ip nhrp cache non-authoritative
 ip nhrp shortcut
 ip nhrp path preference 255
…

Cisco の資料は、この挙動を既定値の決まり方として書いています。

enabled or disabled by default according to whether or not the interface is multipoint or p2p

したがって Phase 2 と Phase 3 を分けているのは、spoke の ip nhrp shortcut ではありません。spoke が mGRE になった Phase 2 の時点で、shortcut は既に有効でした。Phase 3 を成立させているのは hub 側の ip nhrp redirect です。同じ資料は Phase 3 を次のように定義しており、集約には触れていません。

Routers in a Dynamic Multipoint VPN (DMVPN) Phase 3 network use Next Hop Resolution Protocol (NHRP) Shortcut Switching to discover shorter paths to a destination network after receiving an NHRP redirect message from the hub.

では集約は何のために入れるのか（本ラボが入れている理由）。集約は、近道を NHRP の経路として経路表に載せる形（§11 の T1）を成り立たせる条件です。資料は集約を「covering prefix」と呼び、NHRP 経路の存在がそれに支配されると書いています。

The summary route, or “covering prefix”, governs the existence of the NHRP route in the RIB.

If the summary route is absent, NHRP cannot discover a shortcut path.

この一文は、hub が集約を配る設計を前提にした段落の中にあります。同じ資料は別の項で、同一のプレフィックスの経路が既に経路表にある場合について、NHRP が経路を作るのではなくnext-hop を上書きする別の道を定義しています（§11 の T2）。つまり「集約が無ければ近道は一切できない」と読める一文ですが、射程は「NHRP の経路として経路表に載る形」に限られます。

では集約を外すとどうなるか。本ラボは測っていません。 本ラボに在る構成は「redirect 無し・集約無し」（Phase 2）と「redirect 有り・集約有り」（Phase 3）の 2 つで、両者は 2 つの設定が同時に変わっています。片方だけを変えた構成、つまり「redirect 有り・集約無し」は一度も組んでいないので、集約だけを外したときに何が起きるかはこのラボからは言えません（§15）。

言えるのは、Phase 2 では Traffic Indication が送受信とも 0 のまま spoke どうしが直接つながった、という事実までです（§8）。ただしその Phase 2 には ip nhrp redirect 自体が入っていないので、この 0 を「集約が無いから」と読むことはできません。redirect が無いことだけでも 0 は説明がつきます。

要求が何を尋ねているかも、出典に当たると分かります。Cisco の Phase 3 構成例は、redirect を受けた spoke が出す要求を次のように書いています。

Spoke 1 sends NHRP resolution request for 192.168.18.10/32 to Hub 1 over the existing spoke to the regional hub1 tunnel.

尋ねているのは宛先ホストのアドレスで、プレフィックス単位の項目は応答から得た結果です。本ラボはパケットを撮っていないので、この点は出典に依っています（§15）。

したがって「集約を外しても redirect が働く」とは言えません。§11 で触れる T2（next-hop override）を見るには、hub の next-hop 書き換えを戻して個別経路の next-hop を hub に向け、そのうえで redirect を効かせる構成が要ります。本ラボはその構成を組んでいないので、T2 は一度も観測していません（§15）。

集約を入れ、セッションとキャッシュを消したあとの spoke の経路を見ます。

snippet 
SPOKE1# show ip route eigrp
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, m - OMP
       n - NAT, Ni - NAT inside, No - NAT outside, Nd - NAT DIA
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       H - NHRP, G - NHRP registered, g - NHRP registration summary
       o - ODR, P - periodic downloaded static route, l - LISP
       a - application route
       + - replicated route, % - next hop override, p - overrides from PfR
       & - replicated local route overrides by connected

Gateway of last resort is 198.51.100.1 to network 0.0.0.0

D     192.168.0.0/16 [90/27008000] via 10.99.0.1, 00:00:24, Tunnel0

EIGRP が配る経路は 192.168.0.0/16 の 1 本だけになりました。個別の 192.168.12.0/24 は消えています。近道を作り直させるため、この 2 つの出力はどちらもセッションとキャッシュを消したあとに撮っています（取得スクリプトは clear dmvpn session と clear ip nhrp を先に打ってから、この節の出力をまとめて撮ります）。

snippet 
SPOKE1# show dmvpn detail
…
IPv4 NHS:
10.99.0.1  RE  priority = 0 cluster = 0
Type:Spoke, Total NBMA Peers (v4/v6): 1

# Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb    Target Network
----- --------------- --------------- ----- -------- ----- -----------------
    1 203.0.113.2           10.99.0.1    UP 00:03:53     S       10.99.0.1/32
…

peer は hub の 1 本に戻っています。この状態で通信を流します。

snippet 
SPOKE1# ping 192.168.12.10 source 192.168.11.1 repeat 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 192.168.12.10, timeout is 2 seconds:
Packet sent with a source address of 192.168.11.1 
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 2/2/3 ms

カウンタを見ます。

snippet 
SPOKE1# show ip nhrp traffic
Tunnel0: Max-send limit:10000Pkts/10Sec, Usage:0%
   Sent: Total 8
         2 Resolution Request  1 Resolution Reply  5 Registration Request  
         0 Registration Reply  0 Purge Request  0 Purge Reply  
         0 Error Indication  0 Traffic Indication  0 Redirect Suppress  
   Rcvd: Total 9
         1 Resolution Request  2 Resolution Reply  0 Registration Request  
         5 Registration Reply  0 Purge Request  0 Purge Reply  
         0 Error Indication  1 Traffic Indication  0 Redirect Suppress

Phase 2 の時点（送信合計 4 / 受信合計 4）と比べると、送信が +4、受信が +5 です。増えたものの中に、Phase 2 では 0 だった 1 Traffic Indication が受信側に現れています。カウンタは累積なので、値そのものではなく増分で読みます。

カウンタPhase 2 時点Phase 3 時点増分
送信合計48+4
受信合計49+5
受信 Traffic Indication01+1
送信 Resolution Request12+1
送信 Resolution Reply01+1
受信 Resolution Request01+1
受信 Resolution Reply12+1

送信・受信とも合計は内訳の和と一致します（送信 2 + 1 + 5 = 8、受信 1 + 2 + 5 + 1 = 9）。注目すべきは下の 4 行で、SPOKE1 は解決要求を出して応答を受け取ると同時に、解決要求を受け取って応答を返しています。§8 で保留した「誰が応答を返すか」について、少なくとも spoke が応答を返す側に回ることは、この増分から言えます。

Traffic Indication という名前は、Cisco が redirect と呼んでいるものの実装上の名前です。Phase 3 の構成例に、その対応が出ています。

NHRP: Send Traffic Indication via Tunnel1 vrf 0, packet size: 96

traffic code: redirect(0)

NHRP キャッシュを詳細で見ます。

snippet 
SPOKE1# show ip nhrp detail
10.99.0.1/32 via 10.99.0.1
   Tunnel0 created 00:04:04, never expire 
   Type: static, Flags: used 
   NBMA address: 203.0.113.2 
   Preference: 255
10.99.0.3/32 via 10.99.0.3
   Tunnel0 created 00:00:08, expire 00:04:51
   Type: dynamic, Flags: router nhop rib 
   NBMA address: 192.0.2.2 
   Preference: 255
192.168.12.0/24 via 10.99.0.3
   Tunnel0 created 00:00:08, expire 00:04:51
   Type: dynamic, Flags: router rib 
   NBMA address: 192.0.2.2 
   Preference: 255
192.168.11.0/24 via 10.99.0.2
   Tunnel0 created 00:00:08, expire 00:04:51
   Type: dynamic, Flags: router unique local 
   NBMA address: 198.51.100.2 
   Preference: 255
    (no-socket) 
  Requester: 10.99.0.3 Request ID: 2

4 つの項目が並んでいます。10.99.0.1/32 は設定に書いた静的な項目で、10.99.0.3/32 は router nhop rib です。192.168.12.0/24 という宛先プレフィックス単位の項目が router rib として増えています。最後の 192.168.11.0/24 は router unique local で、(no-socket) と Requester: 10.99.0.3 Request ID: 2 が付いています。この行が、SPOKE2 から SPOKE1 へ解決要求が来たことの正の逐語です。

ここから先は読み違えが起きやすいところです。経路表を見ます。

snippet 
SPOKE1# show ip route 192.168.12.0
Routing entry for 192.168.12.0/24
  Known via "nhrp", distance 250, metric 255
  Tag 1, type resolved
  Last update from 10.99.0.3 on Tunnel0, 00:00:18 ago
  Routing Descriptor Blocks:
  * 10.99.0.3, from 10.99.0.3, 00:00:18 ago, via Tunnel0
      Route metric is 255, traffic share count is 1
      Route tag 1

Known via "nhrp", distance 250 です。近道は転送表だけの話ではなく、経路表に NHRP の経路として載ります。Cisco の資料もそう書いています。

This means that shortcut paths appear as routes in the routing table and NHRP works in lieu of the routing protocol (for example, RIP, OSPF or EIGRP).

To implement shortcut switching, NHRP works as a route source and installs shortcut paths, as NHRP routes, directly into the Routing Information Base (RIB).

NHRP の経路だけを一覧にすると 2 本あります。

snippet 
SPOKE1# show ip route nhrp
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, m - OMP
       n - NAT, Ni - NAT inside, No - NAT outside, Nd - NAT DIA
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       H - NHRP, G - NHRP registered, g - NHRP registration summary
       o - ODR, P - periodic downloaded static route, l - LISP
       a - application route
       + - replicated route, % - next hop override, p - overrides from PfR
       & - replicated local route overrides by connected

Gateway of last resort is 198.51.100.1 to network 0.0.0.0

      10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
H        10.99.0.3/32 is directly connected, 00:00:20, Tunnel0
H     192.168.12.0/24 [250/255] via 10.99.0.3, 00:00:20, Tunnel0

経路表の全量も見ておきます。

snippet 
SPOKE1# show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, m - OMP
       n - NAT, Ni - NAT inside, No - NAT outside, Nd - NAT DIA
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       H - NHRP, G - NHRP registered, g - NHRP registration summary
       o - ODR, P - periodic downloaded static route, l - LISP
       a - application route
       + - replicated route, % - next hop override, p - overrides from PfR
       & - replicated local route overrides by connected

Gateway of last resort is 198.51.100.1 to network 0.0.0.0

S*    0.0.0.0/0 [1/0] via 198.51.100.1
      10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
C        10.99.0.0/24 is directly connected, Tunnel0
L        10.99.0.2/32 is directly connected, Tunnel0
H        10.99.0.3/32 is directly connected, 00:00:22, Tunnel0
D     192.168.0.0/16 [90/27008000] via 10.99.0.1, 00:00:51, Tunnel0
      192.168.11.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.11.0/24 is directly connected, GigabitEthernet3
L        192.168.11.1/32 is directly connected, GigabitEthernet3
H     192.168.12.0/24 [250/255] via 10.99.0.3, 00:00:22, Tunnel0
      198.51.100.0/24 is variably subnetted, 2 subnets, 2 masks
C        198.51.100.0/30 is directly connected, GigabitEthernet2
L        198.51.100.2/32 is directly connected, GigabitEthernet2

D 192.168.0.0/16 と H 192.168.12.0/24 が同居しています。集約は消えておらず、より長い一致である /24 が使われる形です。show ip route eigrp だけを見ると集約 1 本に見えますが、あの出力は code H の経路を落としているだけで、経路表が集約 1 本になっているわけではありません。転送表も /24 で引けます。

snippet 
SPOKE1# show ip cef 192.168.12.10
192.168.12.0/24
  nexthop 10.99.0.3 Tunnel0

traceroute も 2 ホップになりました。

snippet 
SPOKE1# traceroute 192.168.12.10 source 192.168.11.1 probe 1 timeout 2
Type escape sequence to abort.
Tracing the route to 192.168.12.10
VRF info: (vrf in name/id, vrf out name/id)
  1 10.99.0.3 3 msec
  2 192.168.12.10 2 msec

EIGRP が配る経路は集約 1 本のままなのに、通信は hub を通りません。これが Phase 3 の姿です。

なお、この NHRP 経路の寿命は単独で決まるわけではないと資料は書いています。

In summary, the validity of an NHRP route in the RIB is determined by the less specific, longest match IGP route present in the RIB.

近道を覆っている集約が消えれば、近道もその影響を受ける、という記述になります。本ラボは集約を消す操作をしていないので、この点は実測していません（§15）。

11. show dmvpn の読み方

show dmvpn detail は、凡例を機器自身が毎回印字します。Phase 3 の SPOKE1 の全文です。

snippet 
SPOKE1# show dmvpn detail
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
	N - NATed, L - Local, X - No Socket
	T1 - Route Installed, T2 - Nexthop-override, B - BGP
	C - CTS Capable, I2 - Temporary
	# Ent --> Number of NHRP entries with same NBMA peer
	NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting
	UpDn Time --> Up or Down Time for a Tunnel
==========================================================================

Interface Tunnel0 is up/up, Addr. is 10.99.0.2, VRF "global" 
   Tunnel Src./Dest. addr: 198.51.100.2/Multipoint, Tunnel VRF "global"
   Protocol/Transport: "multi-GRE/IP", Protect "" 
   Interface State Control: Disabled
   nhrp event-publisher : Disabled

IPv4 NHS:
10.99.0.1  RE  priority = 0 cluster = 0
Type:Spoke, Total NBMA Peers (v4/v6): 3

# Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb    Target Network
----- --------------- --------------- ----- -------- ----- -----------------
    1 203.0.113.2           10.99.0.1    UP 00:04:10     S       10.99.0.1/32
    2 192.0.2.2             10.99.0.3    UP 00:00:15   DT1       10.99.0.3/32
      192.0.2.2             10.99.0.3    UP 00:00:15   DT1    192.168.12.0/24
    1 198.51.100.2          10.99.0.2    UP 00:00:15   DLX    192.168.11.0/24


Crypto Session Details: 
--------------------------------------------------------------------------------

Pending DMVPN Sessions:

Attrb 列は 1 文字ずつが属性を表し、複数付くこともあります。この出力では次のように読めます。

行Attrb読み
203.0.113.2 / 10.99.0.1 / 10.99.0.1/32S設定に書いた静的な対応づけ（hub）
192.0.2.2 / 10.99.0.3 / 10.99.0.3/32DT1動的に得た対応づけで、かつ経路として入れたもの
192.0.2.2 / 10.99.0.3 / 192.168.12.0/24DT1同上。宛先プレフィックス単位の行
198.51.100.2 / 10.99.0.2 / 192.168.11.0/24DLX動的・ローカル・ソケット無し。自分自身の LAN を指す行

ここで T1 - Route Installed と T2 - Nexthop-override の分かれ目が問題になります。凡例には両方が常に印字されるので、凡例だけを見て「next-hop を上書きしている」と読むことはできません。Cisco の資料は、どちらになるかの条件を書いています。

If an NHRP route in the RIB is identical to another route (owned by another protocol) in the RIB then NHRP overrides the other protocol’s next hop entries by installing shortcut next hops in the RIB.

同一の経路が既に RIB にあるときは next-hop の上書き (T2) になります（出典が書いているのはこの向きだけで、逆に T2 が起きる条件がこれに限ると断じてはいません）。本ラボは EIGRP が /16 の集約しか配っておらず、192.168.12.0/24 と同一の経路は RIB にありませんでした。だから経路として入る側 (T1) になっています。機器自身も、この 2 つを別勘定で数えています。

snippet 
SPOKE1# show ip nhrp summary
IP NHRP cache 4 entries, 3040 bytes
    1 static   3 dynamic    0 incomplete
3 Remote
    1 static   2 dynamic    0 incomplete
    1 nhop     0 bfd
    0 default  0 temporary
    2 route
        2 rib (2 H    0 nho)
        0 bgp
    0 lfib
1 Local
    0 static   1 dynamic    0 incomplete
    0 lfib

2 rib (2 H 0 nho) です。H が 2、nho（next-hop override）が 0 で、本ラボでは T2 が 1 件も起きていません。これは本ラボの経路設計の帰結であって、T2 が起きないという一般則ではありません。集約ではなく個別の /24 を配る設計にすれば、同一経路が RIB にある状況が作れます。

なお、§10 で見た show ip route nhrp には H の経路が 2 本（10.99.0.3/32 と 192.168.12.0/24）出ています。同じ出力の NHRP キャッシュ側でも、rib フラグが立っている項目はこの 2 つ（10.99.0.3/32 と 192.168.12.0/24）で、経路表の H 2 本と 1 対 1 で対応します。

peer の件数は機体をまたいで一般化できません。§8 で貼った同じ取得（Phase 2 の同一ファイル）で、SPOKE1 は 2、SPOKE2 は 3 と出ています。spoke 側には自分を指す DLX の行や、対向からの要求で作られた router unique local の項目が混ざるためで、数そのものには意味がありません。読むべきは Attrb 列と Target Network 列の組み合わせになります。

12. GRE の overhead と MTU

トンネルのインタフェースが何を表示しているかを先に見ます。

snippet 
SPOKE1# show interfaces Tunnel0 | include line protocol|Tunnel source|Tunnel protocol|MTU|BW
Tunnel0 is up, line protocol is up 
  MTU 9976 bytes, BW 100 Kbit/sec, DLY 50000 usec, 
  Tunnel source 198.51.100.2 (GigabitEthernet2)
  Tunnel protocol/transport multi-GRE/IP
  Tunnel transport MTU 1476 bytes

この出力には 4 つの数が出ています。MTU 9976 bytes は論理インタフェースの値、Tunnel transport MTU 1476 bytes はカプセル化される前のパケットに使える大きさ、BW 100 Kbit/sec と DLY 50000 usec は §6 のメトリックの元になった既定値です。

1476 は物理インタフェースの 1500 から 24 を引いた値です。この 24 が GRE のオーバーヘッドで、Cisco の資料はそれを次のように書いています。

For example, the addition of Generic Router Encapsulation (GRE) adds 24 bytes to a packet, and after this increase, the packet needs to be fragmented because it is larger than the outbound MTU.

向きに注意が要ります。 1476 は「外側に使える大きさ」ではなく、包む前のパケットに使える大きさです。同じ資料が、1476 バイトのデータグラムを包むと外側が 1500 バイトになる、と書いています。

This router encapsulates the 1476-byte IPv4 datagram inside GRE to get a 1500-byte GRE IPv4 datagram.

なお内訳（外側 IP ヘッダ 20 バイト + GRE ヘッダ 4 バイト）は出典の定義から導けますが、本ラボはカプセル化後のパケットを撮っていないので、内訳そのものは実測していません。

本ラボの Tunnel0 には ip mtu 1400 と ip tcp adjust-mss 1360 を入れてあります。この組は Cisco の推奨に合わせたものです。

The recommended value is 1360 when the number of IP MTU bytes is set to 1400.

では実際にいくつまで通るのかを、DF ビットを立てた ping で掃引しました。

snippet 
SPOKE1# ping 192.168.12.10 source 192.168.11.1 size 1400 df-bit repeat 3
Type escape sequence to abort.
Sending 3, 1400-byte ICMP Echos to 192.168.12.10, timeout is 2 seconds:
Packet sent with a source address of 192.168.11.1 
Packet sent with the DF bit set
!!!
Success rate is 100 percent (3/3), round-trip min/avg/max = 3/4/6 ms
snippet 
SPOKE1# ping 192.168.12.10 source 192.168.11.1 size 1410 df-bit repeat 3
Type escape sequence to abort.
Sending 3, 1410-byte ICMP Echos to 192.168.12.10, timeout is 2 seconds:
Packet sent with a source address of 192.168.11.1 
Packet sent with the DF bit set
...
Success rate is 0 percent (0/3)

掃引の全体は次のとおりです。

size結果
1380Success rate is 100 percent (3/3)
1390Success rate is 100 percent (3/3)
1400Success rate is 100 percent (3/3)
1410Success rate is 0 percent (0/3)
1420Success rate is 0 percent (0/3)
1450Success rate is 0 percent (0/3)
1476Success rate is 0 percent (0/3)

確認できた最大の成功サイズは 1400 です。これは ip mtu 1400 として投入した設定値そのもので、GRE の overhead から引き算して出た値ではありません。1476 と同じ量（包む前の IPv4 パケットに使える大きさ）を測っていますが、1476 はそれを触らなかったときの既定値で、本ラボはそれより小さい 1400 を明示的に入れたということです。設定を入れていなければ境界は 1476 の近くに出たはずですが、本ラボはその構成を測っていません。掃引は 10 バイト刻みなので、境界は 1400 と 1410 のあいだにあり、1401 から 1409 までは測っていません。

ここで 6-5 と 6-6 の数値と並べられます。6-5 の VXLAN は overlay の上限が 1450（境界は 1450 と 1451 のあいだ）、6-6 の LISP VXLAN fabric も 1450（10 バイト刻み）でした。3 つとも DF ビットを立てた ping の掃引で測った値なので、同じ量を比べています。ただし成り立ちは違います。6-5 と 6-6 の 1450 は underlay の 1500 からカプセル化の分を引いた結果であるのに対し、本節の 1400 は人間が ip mtu に書いた値です。この節の 1400 を「GRE の overhead は 100 バイト」と読んではいけません。

1410 が落ちる場所（送信側のトンネルインタフェースか、経路の途中か）は切り分けていません（§15）。

13. LISP との違い — 3 軸の答え合わせ

§1 で立てた 3 軸に、実測と出典で答えます。

軸LISP の map-request（6-6）NHRP の resolution-request（本節）
解決する対象EID。端末そのもののアドレスから、収容装置の RLOC を求めるNBMA アドレス。Phase 2 ではトンネルの next-hop（10.99.0.3）から、相手の実アドレス（192.0.2.2）を求める。Phase 3 で要求の対象になるのは宛先ホストのアドレスで、/24 は応答から学ぶ結果である（これは出典による。本ラボはパケットを撮っていないので要求の中身は観測していない・§15）
答えを持つ装置control plane node。map-server と map-resolver を兼ね、ETR が登録するNHS = hub。spoke が起動時に登録し、hub がデータベースを保つ。ただし本ラボの Phase 3 では spoke 自身も解決要求を受け取って応答を返していた（§10）
キャッシュの置き場所map-cache のみ。リモートの端末は経路表に載らないNHRP キャッシュに載り、本ラボの集約構成では さらに H の経路として経路表にも載る（AD 250。同一プレフィックスの経路が既に在る構成では next-hop の上書きになる・§11）

3 番目の差は、それぞれのプロトコルが経路に対して取っている立場の違いから来ています。LISP のマッピングは経路表の外側に別の表として置かれます。NHRP は経路表の中に経路を足しますが、経路プロトコルそのものではないことを Cisco は明記しています。

NHRP acts as a route producer to the RIB, but it does not function as a full routing protocol.

NHRP manages the route registration, resolution, and purge messages but it does not discover or maintain NHRP neighbors, advertise NHRP routing messages, or inform the network of any network topology changes.

経路を作って RIB に渡す役ではあるが、隣接を見つけたりトポロジの変化を触れ回ったりはしない、という位置づけです。本ラボの経路表に現れた H 192.168.12.0/24 [250/255] は、EIGRP が配ったものではなく、この「経路の生産者」が入れたものになります。

もう 1 つ、似ているようで違う点があります。6-6 の LISP では、リモートの端末の居場所を知らないうちはパケットが捨てられるか溜められるとされていました（6-6 が引いた RFC 9301 の記述で、6-6 の実機で観測したものではありません）。本ラボの Phase 3 では、近道ができるまでのあいだ集約経路に従って hub へ転送されます。経路が一度も途切れずに短くなる形になりますが、本ラボはその切り替わりの瞬間を撮っていません。掲載した 10 発の ping は近道が立った後の疎通確認で、その前の状態との対照になっていないためです（§8 / §15）。

14. 落とし穴・補足

holdtime は三重に食い違っています。本ラボは 3 台とも ip nhrp holdtime 300 を投入しており、show run と show run all の両方にその行が出ています。それでも hub の登録項目の寿命は約 600 秒でした（created 00:02:07, expire 00:07:52 で合計 599 秒。もう 1 件も 599 秒）。一方、spoke が解決で得た項目は約 300 秒です（created 00:00:12, expire 00:04:47 で 299 秒）。出典の側も一致していません。同じ 1 行が、コマンドの既定値を 600 と示しながら、散文では 6 分と書いています。600 秒は 10 分です。

ip|ipv6 nhrp holdtime 600—default hold time is 6 mins and registrations are sent every 2 mins

登録の送出間隔を決める ip nhrp registration timeout は 100 秒でした（show running-config all | section interface Tunnel0 の全量に出ています）。これは本ラボが入れた ip nhrp holdtime 300 の 1/3 にあたります。同じ出力の IPv6 側が ipv6 nhrp holdtime 600 に対して ipv6 nhrp registration timeout 200 になっていることも、この値が holdtime から導かれていることを示しています。出典も登録間隔を「holdtime の 1/3、または ip nhrp registration timeout の値」と書いています。

どの値がどちらの寿命を決めているかは本ラボでは確定していません。「holdtime 300 なので 5 分で失効する」とは書けません。

なお、この値を撮るときに出力フィルタの落とし穴を踏みました。… | section interface Tunnel0 | include nhrp holdtime|nhrp registration という形で撮ったところ、registration の行だけが返り、設定されている holdtime の行が落ちました。パイプと | が入り混じった式をどう解釈した結果なのかは本ラボでは確かめていませんが、結果として設定されているのに「設定されていない」ように見える出力が手に入ります。フィルタ済みの出力を「そこに無い」の根拠にはできません。全量を撮って読むのが確実です。

show run は既定値と同じ行を出しません。Cisco はこれを NHRP Smart Default の仕様として書いています。

The default values do not display when you use the show run command but are displayed when you use show run all command. However, user configured values override default values.

ところが本ラボでは、明示投入したのに show run に出ない行がありました。hub には ip nhrp map multicast dynamic を投入していますが、show running-config interface Tunnel0（§2）には出ず、show running-config all | section interface Tunnel0 にだけ出ます。この行は 16.3 以降は既定で有効だと同じ資料が書いています。

Effective with Cisco IOS XE Denali 16.3 ip nhrp map multicast dynamic is enabled by default.

既定値と一致する行は、明示投入しても show run に現れない、と読むのが本ラボの観測に合います。ip nhrp map / ip nhrp network-id / ip nhrp holdtime / ip nhrp nhs のように既定値と違う値を書いたものは show run に出ています。

既定値込みで見るコマンドの形に注意してください。本ラボで使えたのは show running-config all | section interface Tunnel0 の形です。show running-config all interface Tunnel0 と続けて書く形は手元の機体では通りませんでしたが、そのときの機器の応答は本節が根拠とする 23 ファイルには含まれていません（別の実行で撮ったものです）。ここは形の申し送りとして読んでください。

ip split-horizon と ip split-horizon eigrp 100 は別のノブです。hub の show run all には no ip split-horizon eigrp 100 と ip split-horizon が両方印字されています。前者が EIGRP 用、後者が距離ベクトル型の一般のものです。片方だけを見て「切れている」「切れていない」と判断できません。

投入していない no ip redirects が mGRE のインタフェースに現れます。hub は Phase 1 から、spoke は mGRE になった Phase 2 から no ip redirects を持っています。p2p GRE だった Phase 1 の spoke は ip redirects でした。本ラボはこの行を一度も投入していないので、mGRE 化に伴って現れたことは分かりますが、その機序は確かめていません。

show ip route eigrp だけでは Phase 3 を語れません。あの出力は code H の経路を落とします。§10 で見たとおり、show ip route の全量や show ip route nhrp を併せて見ないと、近道が経路表に載っていることが見えません。

集約に 0.0.0.0/0 を使う設計は本ラボでは採りませんでした。spoke には underlay 用の静的既定経路（AD 1）が入っており、EIGRP の既定経路（AD 90）はそれに負けます。本ラボは拠点 LAN をまとめた 192.168.0.0/16 を選びました。0.0.0.0/0 を投入した場合にどう見えるかは試していません。

トンネルの bandwidth は資料と実測で値が違います。Cisco は既定値を 9 kbps と書き、EIGRP を併用するなら 1000 以上が critical だと書いています。

The kbps argument specifies the bandwidth in kilobits per second. The default value is 9. The recommended bandwidth value is 1000 or greater.

Setting the bandwidth value to at least 1000 is critical if EIGRP is used over the tunnel interface. Higher bandwidth values may be necessary depending on the number of spokes supported by a hub.

本ラボの csr1000v 17.03.08a が印字したのは BW 100 Kbit/sec でした（§12）。どちらが正しいかではなく、資料の書く既定値と手元の機体の既定値が違う、という事実だけを記録します。本ラボは bandwidth も delay も触っていないので、推奨値に合わせた場合の挙動は測っていません。

csr1000v 17.03.08a は CDP が既定で無効です（show cdp neighbors が % CDP is not enabled を返します）。この点は §1 の 23 ファイルの外で、本ラボを建てる前に同じイメージで回した事前検証ラボの記録です。配線照合に CDP を使うなら cdp run が要ります。§4 の CDP 出力は、この設定を入れたうえで撮ったものです。

15. 本ラボで確かめていないこと

本節の実測は 23 ファイルに収まる範囲です。以下は観測していません。

  • NHRP のパケットそのもの。パケットキャプチャを取っていないため、撮れているのはカウンタとキャッシュと経路表だけです。登録も解決も redirect も、前後の状態と増分から読んでいます。
  • 解決要求が hub をどう転送されたか。要求を出したのが SPOKE1 であること、応答が 1 通返ったこと、そして応答を返した側に Local の項目が作られたこと（§8）は撮れています。撮れていないのは、その要求が hub をどう経由して対向 spoke へ渡ったかの部分です。
  • IPsec で保護した DMVPN。本節は平文の mGRE です。tunnel protection ipsec profile は投入していません。暗号側は 4-8 が扱っています。
  • no ip split-horizon eigrp 100 を外した状態。Phase 1 の時点から入れてあるため、外すと spoke 間の経路がどう見えるかは測っていません。
  • spoke の ip nhrp map multicast を入れない状態。mGRE 化と同時に投入したので、この行が無いと EIGRP の隣接がどうなるかは測っていません。
  • 集約を消したときの近道の寿命。§10 で引いた「NHRP 経路の有効性は、それを覆う IGP 経路で決まる」という記述は確かめていません。
  • nho（next-hop override）が立つ構成。本ラボは集約しか配っていないので nho は 0 のままでした。同一プレフィックスの経路が既に RIB にある構成は組んでいません（§11）。
  • 1410 バイトが落ちる場所。DF ビット付きで 0 パーセントになることは撮れていますが、送信側で落ちているのか経路の途中なのかは切り分けていません。1401 から 1409 バイトも測っていません。
  • dual-hub と 3 拠点を超える規模。ノードを増やしていません。冗長設計とスケール上限は本ラボの射程外です。
  • NAT の内側に spoke を置く構成。NAT を置いていません。
  • トンネルの bandwidth と delay のチューニング。既定のまま（BW 100 Kbit/sec / DLY 50000 usec）です。
  • マルチキャストの配信と PIM。EIGRP の制御通信以外のマルチキャスト配信や PIM は検証していません。資料は IOS-XE の DMVPN で PIM dense mode が非対応であることを明記しています。

Protocol-independent mulitcast (PIM) dense mode is not supported over DMVPN on IOS-XE devices.

  • purge。前に答えた内容が変わったときに送られる purge request / reply は、撮れている範囲では発生していません（show ip nhrp traffic を撮ったのは HUB の Phase 1 と SPOKE1 の Phase 2 前後・Phase 3 の計 4 点で、SPOKE2 と Phase 2/3 の HUB は撮っていません。撮った 4 点ではカウンタはすべて 0 のままです）。
  • per-tunnel QoS と FVRF。どちらも設定していません。
  • 解決や redirect の引き金になったパケットそのもの。本ラボの取得スクリプトは、掲載用の ping を撮る前に、記事に出していない 3 発の ping を打ち、peer や近道が立つまで待ってから撮っています。したがって掲載した出力はすべて成立後の状態で、「まだ立っていない状態」から「立った状態」への切り替わりの瞬間は撮っていません（§8 / §13）。前後の対として撮れているのは、clear の直後と transit の後という粗い 2 点だけです。
  • redirect を入れたまま集約だけを外した構成。本ラボに在るのは「redirect 無し・集約無し」（Phase 2）と「redirect 有り・集約有り」（Phase 3）の 2 つで、2 つの設定が同時に変わっています。片方だけを変えた対照を組んでいないため、集約の有無そのものの効果は切り分けられません（§10）。
  • spoke どうしの直接トンネルが立った寄与の切り分け。Phase 1 から Phase 2 への変更では、spoke の mGRE 化と hub の no ip next-hop-self eigrp 100 を同時に投入しています。片方だけを変えた対照を組んでいないため、直接トンネルが立ったことをどちらの設定に帰属させるかは決められません（§7。なお経路表の next-hop が変わったことは hub 側の 1 行に帰属します）。
  • 解決要求の中身。要求が宛先ホストのアドレスを尋ねていることは出典によります。本ラボはパケットを撮っていないので、要求の中身そのものは観測していません（§10 / §13）。
  • T2（next-hop override）の形。同一のプレフィックスの経路が既に RIB に在るときに T2 になると資料は書いていますが、本ラボはその構成を組んでいないため一度も観測していません（§11）。
  • Phase 3 における HUB と SPOKE2 の show dmvpn。Phase 3 で撮ったのは SPOKE1 と HUB の一部だけで、SPOKE2 側の状態は撮っていません（§11 の件数の比較は Phase 2 の取得によるものです）。

16. 次節

本節では、mGRE が tunnel destination を書かないトンネルであり、その相手の実アドレスを NHRP が解決すること、登録は起動時に spoke から NHS へ、解決は通信が起きてから走ることを見ました。Phase 1 と Phase 2 のあいだで経路表の next-hop を変えたのは hub の no ip next-hop-self eigrp 100 であり（直接トンネルが立ったことは spoke の mGRE 化と交絡していて 1 行には帰属できない）、no ip split-horizon eigrp 100 は Phase 1 から要ること。Phase 2 と Phase 3 を分けるのは hub の ip nhrp redirect であって、spoke の ip nhrp shortcut は mGRE のインタフェースでは既定で有効だったこと。本ラボが入れた集約は、近道を T1 の形（NHRP の経路として経路表に載る形）で成り立たせるための条件であること。Phase 3 の近道は転送表だけの差し替えではなく、本ラボの集約構成では Known via "nhrp", distance 250 の経路として経路表に載ること（同一プレフィックスの経路が既に在る構成では next-hop の上書きになる）。overlay を通る最大サイズは ip mtu 1400 を入れた本ラボで 1400 であり、これは表示値 1476 と同じ量（包む前のパケットに使える大きさ）の、既定値を人間が下げた側の値であること。確かめていないことは §15 にまとめてあります。

次節 6-8 Performance Routing (PfR) では、経路の品質を測って出口を選ぶ仕組みを扱います。本節の DMVPN が決めたのは「どのトンネルを張るか」までで、そのトンネルが速いか遅いかは一度も測っていません。複数の出口があるときに、遅延やロスを見て通信ごとに出口を変える層が PfR です。6-4 SD-WAN 設計の節がアプリケーション認識ルーティングを予告として置いたまま送った話も、ここで合流します。測る対象と、測った結果をどう転送に反映するのかを見ていきましょう。

17. 出典

本節が参照した資料です。Cisco の 5 件と RFC の 3 件を 2026 年 9 月 21 日に取得しました。本文中の引用はその時点のページの逐語です。手元の機体は csr1000v 17.03.08a で、Cisco の設定ガイドは別のリリースを対象としています。

資料更新日URL
Cisco Security and VPN Configuration Guide, IOS XE 17.x — Dynamic Multipoint VPN2021-01-11https://www.cisco.com/c/en/us/td/docs/routers/ios/config/17-x/sec-vpn/b-security-vpn/m_sec-conn-dmvpn-dmvpn-0.html
Cisco IP Addressing Configuration Guide, IOS XE 17.x — Shortcut Switching Enhancements for NHRP in DMVPN Networks2022-11-15https://www.cisco.com/c/en/us/td/docs/routers/ios/config/17-x/ip-addressing/b-ip-addressing/m_nhrp-switch-enhancemts-dmvpn-0.html
Cisco IP Multicast Configuration Guide, IOS XE 17.x — Dynamic Multipoint VPN2022-03-11https://www.cisco.com/c/en/us/td/docs/routers/ios/config/17-x/ip-multicast/b-ip-multicast/m_sec-conn-dmvpn-dmvpn-0.html
Cisco — Configure Phase-3 Hierarchical DMVPN2017-05-30https://www.cisco.com/c/en/us/support/docs/security/dynamic-multipoint-vpn-dmvpn/211292-Configure-Phase-3-Hierarchical-DMVPN-wit.html
Cisco — Resolve IPv4 Fragmentation, MTU, MSS, and PMTUD Issues with GRE and IPsec2024-06-19https://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag.html
RFC 2332 — NBMA Next Hop Resolution Protocol (NHRP)—https://www.rfc-editor.org/rfc/rfc2332.txt
RFC 2784 — Generic Routing Encapsulation (GRE)—https://www.rfc-editor.org/rfc/rfc2784.txt
RFC 1702 — Generic Routing Encapsulation over IPv4 networks—https://www.rfc-editor.org/rfc/rfc1702.txt