DMVPN – Analyzing and Discuss for Phase2,3

21 2 月, 2014,由 frank撰写

对于Site-to-Site VPN来说，IPsec是最好的选择，但他有天然的不足，就是无法大规模部署。如果在hub-spoke这种模型下，客户有1000个站点要建VPN，而且spoke跟spoke也要VPN通信，那么全网VPN的配置非常巨大，也非常消耗路由器的资源。此时思科推出了DMVPN，他利用了几个组件，实现了动态IPsec VPN的建立。本文将讨论DMVPN的基本信息及部署方法。

DMVPN的组件

1. mGRE(multipoint GRE)，多点GRE
2. NHRP(Next Hop Resolution Protocol)
3. Dynamic Routing Protocol
4. IPsec VPN，也可以不加IPsec

NHRP类似ARP，不同的是ARP是IP地址到MAC地址的映射，而NHRP是tunnel地址到物理地址（NMBA地址）的映射。
对于DMVPN有3个发展阶段，其他资料里有很细的分类和不同，我在这里只做简单总结：
Phase1：只有hub支持mGRE，branch只支持pGRE；所有流量都需要经过hub，spoke跟spoke之间不能建立隧道；hub可路由汇总，spoke不需要明细路由
Phase2：hub和spoke都支持mGRE；spoke跟spoke可以直接建立隧道，流量可不经过hub；spoke必须要明细路由；hub需要关闭水平分割
phase3：hub和spoke都支持mGRE；spoke跟spoke的隧道由hub触发；hub不需要关闭水平分割

测试Topology

配置DMVPN的步骤及注意事项-Phase2

1. spoke不管是DSL或拨号，都首先要连到internet上，并路由，此处广域网路由部分省略
2. 广域网路由通后，在hub上建立mGRE，在spoke上也建立mGRE
下面是hub的mGRE配置

interface Tunnel0
 ip address 172.16.1.100 255.255.255.0
 ip mtu 1400
!---由于各种包头，如GRE，ESP，IP header等，所以建议1400
 no ip next-hop-self eigrp 100
 no ip split-horizon eigrp 100
 tunnel source FastEthernet0/0
!---对于多点GRE只有源，没有目的
 tunnel mode gre multipoint
 tunnel key 12345
!---这个key主要是区分多个tunnel的场景

下面是spoke的mGRE配置（仅拿R3为例）

interface Tunnel0
 ip address 172.16.1.1 255.255.255.0
 tunnel source FastEthernet1/0
 tunnel mode gre multipoint
 tunnel key 12345

3. 配置NHRP，使tunnel互通，由于内网仍然没有路由，所以每台路由器的内网地址不能互通
下面是hub的NHRP配置

interface Tunnel0
 ip nhrp authentication cisco
 ip nhrp map multicast dynamic
!---hub的nhrp是动态映射，因为他不知道分支站点的IP地址
 ip nhrp network-id 10
!---类似eigrp的as号，区分DMVPN域的

下面是spoke的NHRP配置（仅拿R3为例）

interface Tunnel0
 ip nhrp authentication cisco
 ip nhrp map 172.16.1.100 12.1.1.1
!---手动映射，tunnel到真实地址的映射
 ip nhrp map multicast 12.1.1.1
!---组播发给hub
 ip nhrp network-id 10
 ip nhrp nhs 172.16.1.100
!---指定nhrp server去注册，这里是tunnel的地址

4. 配置动态路由协议，此处用EIGRP来配置，EIGRP对hub-spoke场景支持的很好，此处配置略
要注意几点：
-对于DMVPN，只有hub-spoke有neighbor关系，spoke-spoke没有邻接关系
-由于水平分割的影响，hub从spoke学到的路由不会传给另一个spoke，所以要关闭水平分割
-对于EIGRP来说路由经过hub会改变下一跳地址为自己，所以用增强的EIGRP可以关掉这个功能

