我正在部署 DMVPN。主要的复杂性在于一些分支位于 NAT 后面，无法直接相互传输流量，因此需要通过集线器传输。但是，它没有按预期工作。流量仍直接发送到其他分支。
拓扑结构为单云、双集线器。在测试实验室 (GNS3) 中，我有四个辐条：其中两个具有对辐条的“直接”访问权限（无需地址转换），另外两个位于其他执行 NAT 的路由器后面，每个辐条都有自己的 NAT（因此没有两个辐条位于单个 NAT 后面）。
动态路由使用 EIGRP 完成，因为 Cisco 在后来的 DMVPN 相关文档中明确推荐它，并表示 OSPF 没有经过过多的测试。但是，我不确定，如果 OSPF 性能更好，我可以使用它。
（图中部分主机显示为宕机，此图是我在进行上述所有测试和分析后制作的）
相关配置是： hub1：
!
interface Tunnel0
bandwidth 1000000
ip address 10.100.255.253 255.255.255.0
no ip redirects
ip mtu 1400
no ip next-hop-self eigrp 65000
no ip split-horizon eigrp 65000
ip nhrp map multicast dynamic
ip nhrp network-id 65000
ip nhrp holdtime 300
ip nhrp redirect
tunnel source Ethernet0/0
tunnel mode gre multipoint
!
interface Ethernet0/0
description internet.e0/0
ip address 172.31.0.2 255.255.255.0
!
interface Ethernet0/3
description service.e0/0
ip address 10.100.200.253 255.255.255.240
standby 1 ip 10.100.200.252
standby 1 priority 110
standby 1 preempt delay reload 60
standby 1 name HSRP
!
router eigrp 65000
network 10.100.200.176 0.0.0.15
network 10.100.255.0 0.0.0.255
!
ip route 0.0.0.0 0.0.0.0 172.31.0.1
!
中心2：
!
interface Tunnel0
bandwidth 800000
ip address 10.100.255.254 255.255.255.0
no ip redirects
ip mtu 1400
no ip next-hop-self eigrp 65000
no ip split-horizon eigrp 65000
ip nhrp map multicast dynamic
ip nhrp map multicast 172.31.0.2
ip nhrp map 10.100.255.253 172.31.0.2
ip nhrp network-id 65000
ip nhrp holdtime 300
ip nhrp nhs 10.100.255.253
ip nhrp shortcut
ip nhrp redirect
tunnel source Ethernet0/0
tunnel mode gre multipoint
!
interface Ethernet0/0
description internet.e0/1
ip address 172.31.0.3 255.255.255.0
!
interface Ethernet0/3
description service.e0/1
ip address 10.100.200.254 255.255.255.240
standby 1 ip 10.100.200.252
standby 1 preempt delay reload 60
standby 1 name HSRP
!
router eigrp 65000
network 10.100.200.240 0.0.0.15
network 10.100.255.0 0.0.0.255
!
ip route 0.0.0.0 0.0.0.0 172.31.0.1
!
spoke1（直接互联网）：
!
interface Loopback0
ip address 10.100.200.5 255.255.255.252
!
interface Tunnel0
bandwidth 100000
ip address 10.100.255.1 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp map 10.100.255.253 172.31.0.2
ip nhrp map 10.100.255.254 172.31.0.3
ip nhrp map multicast 172.31.0.2
ip nhrp map multicast 172.31.0.3
ip nhrp network-id 65000
ip nhrp holdtime 300
ip nhrp nhs 10.100.255.253
ip nhrp nhs 10.100.255.254
ip nhrp shortcut
tunnel source Ethernet0/0
tunnel mode gre multipoint
!
interface Ethernet0/0
description internet.e1/0
ip address 172.31.1.2 255.255.255.0
!
router eigrp 65000
network 10.100.200.4 0.0.0.3
network 10.100.255.0 0.0.0.255
!
ip route 0.0.0.0 0.0.0.0 172.31.1.1
!
spoke2 与 1 类似，只有地址不同。lo0 有 10.100.200.9/30
spoke3 (NAT 后面)：
!
interface Loopback0
ip address 10.100.200.13 255.255.255.252
!
interface Tunnel0
bandwidth 100000
ip address 10.100.255.3 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp map 10.100.255.253 172.31.0.2
ip nhrp map 10.100.255.254 172.31.0.3
ip nhrp map multicast 172.31.0.3
ip nhrp map multicast 172.31.0.2
ip nhrp network-id 65000
ip nhrp holdtime 300
ip nhrp nhs 10.100.255.253
ip nhrp nhs 10.100.255.254
ip nhrp shortcut
tunnel source Ethernet0/0
tunnel mode gre multipoint
!
interface Ethernet0/0
description spoke3-gw.e0/3
ip address 192.168.1.2 255.255.255.0
!
router eigrp 65000
network 10.100.200.12 0.0.0.3
network 10.100.255.0 0.0.0.255
!
ip route 0.0.0.0 0.0.0.0 192.168.1.1
!
spoke3-gw（为 spoke3 执行 NAT 的那个）：
!
interface Ethernet0/0
description internet.e1/2
ip address 172.31.3.2 255.255.255.0
ip nat outside
ip virtual-reassembly in
!
interface Ethernet0/3
description spoke3.e0/0
ip address 192.168.1.1 255.255.255.0
ip nat inside
ip virtual-reassembly in
!
ip nat inside source list 1 interface Ethernet0/0 overload
ip route 0.0.0.0 0.0.0.0 172.31.3.1
!
access-list 1 permit 192.168.1.0 0.0.0.255
!
spoke4 和 spoke4-gw 对类似，lo0 有 10.100.200.17/30。“灰色”地址相同，为 192.168.1.0/24。思科明确指出这是有效情况，应该可以工作。
互联网拥有所有那些 172.31.{0,1,2,3,4}.1 地址，并且只是在 .2-s 和 .0.3 之间转发数据包；服务只是一个拥有 10.100.200.241 地址并默认为 10.100.200.252（HSRP 管理）的系统。
没有配置 IPSEC。我正在尝试逐步完成任务，第一次尝试就把所有事情都做对是件很困难的事。
我已经使用“ping 10.100.200.13 source 10.100.200.17”（从 spoke3 到 spoke4）等命令进行了测试。
这“似乎”有效。也就是说，所述 ping 有效。但在链路“internet.e1/3 - spoke4-gw.e0/0”上捕获数据包表明，我们仍然有从 spoke3-gw 到 spoke4-gw 的直接数据包，反之亦然。spoke3 和 spoke4 上的“show ip nhrp”显示了这一点（解析为其他的 -gw“白色”地址）。检查 -gw 上的 NAT“show ip nat 翻译”显示，是的，在 spoke3-gw 上有从 spoke3 到 spoke4-gw 的 GRE 转换（spoke4-gw 上也有类似情况）。这就是所述 ping 工作的方式。我很幸运在这个实验室中有 Cisco 做 NAT，它做得对。
在现实世界中，NAT 盒可以是任何东西。我不能要求使用某些具体的设备（这样做是违法的）。我只能要求它正确地执行 GRE 到集线器的 NAT 并返回（这是运行 DMVPN 的最低要求）。
如果我阻止 spoke3-gw 和 spoke4-gw 之间的直接流量（在互联网系统上，通过安装从 172.31.4.2 到 172.31.3.2 的访问规则，反之亦然），我预计系统会看到这一点并通过 hub 转发 spoke3 和 spoke4 之间的所有内容。但是，它不起作用。
sh ip nhrp on spoke3 这次显示无法解析 10.100.200.17：
10.100.200.12/30 via 10.100.255.3
Tunnel0 created 00:00:39, expire 00:04:33
Type: dynamic, Flags: router unique local
NBMA address: 192.168.1.2
(no-socket)
10.100.200.17/32
Tunnel0 created 00:00:39, expire 00:02:25
Type: incomplete, Flags: negative
Cache hits: 2
10.100.255.3/32 via 10.100.255.3
Tunnel0 created 00:01:34, expire 00:04:20
Type: dynamic, Flags: router unique local
NBMA address: 192.168.1.2
(no-socket)
10.100.255.4/32 via 10.100.255.4
Tunnel0 created 00:00:39, expire 00:04:33
Type: dynamic, Flags: router implicit used nhop
NBMA address: 172.31.4.2
(Claimed NBMA address: 192.168.1.2)
10.100.255.253/32 via 10.100.255.253
Tunnel0 created 03:24:10, never expire
Type: static, Flags: used
NBMA address: 172.31.0.2
10.100.255.254/32 via 10.100.255.254
Tunnel0 created 03:24:10, never expire
Type: static, Flags: used
NBMA address: 172.31.0.3
为什么在这种情况下它不通过集线器引导数据包？ 这种方式仍然有效。
答案1
Spoke-to-Spoke DMVPN 被视为 DMVPN 第二阶段。Spoke-to-Hub 设计被视为 DMVPN 第一阶段。
我建议进行以下更改以将您的行为改变为 DMVPN 第一阶段。
中心1
interface Tunnel0
ip next-hop-self eigrp 65000
no ip nhrp redirect
中心2
interface Tunnel0
ip next-hop-self eigrp 65000
no ip nhrp shortcut
no ip nhrp redirect
辐条1
interface Tunnel0
no ip nhrp shortcut
辐条2
interface Tunnel0
no ip nhrp shortcut
辐条3
interface Tunnel0
no ip nhrp shortcut
有关配置以及验证行为的更多详细信息，请参见这里。