前言
DMVPN（Dynamic Multipoint VPN）是 Cisco 经典的动态多点 VPN 方案，大多数资料都以 IPv4 作为底层承载网络。本文记录一次完全基于 IPv6 公网地址、并通过域名动态解析来组建 DMVPN 的实验过程。相比传统 IPv4 方案，该设计省去了 NAT 穿越的困扰，且域名解析机制让 Spoke 无需硬编码 Hub 的 IPv6 地址，配置更灵活。
实验的 IKE 版本选用 IKEv2，加密套件使用 AES-GCM-256，密钥交换采用 DH Group 19（ECP-256）。
实验拓扑
+----------+
| Hub |
| C8000V |
| .254 | Tunnel200: 172.16.200.0/24
+----+-----+
|
IPv6 Internet | GRE over IPv6 (mGRE)
|
+------------+------------+
| |
+----+-----+ +----+-----+
| Spoke1 | | Spoke2 |
| C8000V | | C8000V |
| .1 | | .2 |
+----------+ +----------+
Hub IPv6: 240E:3AF:872:94B0:BE24:11FF:FE6A:40BD (nj-home.wuhao.net.cn)
Spoke1 IPv6: 240E:3A1:620:80A3:250:56FF:FE91:FF24
Spoke2 IPv6: 2408:823C:8B8D:CE4:BE24:11FF:FEC8:1064
OSPF Area 0 在 Tunnel 接口上运行，实现路由动态学习
Hub Loopback2: 10.255.1.1/32 (Router-ID: 10.255.0.1)
Spoke1 Loopback2: 2.2.2.2/32 (Router-ID: 10.255.0.2)
Spoke2 Loopback2: 3.3.3.3/32 (Router-ID: 10.255.0.3)
设备信息：
核心设计要点
1. IPv6 作为底层承载（Underlay）
传统的 DMVPN 使用 IPv4 公网地址作为 NBMA 地址。本实验全部三台路由器的公网接口（GigabitEthernet1）均通过 SLAAC 获取 IPv6 全球单播地址，GRE 隧道封装在 IPv6 之上：
interface Tunnel200
tunnel mode gre multipoint ipv6 # 关键：mGRE over IPv6
tunnel source GigabitEthernet1 # 源接口通过 SLAAC 获取 IPv6
IKEv2 和 IPsec 的通信对端也都是 IPv6 地址，所有 ISAKMP 和 ESP 报文封装在 IPv6 中传输。
2. 域名方式发现 Hub（NHS）
这是本实验最特别的设计。传统 DMVPN 中，Spoke 的 NHS 配置通常是硬编码的 IPv4/IPv6 地址：
! 传统方式
ip nhrp nhs 240E:3AF:872:94B0:BE24:11FF:FE6A:40BD
而本实验中，Spoke 通过域名指定 NHS，由路由器在运行时做 DNS 解析：
! Spoke1 和 Spoke2 上的配置
ip host nj-home.wuhao.net.cn 240E:3AF:872:94B0:BE24:11FF:FE6A:40BD
!
interface Tunnel200
ip nhrp nhs dynamic nbma nj-home.wuhao.net.cn multicast
dynamic nbma 关键字表示 NBMA 地址通过 DNS 动态解析获得。这意味着如果 Hub 的 IPv6 地址发生变更，只需更新 DNS 记录（以及路由器上的静态 host 映射），无需修改 NHRP 配置本身。在多 Hub 场景下，还可以结合 DNS 轮询实现负载分担。
3. Hub 作为 NHRP 服务器和 OSPF DR
Hub 的特殊配置：
interface Tunnel200
ip nhrp server-only # 仅作为服务器，不学习其他 NHS
ip nhrp redirect # 启用 NHRP 重定向，支持 Spoke-to-Spoke 捷径
ip ospf priority 255 # 确保 Hub 成为 OSPF DR（广播网络类型）
OSPF 网络类型设为 broadcast，Hub 的优先级设为 255 确保它总是 DR，Spoke 优先级设为 0 不参与 DR 选举。这样设计的原因是 mGRE 网络中 Hub 是中心节点，作为 DR 可以确保 LSA 的可靠泛洪。
配置详解
Hub 配置
IKEv2 配置
crypto ikev2 proposal IKEV2-PROPOSAL
encryption aes-gcm-256 # 加密算法
prf sha256 sha384 # 伪随机函数
group 19 # DH Group 19 (ECP-256)
crypto ikev2 policy IKEV2-POLICY
proposal IKEV2-PROPOSAL
crypto ikev2 keyring DMVPN-KEYRING
peer DMVPN
address ::/0 # 匹配所有 IPv6 对端
pre-shared-key Cisco123
crypto ikev2 profile DMVPN-PROFILE-V6
match identity remote address ::/0
authentication remote pre-share
authentication local pre-share
keyring local DMVPN-KEYRING
crypto ikev2 dpd 30 5 on-demand # DPD 保活
值得注意的点：
address ::/0匹配所有 IPv6 地址，使得 Spoke 可以动态加入，无需在 Hub 上逐一添加 Spoke 的地址IKEv2 Profile 中的
match identity remote address ::/0同样使用通配匹配，适合 Spoke 地址不固定的场景
IPsec 配置
crypto ipsec transform-set DMVPN-TS esp-gcm 256
mode transport # 传输模式，避免额外封装开销
crypto ipsec profile DMVPN-IPSEC-V6
set transform-set DMVPN-TS
set ikev2-profile DMVPN-PROFILE-V6
DMVPN 中使用 transport mode 而非 tunnel mode，因为 GRE 已经提供了隧道封装，IPsec 只需保护 GRE 载荷即可，避免双重隧道头的额外开销。
Tunnel 接口配置
interface Tunnel200
ip address 172.16.200.254 255.255.255.0
ip mtu 1380 # 预留 GRE+IPsec 封装开销
ip nhrp authentication Cisco123
ip nhrp network-id 200
ip nhrp holdtime 360
ip nhrp server-only
ip nhrp redirect
ip tcp adjust-mss 1340
ip ospf network broadcast
ip ospf hello-interval 2
ip ospf priority 255
ip ospf mtu-ignore
ip ospf 1 area 0
tunnel source GigabitEthernet1
tunnel mode gre multipoint ipv6 # mGRE over IPv6
tunnel key 200
tunnel path-mtu-discovery
tunnel protection ipsec profile DMVPN-IPSEC-V6
MTU/MSS 参数说明：
ip mtu 1380：IPv6 头（40）+ GRE 头（4-24）+ IPsec ESP 头（约 56）+ 内部 IP 头（20）= 约 120 字节开销，1380 + 120 = 1500ip tcp adjust-mss 1340：在 TCP 三次握手时动态调整 MSS，避免分片
Spoke 配置（以 Spoke1 为例）
Spoke 的 IKEv2 和 IPsec 配置与 Hub 完全一致，差异主要在 Tunnel 接口：
ip host nj-home.wuhao.net.cn 240E:3AF:872:94B0:BE24:11FF:FE6A:40BD
interface Tunnel200
ip address 172.16.200.1 255.255.255.0
ip mtu 1380
ip nhrp authentication Cisco123
ip nhrp network-id 200
ip nhrp holdtime 360
ip nhrp nhs dynamic nbma nj-home.wuhao.net.cn multicast # 域名方式指定 NHS
ip nhrp redirect
ip tcp adjust-mss 1340
ip ospf network broadcast
ip ospf hello-interval 2
ip ospf priority 0 # Spoke 不参与 DR 选举
ip ospf mtu-ignore
ip ospf 1 area 0
tunnel source GigabitEthernet1
tunnel mode gre multipoint ipv6
tunnel key 200
tunnel path-mtu-discovery
tunnel protection ipsec profile DMVPN-IPSEC-V6
Spoke2 配置与 Spoke1 类似，Tunnel 地址为 172.16.200.2/24，Loopback2 为 3.3.3.3/32。
OSPF 路由配置
所有节点上：
router ospf 1
router-id 10.255.0.X
passive-interface default # 默认所有接口不发送 OSPF Hello
no passive-interface Tunnel200 # 仅在 Tunnel 接口启用 OSPF
通过 passive-interface default 限制 OSPF 只在 Tunnel 网络运行，避免在公网侧接口建立不必要的邻居关系。
验证与分析
1. IKEv2 SA 状态
Hub 上的 IKEv2 SA（两个 Spoke 均已接入）：
Hub# show crypto ikev2 sa
IPv6 Crypto IKEv2 SA
Tunnel-id fvrf/ivrf Status
2 none/none READY
Local 240E:3AF:872:94B0:BE24:11FF:FE6A:40BD/500
Remote 2408:823C:8B8D:CE4:BE24:11FF:FEC8:1064/500
Encr: AES-GCM, keysize: 256, PRF: SHA256, Hash: None,
DH Grp:19, Auth sign: PSK, Auth verify: PSK
Tunnel-id fvrf/ivrf Status
1 none/none READY
Local 240E:3AF:872:94B0:BE24:11FF:FE6A:40BD/500
Remote 240E:3A1:620:80A3:250:56FF:FE91:FF24/500
Encr: AES-GCM, keysize: 256, PRF: SHA256, Hash: None,
DH Grp:19, Auth sign: PSK, Auth verify: PSK
可以看到 Hub 与两个 Spoke 分别建立了独立的 IKEv2 SA，状态均为 READY，会话参数完全一致：AES-GCM-256 加密、SHA256 伪随机函数、DH Group 19、PSK 认证。IKE SA 的生命周期为 86400 秒（24 小时）。
Spoke1 上的 IKEv2 SA（一次 Spoke-to-Spoke 通信后）：
Spoke1# show crypto ikev2 sa
Tunnel-id fvrf/ivrf Status
2 none/none READY
Local 240E:3A1:620:80A3:250:56FF:FE91:FF24/500
Remote 2408:823C:8B8D:CE4:BE24:11FF:FEC8:1064/500 ← 与 Spoke2 的直接隧道
Tunnel-id fvrf/ivrf Status
1 none/none READY
Local 240E:3A1:620:80A3:250:56FF:FE91:FF24/500
Remote 240E:3AF:872:94B0:BE24:11FF:FE6A:40BD/500 ← 与 Hub 的隧道
Spoke1 上同时存在两条 IKEv2 SA：一条是与 Hub 的（始终存在），另一条是与 Spoke2 的（触发式按需建立）。这就是 DMVPN Phase 3 的核心特征——Spoke-to-Spoke 动态隧道。
2. IPsec SA 状态
Hub# show crypto ipsec sa
interface: Tunnel200
Crypto map tag: Tunnel200-head-0,
local addr 240E:3AF:872:94B0:BE24:11FF:FE6A:40BD
protected vrf: (none)
local ident (addr/mask/prot/port):
(240E:3AF:872:94B0:BE24:11FF:FE6A:40BD/128/47/0)
remote ident (addr/mask/prot/port):
(2408:823C:8B8D:CE4:BE24:11FF:FEC8:1064/128/47/0)
inbound esp sas:
spi: 0x6D1F1F30
transform: esp-gcm 256,
in use settings ={Transport, }
sa timing: remaining key lifetime (k/sec): (4607989/3480)
Status: ACTIVE(ACTIVE)
outbound esp sas:
spi: 0x703408D0
transform: esp-gcm 256,
in use settings ={Transport, }
Status: ACTIVE(ACTIVE)
ESP 使用 GCM-256 认证加密，传输模式（Transport），SA 状态均为 ACTIVE。prot 47 表明保护的是 GRE 协议流量。
3. NHRP 表项
Hub 上的 NHRP：
Hub# show ip nhrp
172.16.200.1/32 via 172.16.200.1
Type: dynamic, Flags: registered nhop
NBMA address: 240E:3A1:620:80A3:250:56FF:FE91:FF24
172.16.200.2/32 via 172.16.200.2
Type: dynamic, Flags: registered nhop
NBMA address: 2408:823C:8B8D:CE4:BE24:11FF:FEC8:1064
Hub# show dmvpn
Interface: Tunnel200, IPv4 NHRP Details
Type:Hub, NHRP Peers:2,
# Ent Peer NBMA Addr Peer Tunnel Addr State UpDn Tm Attrb
----- ----------------------------------- --------------- ----- -------- -----
1 240E:3A1:620:80A3:250:56FF:FE91:FF24 172.16.200.1 UP 00:03:01 D
1 2408:823C:8B8D:CE4:BE24:11FF:FEC8:1064 172.16.200.2 UP 00:02:10 D
Hub 作为 NHRP 服务器，维护了两个 Spoke 的动态注册信息。每个 Spoke 的 NBMA 地址都是其 IPv6 全球单播地址。
Spoke1 上的 NHRP（静态 + 动态）：
Spoke1# show ip nhrp
172.16.200.254/32 via 172.16.200.254
Type: static, Flags:
NBMA address: 240E:3AF:872:94B0:BE24:11FF:FE6A:40BD (nj-home.wuhao.net.cn)
172.16.200.2/32 via 172.16.200.2
Type: dynamic, Flags: router nhop
NBMA address: 2408:823C:8B8D:CE4:BE24:11FF:FEC8:1064
NHRP 表中有两条记录：
Hub（172.16.200.254）是静态条目，通过域名
nj-home.wuhao.net.cn解析得到的 IPv6 地址。Flags 中显示域名信息。Spoke2（172.16.200.2）是动态条目，在 Spoke1 首次访问 3.3.3.3（Spoke2 的 Loopback）时通过 NHRP 解析获取。
router nhop 标志表示该条目是通过 NHRP Redirect 学习到的，用于 Spoke-to-Spoke 直接通信，下一跳是 Spoke2 的 Tunnel 地址而非 Hub。
4. 路由表验证
Hub 的路由表：
Hub# show ip route
O 2.2.2.2 [110/1001] via 172.16.200.1, 00:02:37, Tunnel200
O 3.3.3.3 [110/1001] via 172.16.200.2, 00:01:46, Tunnel200
C 10.255.1.1 is directly connected, Loopback2
C 172.16.200.0/24 is directly connected, Tunnel200
Spoke2 的路由表：
Spoke2# show ip route
O 2.2.2.2 [110/1001] via 172.16.200.1, 00:03:44, Tunnel200
C 3.3.3.3 is directly connected, Loopback2
O 10.255.1.1 [110/1001] via 172.16.200.254, 00:03:44, Tunnel200
C 172.16.200.0/24 is directly connected, Tunnel200
所有路由均通过 OSPF 学习，Metric 为 1001（到 Loopback 接口的默认开销 + 1000）。Tunnel 接口被 OSPF 视为广播网络，各节点通过 Hub（DR）交换 LSA。
5. 连通性测试
Spoke1 访问 Spoke2 的 Loopback（首次触发 NHRP 解析）：
Spoke1# ping 3.3.3.3 source lo2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/20/21 ms
Spoke2 访问 Spoke1 的 Loopback：
Spoke2# ping 2.2.2.2 source 3.3.3.3
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 17/17/19 ms
两端互通，延迟稳定在 17-21ms，说明 Spoke1 和 Spoke2 之间已建立直接的 IPsec 隧道。
Spoke-to-Spoke 动态隧道建立过程
DMVPN Phase 3 最精彩的部分是 Spoke 之间的直接隧道建立。以 Spoke1 ping Spoke2（3.3.3.3）为例，完整流程如下：
Step 1: Spoke1 查路由表，发现 3.3.3.3 的下一跳是 172.16.200.2（Spoke2 的 Tunnel 地址）
Step 2: Spoke1 查 NHRP 表，172.16.200.2 没有对应条目
Step 3: Spoke1 向 Hub（NHS）发送 NHRP Resolution Request：
"谁是 172.16.200.2？"
Step 4: Hub 查 NHRP 表，回复 NHRP Resolution Reply：
"172.16.200.2 的 NBMA 地址是 2408:823C:8B8D:CE4:BE24:11FF:FEC8:1064"
Step 5: Spoke1 与 2408:823C:8B8D:CE4:BE24:11FF:FEC8:1064 发起 IKEv2 协商
Step 6: IKEv2 SA 和 IPsec SA 建立成功（独立的隧道，不经 Hub）
Step 7: 数据流直接在 Spoke1 ↔ Spoke2 之间传输
从 Spoke1 的验证输出来看，ping 发起后：
NHRP 表中新增了一条到 Spoke2 的动态条目
IKEv2 SA 中新增了与 Spoke2 的会话（Tunnel-id 2，Active Time: 7 sec）
DMVPN 表中 Peer 数从 1 变为 2
安全参数总结
总结
本实验展示了基于 IPv6 的 IKEv2 DMVPN 的几个关键技术点：
IPv6 作为 Underlay：使用
tunnel mode gre multipoint ipv6在 IPv6 公网上运行 mGRE，避免了 IPv4 NAT 穿越问题。域名动态解析：通过
ip nhrp nhs dynamic nbma <FQDN>实现 NHS 的域名指定，使 Hub 地址变更时配置更加灵活。IKEv2 + AES-GCM-256：使用现代加密标准，GCM 模式同时提供加密和完整性校验，相比传统的 AES-CBC + HMAC 组合更高效。
Spoke-to-Spoke 直接通信：借助 NHRP Redirect 和 NHRP Resolution 机制，Spoke 之间可以动态建立直连隧道，流量无需绕行 Hub。
这种架构适合 Spoke 分布在运营商 IPv6 宽带下的场景——如家庭办公、门店互联等，无需固定的公网 IPv4 地址，也无需担心 NAT 对 IPsec 的影响。
实验环境：Cisco C8000V (IOS XE 17.06.07 / 17.09.07a)，2026 年 6 月