MGRE GRE DSVPN

        VPN---虚拟专用网络

       依靠ISP或者其他公用网络基础设施上构建专用的安全数据通信网络，只不过这个专用网络是逻辑而非物理的

       虚拟：用户不在需要拥有实际的长途数据线缆，而是使用公共网络资源建立自己的专用网络。

       专用：可以定制最符合自身需求的网络

核心技术：封装技术

GRE---通用路由封装

源是1.1目标是2.1，想要用1.1去访问2.1，要是从R1直接发送给ISP是不通的，通过GRE在R1与R3之间加上一根线，假设给一个192.168.3.0/24的一个私网网段，将R1与R3连接起来

连上之后，IP为3.1的端口与IP为3.2的端口直接相连，相当于在私网直接相连

来到R1，此时需要配置一条虚拟链路路由，而虚拟链路不能发送数据，还是要依靠物理链路，所以现在虚拟链路将原数据|1.1|2.1|前面加上一个IP头部 源网段与目标网段，即|12.0.0.0|23.0.0.0|1.1|2.1|，变成一个新的IP头部+DATA ，然后封装完后来到R1，R1查找路由表发现没有23.0.0.0这个网段的路由，所以通过配置的缺省路由将数据包发送给R2，R2查看IP头部发现目标23.0.0.0这个网段查找路由表发现有这个网段的路由，将其从g0/0/1端口转发出去，从而到达R3，到达R3后发现目的网段为自己的接口网段，就拆开数据包，此时需要考虑DATA部分需要交给哪一个协议来处理，就需要看IP头部里面包含的内容，即Protocol字段，在看到Protocol字段内的内容后，发现为IP协议，就会交给GRE模块，而GRE模块不能处理，所以GRE内部存在一个字段来交给IP去处理。即最终数据包封装就变成了：|新IP|GRE|原IP| 其中原ip为两个私网IP，新ip为两个私网边界设备的出接口IP

所以是一个封装的思路去转发数据

而旧数据前添加一个新数据不是一个加密数据，它是两个完整的数据段粘和到一起的

配置：

配置IP

R1：

int l0

ip ad 192.168.1.1 24

int g0/0/0

ip address 12.0.0.1 24

q

ip route-static 0.0.0.0 0 12.0.0.2

R2：

int g0/0/0

ip ad 12.0.0.2 24

int g0/0/1

ip ad 23.0.0.2 24

R3：

int l0

ip ad 192.168.2.1 24

int g0/0/0

ip ad 23.0.0.3 24

q

ip route-static 0.0.0.0 0 23.0.0.2

配置完成后，除了两个私网之间不能通讯之外，其他的都能通讯

配置GRE，两个路由器直接虚拟出一个接口，然后将两个接口连接起来，在路由器配置的接口是存在的

Tunnel接口一共有512个接口可以使用即0/0/0~0/0/512

Tunnel的通讯协议不是IP协议而是隧道技术JRE

       所以在配置Tunnel时，需要人为配置一下封装协议，将gre贴在原IP前，即|gre|原IP|

       在配置完封装协议后要手工配置协议前的信息，即|新IP|gre|原IP|

       在配置新IP时，一定要是边界路由器的出接口的真实IP地址

R1：

interface Tunnel 0/0/0

ip ad 192.168.3.1 24

tunnel-protocol gre

source 12.0.0.1

destination 23.0.0.3

此时Tunnel的协议层也为UP

R1配置虚拟接口的静态路由

R1：

ip route-static 192.168.2.0 24 192.168.3.2

可以看到其没有加密，且就是添加封装

在R3上配置，注意原和目的不要搞反了

R3：

int t0/0/0

ip ad 192.168.3.2 24

tunnel-protocol gre

source 23.0.0.3

destination 12.0.0.1

q

ip route-static 192.168.1.0 24 192.168.3.1

GRE配置完成

5秒keep包，三次不会就判定断了

keepalive检测机制

       内部相反

R1：

int t0/0/0

keepalive period 2 retry-times 5

MGRE

以R1为核心，对于上面这个图，若使用GRE需要配置六条才能使得R1到R4互通，此时需要建立12个通道，这样会造成设备资源的浪费，同时GRE需要查看两次路由表，这也加大了路由器的负载。

需要将点到点转换为点到多点

在MGRE环境下只有单播，近似于NBMA，点到多点

配置MGRE，时候写目标端口IP，动态获取，需要一张表来完成，需要到哪一个网段，查表查到哪一个端口，可以用静态写，但是现实生活中的公网会改变，不固定，写静态不够灵活，可能现在能用但以后就用不了了。