所以需要在hub上配置如下配置以解决上面提到的问题：

interface Tunnel0
 no ip next-hop-self eigrp 100
 no ip split-horizon eigrp 100

5. 配置IPsec并应用到tunnel上，hub和spoke配置一样

crypto isakmp policy 10
 authentication pre-share
crypto isakmp key cisco address 0.0.0.0 0.0.0.0
!---这里是8个0，可以跟任何地址协商isakmp，不是特别安全，可改用证书认证
!
crypto ipsec transform-set cisco esp-des esp-md5-hmac 
 mode transport
!
crypto ipsec profile ipsecprof
 set transform-set cisco 
!
interface Tunnel0
 tunnel protection ipsec profile ipsecprof

NHRP抓包分析

根据上面配置，全部已经OK，就差抓包验证了。为了方便分析（加密报文无法分析），此处去掉IPsec

步骤如下：
1. 关闭hub及2个spoke的wan口和tunnel
2. 在hub的出接口抓包
3. 开启hub和spoke1的wan口和tunnel，等待收敛
4. 在开启spoke2的wan口和tunnel，等待收敛
5. 在spoke1上ping spoke2，默认5个包
6. 关闭抓包，抓包名为”dmvpn-02-no-ipsec.pcap”

分析如下：
1-4：可以看到spoke发送NHRP register到hub，hub顺利回复，建立NHRP表项
下面是hub上的抓包信息：

下面是hub的NHRP和路由信息：

hub#sh ip nhrp
172.16.1.1/32 via 172.16.1.1
   Tunnel0 created 03:20:11, expire 01:59:48
   Type: dynamic, Flags: unique registered used 
   NBMA address: 23.1.1.3 
172.16.1.2/32 via 172.16.1.2
   Tunnel0 created 03:20:09, expire 01:57:13
   Type: dynamic, Flags: unique registered 
   NBMA address: 25.1.1.5 

hub#show ip route eigrp
D    192.168.1.0/24 [90/27008000] via 172.16.1.1, 03:22:14, Tunnel0
D    192.168.2.0/24 [90/27008000] via 172.16.1.2, 00:04:46, Tunnel0

下面是spoke1的NHRP和路由信息，可以看到，由于spoke1上没有spoke2的NHRP的信息，所以表项是incomplete的，注意只从CEF和RIB表中看不出真实的下一跳

spoke1#sh ip nhrp 
172.16.1.100/32 via 172.16.1.100
   Tunnel0 created 03:21:49, never expire 
   Type: static, Flags: used 
   NBMA address: 12.1.1.1

spoke1#show ip cef 192.168.100.0/24
192.168.100.0/24
  nexthop 172.16.1.100 Tunnel0
spoke1#
spoke1#
spoke1#show ip cef 192.168.2.0/24  
192.168.2.0/24
  nexthop 172.16.1.2 Tunnel0
spoke1#
spoke1#show ip cef 192.168.100.0/24 inter
192.168.100.0/24, epoch 0, RIB[I], refcount 5, per-destination sharing
  sources: RIB 
  feature space:
   IPRM: 0x00038000
  ifnums:
   Tunnel0(12): 172.16.1.100
  path 67DF9538, path list 67DF8220, share 1/1, type attached nexthop, for IPv4
  nexthop 172.16.1.100 Tunnel0, adjacency IP midchain out of Tunnel0, addr 172.16.1.100 66B725C0
  output chain: IP midchain out of Tunnel0, addr 172.16.1.100 66B725C0 IP adj out of FastEthernet1/0, addr 23.1.1.2 66B72480
