利用IPSec隧道在Internet上进行安全的数据传输，是目前公司总部与分支通讯的主要解决方案。它的商业价值，这里就不提了，随便找个文档也会侃半天的。
    IPSec网络的拓扑可以是星形结构（hub and spoke）也可以是网状结构（full mesh）。实际应用中，数据流量主要分布在分支与中心之间，分支与分支之间的流量分布较少，所以星形结构（hub and spoke）通常是最常用的，并且它更经济。因为星形结构（hub and spoke）比网状结构（full mesh）使用更少的点到点链路，可以减少线路费用。
    在星形拓扑中，分支机构到分支机构（spoke  to spoke）的连通不需要额外的通讯费用。但在星形结构中，分支到分支的通信必须跨越中心，这会耗费中心的资源并引入延时。尤其在用IPSec加密时，中心需要在发送数据分支的隧道上解密，而在接收数据的分支隧道上重新加密。还有一种情况是：通讯的两个分支在同一个城市，而中心在另一个城市，这便引入了不必要的延时。
    当星形IPSec网络（hub and spoke）规模不断扩展时，传统VPN的配置则愈加繁琐，且不便于维护和排错。因此IP数据包的动态路由将非常有意义。
但IPSec隧道和动态路由协议之间存在一个基础问题，动态路由协议依赖于多播或广播包进行路由更新，而IPSec隧道不支持多播或广播包的加密。
这里便引入了动态多点VPN  （DMVPN）的概念。
这里将引入两个协议：GRE 和 NHRP
    GRE：通用路由封装。由IETF在RFC 2784中定义。它是一个可在任意一种网络层协议上封装任意一个其它网络层协议的协议。GRE将有效载荷封装在一个GRE包中，然后再将此GRE包封装基于实际应用的传输协议上进行转发。（我觉得：GRE类似木马的壳。^_^）
    IPSec不支持广播和组播传输，可是GRE能很好的支持运载广播和组播包到对端，并且GRE隧道的数据包是单播的。这就意味着GRE隧道的数据包是可被IPSec加密的，也即GRE Over IPSec。
通过GRE隧道与IPSec加密相结合，利用动态路由协议在加密隧道两端的路由器上更新路由表。从隧道对端学到的子网在路由表条目里将会包含隧道对端的IP地址作为到达对端子网的下一跳地址。这样，隧道任何一端的网络发生变化，另外一端都会动态地学习到这个变化，并保持网络的连通性而无需改变路由器的配置。
IPSec利用访问控制列表（ACL）来匹配感兴趣数据流。当有数据包匹配所定义的ACL时，IPSec加密隧道便会建立。当利用GRE Over IPSec时，GRE隧道的配置已经包括了GRE隧道对端的地址，这个地址同时也是IPSec隧道的对端地址。所以，没有必要再单独为IPSec定义匹配ACL。通过将GRE隧道与IPSec绑定，GRE隧道一旦建立，将立刻触发IPSec加密。在用IPSec对GRE包进行加密时，可以将IPSec配置为传输模式，因为GRE已经将原始数据包封装为单播的IP包，没必要让IPSec再封装一个包头。
GRE的特点使得IPSec也能时髦的运行动态协议了。至此，IPSec不支持动态路由的历史改变了，DMVPN中的“多点” 被摆平。

接下来，让我们看看“动态”的特性是怎样被引入的？
GRE建立了隧道，IPSec完成了VPN网络的加密部分。想要建立GRE隧道，隧道的一端必须知道另一端的IP地址，并且必须能够在Internet上路由。这就要求中心和所有分支路由器必须具有静态的公共IP地址。
    可是向ISP申请静态IP地址的费用是非常昂贵的。通常，为节约地址资源并提高有效利用率，无论是ADSL还是直接线缆接入，ISP会通过DHCP服务来提供动态IP地址。（注：IPv4的瓶颈引发的地址匮乏。IPv6不会存在该问题，号称可以给地球上的每一粒沙子都分个IP，口气很大的说）
  
    显然，GRE+IPSec需要明确知道隧道两端的IP地址，而分支路由器外网接口的IP地址由其本地ISP动态分配，每次拨入网络的IP地址是不同的。GRE隧道没办法建立，那么VPN还是无法工作。
这样，NHRP在钓足大家胃口之时，应市场需求，在万众期盼的目光中闪亮登场了，给它些掌声乐乐。噼里啪啦。。。。。。。
NHRP：下一跳解析协议。由IETF在RFC 2332中定义。用于解决非广播多路访问（NBMA）网络上的源节点（主机或路由器）如何获取到达目标节点的“下一跳”的互联网络层地址和NBMA子网地址。
    下面咱们一起看看 NHRP 是如何解决静态IP地址问题，而让 VPN “动”起来的：