所以希望将表单写成一张动态的表单，类似于ARP缓存表，获取表单的信息，需要对端的路由器向R1发送信息，即IP变更信息或是路由网段变更信息

通过NHRP----下一跳解析协议 来完成  为C/S架构

       NHS下一跳服务器，中心结点的IP地址必须固定

以MGRE搭建的架构为Hub-spoken架构 Hub---集线器（星型拓扑的中心结点），有一个中心，其他的都是结点，结点结点之间没有连接，都是向中心发送，后再由中心（NHS）转发

配置：

R1：

int l0

ip ad 192.168.1.1 24

int g0/0/0

ip ad 15.0.0.1 24

R2：

int g0/0/0

ip ad 25.0.0.2 24

int l0

ip ad 192.168.2.1 24

R3：

int g0/0/0

ip ad 35.0.0.3 24

int l0

ip ad 192.168.3.1 24

R4：

int g0/0/0

ip ad 45.0.0.4 24

int l0

ip ad 192.168.4.1 24

ISP（R5）：

int g0/0/0

ip ad 15.0.0.5 24

int g0/0/1

ip ad 25.0.0.5 24

int g0/0/2

ip ad 35.0.0.5 24

int g4/0/0

ip ad 45.0.0.5 24

MGRE的shortcut配置

写缺省 让几台设备都指向R5

R1：

ip route-static 0.0.0.0 0 15.0.0.5

R2：

ip route-static 0.0.0.0 0 25.0.0.5

R3：

ip route-static 0.0.0.0 0 35.0.0.5

R4：

ip route-static 0.0.0.0 0 45.0.0.5

测试一下连通性：

配置MGRE

以R1为中心路由，其他非中心路由的原地址均写端口，例g0/0/0

R1：

int t0/0/0

ip address 192.168.5.1 24

tunnel-protocol gre p2mp

source 15.0.0.1

R2：

int t0/0/0

ip ad 192.168.5.2 24

tunnel-protocol gre p2mp

source GigabitEthernet 0/0/0

nhrp entry 192.168.5.1 15.0.0.1 register

R3：

int t0/0/0

ip ad 192.168.5.3 24

tunnel-protocol gre p2mp

source g0/0/0

nhrp entry 192.168.5.1 15.0.0.1 register

R4:

int t0/0/0

ip ad 192.168.5.4 24

tunnel-protocol gre p2mp

source g0/0/0

nhrp entry 192.168.5.1 15.0.0.1 register

配置路由

R1：

ip route-static 192.168.2.0 24 192.168.5.2

ip route-static 192.168.3.0 24 192.168.5.3

ip route-static 192.168.4.0 24 192.168.5.4

R2：

ip route-static 192.168.1.0 24 192.168.5.1

ip route-static 192.168.3.0 24 192.168.5.1

ip route-static 192.168.4.0 24 192.168.5.1

R3:

ip route-static 192.168.1.0 24 192.168.5.1

ip route-static 192.168.2.0 24 192.168.5.1

ip route-static 192.168.4.0 24 192.168.5.1

R4:

ip route-static 192.168.1.0 24 192.168.5.1

ip route-static 192.168.2.0 24 192.168.5.1

ip route-static 192.168.3.0 24 192.168.5.1

完成这些配置后，在R1上查看动态关系映射表

可以看到有R2、R3、R4共三条与R1关联的路由

而其他几个路由器均只有一条关联于R1的路由

在R1出接口上抓包： 并在R2上使用192.168.2.1 ping 192.168.3.1

再来看看R2 的nhrp映射

可以看到R2虽然ping通了R3，但是并没有在本地产生一个nhrp关系的映射

再来看抓包信息，可以看到ping了5次，但是抓到了20个包，就是说R1发每发送一个信息，会出现四个报文，可以看到主要是两个内容:request,reply，而这两个数据信息会重复发送两次，且request只由192.168.2.1向192.168.3.1 发送，reply只由192.168.3.1向192.168.2.1发送，可是为啥一个报文要发送两次呢

发两遍的原因：我们可以点开一个报文查看一下

可以看到第一个request报文的第一个IPv4：发出者是R2，目的是R1（第一个IPv4是，真实发送的，先封装数据的，第二个IPv4是想要发送的）

第二个request报文的发出者是R1，目的是R3

可以得知request报文的数据转向是，R2将request数据报文发送给R1，R1将数据发送给R3，均经过R1的g0/0/0。