spoke1#
spoke1#show ip cef 192.168.2.0/24 inter
192.168.2.0/24, epoch 0, RIB[I], refcount 5, per-destination sharing
  sources: RIB 
  feature space:
   IPRM: 0x00038000
  ifnums:
   Tunnel0(12): 172.16.1.2
  path 67DF9620, path list 67DF82B8, share 1/1, type attached nexthop, for IPv4
  nexthop 172.16.1.2 Tunnel0, adjacency IP adj out of Tunnel0, addr 172.16.1.2 (incomplete)
  output chain: IP adj out of Tunnel0, addr 172.16.1.2 (incomplete)

5. 当spoke1 ping spoke2时，可以看到spoke1向hub发送resolution request，hub又转给spoke2，spoke2记录spoke1的NHRP信息；反过来同样的步骤，spoke1记录spoke2的NHRP信息

根据下面的详细数据包，可以看出hub只收到2个ICMP包，当NHRP解析好后，spoke之间的流量不会再次经过hub

Phase3 分析

Phase3加强了spoke-to-spoke的交互，并应用了2个新的NHRP feature，一个是NHRP Redirect，另一个是NHRP Shortcut：
NHRP Redirect：配置在hub上，功能类似IP redirect，当从mGRE口收到一个流量，此流量是从spoke1到spoke2的，而且要从同样的mGRE口出去，此时hub会发送NHRP Redirect给源spoke，告诉它去这个目的地址，不要发给我，要发给xxx
NHRP Shortcut：配置在spoke上，当spoke完成解析，会更新CEF，直接改变下一跳

但根据测试，转发流量总是经过hub，非常郁闷，我也没有抓到redirect的包，不知道这种包的type是不是跟phase2的一样。先放着吧，找到原因了在更新，卡了2天了，郁闷。。。

spoke1#sh ip nhrp
172.16.1.1/32 via 172.16.1.1
   Tunnel0 created 00:02:55, expire 01:57:04
   Type: dynamic, Flags: router unique local 
   NBMA address: 23.1.1.3 
    (no-socket) 
172.16.1.2/32 via 172.16.1.2
   Tunnel0 created 00:02:55, expire 01:57:04
   Type: dynamic, Flags: router implicit 
   NBMA address: 25.1.1.5 
172.16.1.100/32 via 172.16.1.100
   Tunnel0 created 00:09:57, never expire 
   Type: static, Flags: used 
   NBMA address: 12.1.1.1

2014-2-22 更新：问题解决

原因出在模拟器上，dynamips 不支持 DMVPN Phase3，我用最新版的image，也是一样的问题。换了其他设备（非模拟器），同样的配置，直接就ok了，而且也抓到了NHRP的redirect报文，注意这里的实验环境跟上面的topology有了些变化，tunnel和内网地址都没变，只是广域网的互联口变了：hub是R1，switch是R3，spoke1是R5，spoke2是R6，地址分配原则跟上面是一样的。下面的图片是在hub上抓的包：

1. 开始的数据包仍然会punt到hub，因为spoke1没有NHRP信息，所以直接走汇总路由，如上图中的第73和74个ICMP request包

2. 当hub收到spoke1的报文后，发现要从接收端口再次发送出去，所以会向源spoke1发送redirect包，也就是上图中的第75个包，里面告诉spoke1，要想去192.168.2.1，必须先找到192.168.2.1的NHRP，下面是hub的debug和此包的详细信息：