1、分支到中心（Spoke to Hub）的动态隧道建立

    DMVPN网络中，中心路由器上没有关于分支的GRE或IPSec配置信息，而在分支路由器上则必须依据中心路由器的公网IP地址和NHRP协议来配置GRE隧道。
当分支路由器加电启动时，由ISP处通过DHCP获取IP地址，并自动建立IPSec加密的GRE隧道，通过NHRP向中心路由器注册自己的外网端口IP地址（貌似反弹连接）。
这样做有三方面的原因：1、由于分支路由器外网端口的IP地址是自动获取的，每次上线时的IP地址可能不同，所以中心路由器无法根据该地址信息进行配置。2、中心路由器不必针对所有分支分别配置GRE或IPSec信息，将大大简化中心路由器的配置。所有相关信息可通过NHRP自动获取。（即：分支向中心汇报各自特征）3、当DMVPN网络扩展时，不必改动中心路由器和其它分支路由器的配置。通过动态路由协议，新加入的分支路由器将自动注册到中心路由器。这样，所有其它分支路由器可以学到这条新的路由，新加入的分支路由器也可以学到到达其它所有路由器的路由信息，直至收敛。（中心路由器犹如OSPF的DR）
2、分支到分支（Spoke to Spoke）的动态隧道建立

    在DMVPN网络中，分支到中心（Spoke to Hub）的隧道一旦建立便持续存在，但是各分支之间并不需要直接配置持续的隧道。当一个分支需要向另一个分支传递数据包时，它利用NHRP来动态获取目的分支的IP地址。该过程中，中心路由器充当NHRP服务器的角色，响应NHRP请求，向源分支提供目标分支的公网地址。于是，两个分支之间通过mGRE端口动态建立IPSec隧道，进行数据传输。该隧道在预定义的周期之后将自动拆除。

    DMVPN网络中，分支到中心（Spoke to Hub）的隧道一旦建立便持续存在，而各分支之间并没有持续存在的隧道。这样，在路由器初始化后，中心路由器会通过持续存在的隧道向分支路由器宣告其它分支子网的可达路由。到这里，似乎”多点””动态”的问题都解决了，DMVPN可以正常工作了是吧？！

非也！目前，分支路由器的路由表中到达其它分支子网的“下一跳”地址仍是中心路由器的隧道端口地址，而不是其它分支路由器的隧道端口地址。如此一来，分支与分支之间的数据传输还是会通过中心路由器。
    要解决这一问题，必须在中心路由器上设置为在mGRE隧道端口上宣告某一分支子网的可达路由时“下一跳”地址是该分支路由器的隧道端口地址，而非中心路由器的地址。
    在RIP或EIGRP等距离向量型路由协议中，通常都实现了水平分割（split horizon）功能，阻止将路由信息发回到其来源端口，以避免相邻路由器上路由环路的产生。如果在DMVPN网络上运行RIP或EIGRP协议，则必须关闭水平分割（split horizon）功能。否则，分支路由器将无法学习到通往其它分支子网的路由。
    对RIP而言，no split horizon 就大功告成了，因为RIP向路由信息来源端口发送该路由时，其“下一跳”地址不被改变，仍然是原来的地址（即:目标地址）。
但EIGRP在向路由信息来源端口发送该路由时，其“下一跳”地址将改变为该端口的地址。所以，必须关闭这一特性。(EIGRP是CISCO公司的私有协议，关闭这一特性的IOS命令为no ip next hop self eigrp )。
    OSPF是链路状态型路由协议，其本身就不存在水平分割（split horizon）问题。但在配置OSPF网络类型时，应配置为广播型而不要使用点到多点型，否则，仍然会导致上述的问题。另外需要注意的是，必须把DMVPN的中心路由器（Hub）配置为OSPF的指定路由器（DR），可以通过指定中心路由器（Hub）有更高的OSPF优先权来实现。
最后，总结下DMVPN的整体解决方案
    DMVPN是通过多点GRE（mGRE）和下一跳解析协议（NHRP）与IPSec相结合实现的。在DMVPN解决方案中，利用IPSec实现加密功能，利用GRE或多点GRE（mGRE）建立隧道，利用NHRP解决分支节点的动态地址问题。DMVPN只要求中心节点必须申请静态的公共IP地址。（如果用 DNS 的话，中心节点不是也可以动态了吗？）
    GRE隧道支持多播或广播（multicast/broadcast）IP包在隧道内传输。因此，DMVPN网络支持在IPSec和mGRE隧道之上运行动态路由协议。需要指出的是，NHRP必须被配置为动态多播映射，这样，当分支路由器在NHRP服务器（中心路由器）上注册单播映射地址时，NHRP会同时为这个分支路由器建立一个多播/广播（multicast/broadcast）映射。