至此可以推断出reply报文也是如此，R3将reply数据报文发送给R1，R1将数据发送给R2，均经过R1的g0/0/0。

可以得知：所有路由器都会把数据发送给R1（中心站点）

而现在的中心站点为R1会出现一个问题：一个报文R1的端口就要收发四次数据，要是非中心站点的数据报文多的话，相对于R1而言其负载会变得很大，占据R1的资源，从而影响R1的使用

解决方法：可以添加中心，构建全连接架构

全连接架构：将每个路由器均作为中心

       中心判定：别的路由器会向中心发送注册信息

而多中心会出现每个路由器的性能不一的问题，有的路由器的性能可能不能支持其作为中心路由器

因为分支节点的路由器性能不行，所以还是要经过R1中心的路由器，来回进行转发，会对R1设备资源进行消耗，为了使R1设备资源消耗减少，这样的话就需要一条路径，使得分支节点之间可以直接发送信息即DSVPN技术

MGRE

       GRE发展来的点到多点的技术，但本质还是点到点，近似于nbma（非广播型多路访问技术）形式

       MGRE不支持keepalive检测机制：接收方太多，不知道发给谁

MGRE隧道

       两个接口建立起来的逻辑隧道，逻辑隧道之间包含的元素：隧道原地址（GRE封装的报文原地址）/目的（非手工配置，通过nhrp获取到的）/隧道接口IP

MGRE隧道接口

       用于连接MGRE环境的接口

NHRP映射表

• 静态表项
  1. 由网络管理员手工配置
  2. 只有是spoke与hub之间才能建立的静态隧道
• 动态表项
  1. 是由nhrp协议动态生成的
     1. 生成方式：hub被动获取到spoke结点发送来说的注册信息
     2. 各个spoke结点通过HNRP协议获取到对端的spoke结点的映射关系，从生成的动态映射表
     3. 两种获取动态表项类型
        1. 对于一个分支节点而言，会有一个静态表项（手工配置），分支结点会给中心发送一个消息，告诉中心结点：该分支结点的私网IP与公网IP的对应关系，从而中心结点会构造出一个nhrp的映射表
        2. 一个分支结点主打去向其他的分支结点去要，其入接口IP与路由器后面网段的一个表项，DSVPN的目的就是为了获取这个，分支节点之间的动态表项
        3. 老化时间：7200s

DSVPN---华为的技术----动态智能VPN=MGRE+nhrp

       为了解决中心结点处理数据量大的问题诞生的，为了使得分支直接能够通讯，使得分支之间建立其一条直连隧道

       缺陷：不支持广播与组播，在gre、mgre、dsvpn出现之前，hub-spoke架构就已经出现了，当时为了解决hub-spoke架构的问题使用的是IPSec这个VPN技术，但是这个技术不能应用到hub-spoke架构中，因为IPSec这个技术以组播进行发送，而hub-spoke只能单播发送，所以不支持，于是就有了DSVPN

       传统的MGRE技术存在的问题----分支之间无法直接通讯（源分支无法获取目的分支的公网地址，也就无法建立VPN隧道），导致所有的分支之间的通讯数据只能通过总部HUB设备进行中转

NHRP隧道建立过程（三步）

1. 建立spoke到hub之间的mgre隧道

分支本地具备中心结点的两个信息：私网IP，公网IP地址，由分支结点向中心结点发送注册请求：分支节点向中心结点发送其网段信息与对应的网关信息，中心结点会回复一个同意信息，在中心回复后，中心上才会生成一个分支节点的表项信息

发送两个报文

1. spoke向hub注册请求
2. hub向spoke注册应答

只有第一个报文发送过来，第二个报文回复过去了才会建立mgre隧道

1. 分支间路由学习

DSPVN支持两种分支间路由学习方式：

1. 分支间相互学习路由---下一跳写道对端分支路由---非shortcut方式

每个分支需要学习到所有对端的路由数据，且下一跳为分支本身

1. 分支路由汇聚到总部---下一跳写道中心结点---shortcut方式

下一跳为hub设备

1. 建立spoke与spoke之间的mgre隧道

使用静态配置

配置IP与缺省路由

配置：

R1：

int l0

ip ad 192.168.1.1 24

int g0/0/0

ip ad 15.0.0.1 24

R2：

int g0/0/0

ip ad 25.0.0.2 24

int l0

ip ad 192.168.2.1 24

R3：

int g0/0/0

ip ad 35.0.0.3 24

int l0