*Feb 22 10:33:36.341: NHRP: Tunnels gave us remote_nbma: 35.1.1.5 for Redirect
*Feb 22 10:33:36.341: NHRP: Attempting to Redirect, remote_nbma:35.1.1.5, dst:192.168.2.1
*Feb 22 10:33:36.341: NHRP: inserting (35.1.1.5/192.168.2.1) in redirect table
*Feb 22 10:33:36.341: NHRP: Attempting to send packet through interface Tunnel0 via DEST  dst 172.16.1.1
*Feb 22 10:33:36.341: NHRP: Send Traffic Indication via Tunnel0 vrf 0, packet size: 97
*Feb 22 10:33:36.341:  src: 172.16.1.100, dst: 172.16.1.1
*Feb 22 10:33:36.341:  (F) afn: AF_IP(1), type: IP(800), hop: 255, ver: 1
*Feb 22 10:33:36.341:      shtl: 4(NSAP), sstl: 0(NSAP)
*Feb 22 10:33:36.341:      pktsz: 97 extoff: 68
*Feb 22 10:33:36.341:  (M) traffic code: redirect(0)
*Feb 22 10:33:36.341:      src NBMA: 13.1.1.1
*Feb 22 10:33:36.341:      src protocol: 172.16.1.100, dst protocol: 172.16.1.1
*Feb 22 10:33:36.341:      Contents of nhrp traffic indication packet:
*Feb 22 10:33:36.341:         45 00 00 64 04 02 00 00 FE 01 48 DC AC 10 01 01 
*Feb 22 10:33:36.341:         C0 A8 02 01 08 00 0E 62 00 07 00

3. 此时hub 收到了spoke2发送的ICMP reply，目的地址是172.16.1.1。并发现他要从接收口再次转发出去，所以hub也给spoke2发送了一个redirect包，如上面的第78个包，让spoke2请求解析172.16.1.1的报文，下面是hub的debug

*Feb 22 10:33:36.351: NHRP: Tunnels gave us remote_nbma: 36.1.1.6 for Redirect
*Feb 22 10:33:36.351: NHRP: Attempting to Redirect, remote_nbma:36.1.1.6, dst:172.16.1.1
*Feb 22 10:33:36.351: NHRP: inserting (36.1.1.6/172.16.1.1) in redirect table
*Feb 22 10:33:36.353: NHRP: Attempting to send packet through interface Tunnel0 via DEST  dst 192.168.2.1
*Feb 22 10:33:36.353: NHRP: Send Traffic Indication via Tunnel0 vrf 0, packet size: 97
*Feb 22 10:33:36.353:  src: 172.16.1.100, dst: 192.168.2.1
*Feb 22 10:33:36.353:  (F) afn: AF_IP(1), type: IP(800), hop: 255, ver: 1
*Feb 22 10:33:36.353:      shtl: 4(NSAP), sstl: 0(NSAP)
*Feb 22 10:33:36.353:      pktsz: 97 extoff: 68
*Feb 22 10:33:36.353:  (M) traffic code: redirect(0)
*Feb 22 10:33:36.353:      src NBMA: 13.1.1.1
*Feb 22 10:33:36.353:      src protocol: 172.16.1.100, dst protocol: 192.168.2.1
*Feb 22 10:33:36.353:      Contents of nhrp traffic indication packet:
*Feb 22 10:33:36.353:         45 00 00 64 04 02 00 00 FE 01 48 DC C0 A8 02 01 
*Feb 22 10:33:36.353:         AC 10 01 01 00 00 16 62 00 07 00  <<< 172.16.1.1 from spoke2

4. spoke2 接到后，发送请求解析172.16.1.1，如图第79个包，hub有172.16.1.1的NHRP，所以直接转给spoke1，如图第80个包

5. 此时spoke1还没发送对192.168.2.1的解析包，所以继续发送第2个ICMP request报文，如图第81个报文，根据hub的NHRP，转发此request给spoke2，如第83个报文

6. spoke1 接到redirect包后，生成临时NHRP，并请求解析这个地址，如图第82个报文，到hub后，由hub转给spoke2

*Feb 22 10:32:09.888: NHRP: Tunnel0: Cache add for target 192.168.2.1/32 next-hop 192.168.2.1
*Feb 22 10:32:09.888:            
*Feb 22 10:32:09.888: NHRP: nhrp_ifcache: Avl Root:B311E88
*Feb 22 10:32:09.888: NHRP: Enqueued NHRP Resolution Request for destination: 192.168.2.1
*Feb 22 10:32:09.888: NHRP: Checking for delayed event NULL/192.168.2.1 on list (Tunnel0).
*Feb 22 10:32:09.888: NHRP-MPLS:  tableid: 0 vrf: 
*Feb 22 10:32:09.888: NHRP: No delayed event node found.
*Feb 22 10:32:09.888: NHRP: nhrp_ifcache: Avl Root:B311E88
*Feb 22 10:32:09.888: NHRP: Enqueued NHRP Resolution Request for destination: 192.168.2.1