ip ad 192.168.3.1 24

R4：

int g0/0/0

ip ad 45.0.0.4 24

int l0

ip ad 192.168.4.1 24

ISP（R5）：

int g0/0/0

ip ad 15.0.0.5 24

int g0/0/1

ip ad 25.0.0.5 24

int g0/0/2

ip ad 35.0.0.5 24

int g4/0/0

ip ad 45.0.0.5 24

写缺省 让几台设备都指向R5

R1：

ip route-static 0.0.0.0 0 15.0.0.5

R2：

ip route-static 0.0.0.0 0 25.0.0.5

R3：

ip route-static 0.0.0.0 0 35.0.0.5

R4：

ip route-static 0.0.0.0 0 45.0.0.5

配置DSVPN

R1：

int t0/0/0

ip ad 192.168.5.1 24

tunnel-protocol gre p2mp

source 15.0.0.1

q

ip route-static 192.168.2.0 24 192.168.5.2

ip route-static 192.168.3.0 24 192.168.5.3

ip route-static 192.168.4.0 24 192.168.5.4

R2：

int t0/0/0

ip ad 192.168.5.2 24

tunnel-protocol gre p2mp

source G0/0/0

nhrp entry 192.168.5.1 15.0.0.1 register

q

ip route-static 192.168.1.0 24 192.168.5.1

ip route-static 192.168.3.0 24 192.168.5.3

ip route-static 192.168.4.0 24 192.168.5.4

R3：

int t0/0/0

ip ad 192.168.5.3 24

tunnel-protocol gre p2mp

source G0/0/0

nhrp entry 192.168.5.1 15.0.0.1 register

q

ip route-static 192.168.1.0 24 192.168.5.1

ip route-static 192.168.2.0 24 192.168.5.2

ip route-static 192.168.4.0 24 192.168.5.4

R4：

int t0/0/0

ip ad 192.168.5.4 24

tunnel-protocol gre p2mp

source G0/0/0

nhrp entry 192.168.5.1 15.0.0.1 register

q

ip route-static 192.168.1.0 24 192.168.5.1

ip route-static 192.168.2.0 24 192.168.5.2

ip route-static 192.168.3.0 24 192.168.5.3

找到一个结点路由器查看其nhrp关系表

发现R2、R3、R4均只有一条信息，R1有三条

此时我们来看看分支结点是如何相互建立nhrp映射表的：

当R4想要去访问R2，即192.168.4.1去访问192.168.2.1，去构造一个新的GRE报文

1.查找路由表，可以看到R4的路由表，想要到192.168.2.1去的接口为Tunnel接口，而去往Tunnel接口就意味着要进行封装，封装就需要查找nhrp的映射表

2.而nhrp的映射表没有关于192.168.2.1的信息，只有关于192.168.5.1，不能封装关于192.168.2.1的信息，但是这个信息又必须被封装，所以只能将现有的封装上去即目标：15.0.0.1 原：45.0.0.4，所以R4会将信息发送给R1，R1收到后会查表并将其转发给R2，同时R1会将关于R2的nhrp关系映射表的内容发送给R4，于是R4在收到R1发送给R4的nhrp报文后，就得到了192.168.5.2-25.0.0.2这个对应关系；在第二次向R2发送数据的时候，就会将数据的目的填成25.0.0.2，这样就不会经过R1了

通告的原因：R1发现了R4的原IP（192.168.5.4）与目的IP（192.168.5.2）在同一个网段内，就会发送

第一次发送如下图所示

在R1的g0/0/0口上抓包看看 使用R2 ping R4

先看看R2上的NHRP映射表：

可以看到R2的nhrp映射表只有一个

开始ping

此时查看R2的映射表：

可以看到R4的映射关系以及学习到了，动态，且通过tunnel隧道获取的

而且还有一条自己的映射，这是其他路由器来问自己要的东西，所以在给其他路由器发送自己路由器的映射时，就会构建出一条自己的映射信息

查看R1 g0/0/0口的抓包信息

可以看到NHRP报文，与ping命令的ICMP报文，来看到前面两个NHRP，这两个NHRP代表了，nhrp表的申请过程：R2在ping时会发送ICMP的报文，同时会发送NHRP的报文（向R1去要R4的对应关系），R1会将ICMP报文给R4发送过去（为了使连接保持，不会断开），此时R1并不会将R4的信息传给R2，此时需要R4的同意，R1会将R2索要R4对应关系的信息告诉R4，然后由R4就会直接给R2通告：R4的对应映射关系，这就需要R4建立一个关于自己的映射信息、

现在再来抓一下包看看，在R4、R3、R1上抓包

并使用R3 ping R4

R1: 可以看到前两个ICMP报文为请求报文，两个ICMP报文为应答报文

点开第一个ICMP报文，为R3发给R1

第二条是R1发送给R4的

第三个ICMP报文为R4给R1发送

第四个的ICMP报文为R1发送给R3

此时就可以推断ping命令的ICMP报文：request由R3到R1，再由R1到R4；reply由R4到R1，再由R1到R4

R3:

来看R3端口的前两个ICMP数据包即request与reply

发现其都经过R1

而后面几个ICMP数据包则是由R3与R4直接进行传输的

           接下来看看NHRP的reply，可以看到其ID与首次发送的ID相同，这是R3在向

R4申请映射关系，而后面的request的id代表的是R4在向R3申请映射的关系

以上就是一种非shortcut方式

再来看看shortcut方式：其他分支站点都要指向中心

配置：与上面配置MGRE配置相同

这里延用的是DSVPN所以就只更改一下

R2：

dis this

undo ip route-static 192.168.3.0 255.255.255.0 192.168.5.3

undo ip route-static 192.168.4.0 255.255.255.0 192.168.5.4

ip route-static 192.168.3.0 255.255.255.0 192.168.5.1

ip route-static 192.168.4.0 255.255.255.0 192.168.5.1

R3：

dis this

undo ip route-static 192.168.2.0 255.255.255.0 192.168.5.2

undo ip route-static 192.168.4.0 255.255.255.0 192.168.5.4

ip route-static 192.168.2.0 255.255.255.0 192.168.5.1

ip route-static 192.168.4.0 255.255.255.0 192.168.5.1

R4

dis this

undo ip route-static 192.168.2.0 255.255.255.0 192.168.5.2

undo ip route-static 192.168.3.0 255.255.255.0 192.168.5.3

ip route-static 192.168.2.0 255.255.255.0 192.168.5.1

ip route-static 192.168.3.0 255.255.255.0 192.168.5.1

将每个Tunnel口的信息清除一下：即关闭打开

R2：

int t0/0/0

sh

undo sh

R3：

int t0/0/0

sh

undo sh

R4：

int t0/0/0

sh

undo sh

此时R2上已完成 只剩下本地静态

工作流程：

       还是使用R4对R2进行访问，原为192.168.4.1 目标为192.168.2.1，查看R4的路由表

可以看到去往192.168.2.0 24网段的路由 下一跳是192.168.0.1接口是T0/0/0口，然后就进行封装

查看nhrp表

看到192.168.5.1 对应的是15.0.0.1

所以将原45.0.0.1 目的15.0.0.1封装上去

此时R4会认为自己封装的是对的网段的信息，就不会去要R2的信息，然后R4将信息发送给R1，R1拆开后看是要发往R2，便查那两个表并转发给R2

由于R4不会去找R1要R2的映射关系，此时就需要R1主动去告诉R4

在R1上抓包 使用R4 ping R2

可以看到抓到的报文都是ICMP报文 没有NHRP

此时发现分支路由器没有去请求NHRP，而中心路由器也没有去更正这个问题

所以现在需要让R1去更正这个问题

需要添加配置 即在R1上开启重定向功能（默认情况下不启动）

R1：

int t0/0/0

nhrp redirect

开启后，hub设备会自行判断，来的源地址与要去的目标地址即第一次未经过

封装的ip：原：192.168.4.1目的：192.168.2.1

R1会通过路由表

发现对于原IP对应的是192.168.5.4这一条映射；目的IP 192.168.2.1对应的是192.168.5.2，。然后R1会下发信息给R4，告诉R4的路径信息是错的，且需要R4向R1去申请R2的映射关系

即R4不主动发R1会提醒R4发送

配置完成

在R1上开启抓包 使用R1 ping R2 可以看到出现了很多条报文

发现还是连着两个request与reply，可以看出R4并没有对R2添加映射关系

点开R1抓包中的NHRP 发现R1给R4发送了提醒，但是R4并没有去请求

后面的NHRP报文也是R1给R4发送的提醒，或是给R2发送的提醒

此时需要在分支路由器上配置 使能shortcut功能

R4：

int t0/0/0

nhrp shortcut

R2：

int t0/0/0

nhrp shortcut

开启成功

然后他们就可以直接进行通讯了

非shortcut用于小型网络

shortcut用于大型网络