7. 此时spoke1和spoke2都发送了resolution报文给对方，这时两边的NHRP信息都全了，所以两边后面的ICMP及其他信息就不会到hub了，抓包里确实看不到了，至此整个过程分析完毕，下面是正常情况下spoke1的NHRP信息：

spoke1(config-if)#do sh 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
       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
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       a - application route
       + - replicated route, % - next hop override

Gateway of last resort is not set

      172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
H        172.16.1.2/32 is directly connected, 00:00:30, Tunnel0
H     192.168.2.0/24 [250/1] via 172.16.1.2, 00:00:30, Tunnel0
spoke1(config-if)#
spoke1(config-if)#do sh ip nhrp
172.16.1.1/32 via 172.16.1.1
   Tunnel0 created 00:00:39, expire 01:59:20
   Type: dynamic, Flags: router unique local 
   NBMA address: 35.1.1.5 
    (no-socket) 
172.16.1.2/32 via 172.16.1.2
   Tunnel0 created 00:00:39, expire 01:59:20
   Type: dynamic, Flags: router used nhop rib 
   NBMA address: 36.1.1.6 
172.16.1.100/32 via 172.16.1.100
   Tunnel0 created 00:01:40, never expire 
   Type: static, Flags: used 
   NBMA address: 13.1.1.1 
192.168.2.0/24 via 172.16.1.2
   Tunnel0 created 00:00:39, expire 01:59:20
   Type: dynamic, Flags: router rib 
   NBMA address: 36.1.1.6

注：对于H类型的路由，是新版本的新feature，他把从NHRP学来的路由直接放入路由表，并标记为“H”

本文出自 Frank's Blog

本文链接：DMVPN – Analyzing and Discuss for Phase2,3
版权声明：本文为原创文章，仅代表个人观点，版权归 Frank Zhao 所有，转载时请注明本文出处及文章链接

CCDE, CCIE SEC DMVPN

你可以留言,或者trackback 从你的网站

CCIE Security – VPN 理论«

»DMVPN – Designs

留言哦

返回顶端

『无题』

I persist, therefore I am!!!

Memo

Perseverance sometimes equals genius!
There are only two creatures in the world who can surmount the pyramid:

—–the eagle and the snail.
Useful Link

1. IANA - AFI
2. IANA - SAFI
3. IANA - BGP Ex Comm
4. RPM pbone.net
5. Linux Packages Search
Useful Toots

Linux/http server:

python -m SimpleHTTPServer <port>

python -m http.server <port>

PS: only one thread, if require more threads, can replace by “caddy”.

Win10/http server:

http://www.rejetto.com/hfs/

Win10/md5:

certutil -hashfile .\xxxx MD5
分类目录
- CCDE (16)
- CCIE SEC (4)
- CCIE SP (55)
- CCIE VOICE (3)
- Classical CASE (26)
- Linux (75)
- Mobile Phone (4)
- Programmer (44)
- Solution (2)
- Uncategorized (6)
- Windows常用技术 (10)
- 似水流年 (17)
- 学习笔记 (189)
- 常用资料 (44)
- 网络技术 (39)
近期文章
其他操作

DMVPN – Analyzing and Discuss for Phase2,3

DMVPN的组件

测试Topology

配置DMVPN的步骤及注意事项-Phase2

NHRP抓包分析

Phase3 分析

2014-2-22 更新：问题解决

留言哦

『无题』

Memo

Useful Link

Useful Toots

分类目录

近期文章

其他操作