一、GRE---通用路由封装技术
1、简介
GRE技术全称为通用路由封装技术，主要用于解决私网运行动态路由协议如何在公网中传递的问题，原属于思科私有，现已成为各厂商通用技术
因为GRE搭建的是一个点到点的隧道，所以，导致其扩展性较差（当存在多个私网需要相互连接时，需要彼此之间都搭建GRE隧道才行）
VPN----虚拟专用网络：依靠ISP或者其他公用网络基础设施上构建专用的安全数据通信网络。----只不过这个专用网络是逻辑 而非物理的。
2、案例
要求：源ip为192.168.1.1 24目标为192.168.2.1 24，从r2经过，是不通的，以为r2是公网ISP，
虚拟链路（网段为192.168.3.0/24）使R1和R3相连
封装过程：
虚拟链路并不能发送数据，需要通过物理链路来传输数据，虚拟链路将原数据|1.1|2.1|前面加上一个IP头部（源网段12.0.0.0与目标网段23.0.0.0），变成一个新的IP头部+DATA ，封装完后来到R1，R1查看路由表发现没有23.0.0.0这个网段的路由，然后通过配置的缺省路由将数据包发送给R2，然后R2查看IP头部发现了23.0.0.0网段，通过g0/0/1端口转发，达到R3，到达R3后发现目的网段为自己的接口网段，拆开数据包，查看IP头部里面包含Protocol字段的内容，发现为IP协议，就会交给GRE模块，而GRE模块不能处理，所以GRE内部存在一个字段来交给IP去处理。最后数据包封装就变成了：|新IP|GRE|原IP| 其中原ip为两个私网IP，新ip为两个私网边界设备的出接口IP
配置
[r1]interface Tunnel 0/0/0----创建隧道接口
[r1]Tunnel[0/0/0]ip address 192.168.3.1 24 ---该IP地址必须为私网IF
[r1]Tunnel[0/0/0]tunnel-protocol gre ---定义封装方式
[r1]Tunnel[0/0/0]source 12.0.0.1 ----定义封装内容，该IP必须为真实的公网出口IF
[r1]Tunnel[0/0/0]destination 23.0.0.3
配置完成后，需要在本地补上通往目的私网网段的路由信息
配置
R1
R2
R3
配置GRE
192.168.1.0/24和192.168.2.0/24还不能通讯
配置GRE虚拟出虚拟Tunnel
Tunnel接口共有512个可用接口（0/0/0~0/0/512）
Tunnel的通讯协议不是IP协议而是隧道技术JRE
R1配置
R3 配置
R1的路由表有了Tunnel端口的路由
GRE 封装和解封装过程设备从连接私网的接口接收到数据包后，检查报文头部中的目的IP 地址字段，在路由表中查找出接 口，如果发现出接口为隧道接口，则将报文发送给隧道模块进行处理。隧道模块接收到报文后，首先根据乘客协议的类型和当前GRE 隧道配置的校验和参数，对报文进行GRE封装然后，设备给报文添加新的传输协议，该协议的源 IP 就是隧道源地址，目的 IP 为隧道目的地址 。最后，设备根据新条件的IP 报文头部中的目的地址，在路由表中查找对应的出接口并发送报文。接收端设备从连接公网的接口收到报文后，首先分析IP 报文头部信息，如果发现 协议字段类型值为 47 （ GRE 协议号），表示数据部分由 GRE 模块进行处理。GRE模块去除掉 IP 报文头部和 GRE 报文头部，并根据 GRE 报文头部中的协议类型字段来判断乘客协议内容。从而交给对应模块处理。
keepalive检测机制
配置
二、MGRE
若对上图使用GRE则需要配置六条才能使得R1到R4互通，需要建立12个通道，这样会造成设备资源浪费，同时GRE需要查看两次路由表，这也加大了路由器的负载。
需要将点到点（gre）转换为点到多点（mgre）
在MGRE环境下只有单播，近似于NBMA，点到多点prmp
配置MGRE时候写目标端口IP，动态获取，需要一张表来完成所以希望将表单写成一张动态的表单，类似于ARP缓存表，获取表单的信息，需要对端的路由器向R1发送信息，即IP变更信息或是路由网段变更信息
NHRP---下一跳解析协议
通过NHRP----下一跳解析协议 来完成 为C/S架构
NHS下一跳服务器（R1），中心结点的IP地址必须固定
以MGRE搭建的架构为Hub-spoken架构 Hub---集线器（星型拓扑的中心结点），有一个中心，其他的都是结点，结点结点之间没有连接，都是向中心发送，后再由中心（NHS）转发
配置
R1
R2
R3
R4
R5
测试连通性
配置MGRE
相关配置
Hub 节点配置[r1]interface Tunnel 0/0/0 [r1-Tunnel0/0/0]ip address 192.168.5.1 24[r1-Tunnel0/0/0]tunnel-protocol gre p2mp ---- 修改接口封装协议为 GRE ，且为点到多点模式[r1-Tunnel0/0/0]source 15.0.0.1Spoke 节点配置[r2]interface Tunnel 0/0/0[r2-Tunnel0/0/0]ip address 192.168.5.2 24[r2-Tunnel0/0/0]tunnel-protocol gre p2mp[r2-Tunnel0/0/0]source GigabitEthernet 0/0/0[r2-Tunnel0/0/0]nhrp entry 192.168.5.1 15.0.0.1 registerhub 的虚拟接口 IP hub 的物理接口 IP 注册[r1]display nhrp peer all ---- 查看 nhrp 映射表
以R1为中心路由器（hub），其他非中心路由的原地址均写端口
R1
R2
R3
R4
配置路由
R1
R2
R3
R4
在R1上查看动态关系映射表
可以看到有R2、R3、R4共三条与R1关联的路由
而其他几个路由器均只有一条关联于R1的路由
在R1出接口上抓包： 并在R2上ping -a 192.168.2.1 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报文也是如此
所有路由器都会把数据发送给R1（中心站点）
而现在的中心站点为R1会出现一个问题：一个报文R1的端口就要收发四次数据，要是非中心站点的数据报文多的话，相对于R1而言其负载会变得很大，占据R1的资源，从而影响R1的使用
解决方法：可以添加中心，构建全连接架构（将每个路由器都作为中心）
NHRP协议 --- 下一跳解析协议 ---- 自动学习隧道地址和物理地址的对应关系的一种方法。
原理：需要在私网中选出一个物理接口不会发生变化的作为NHRP的中心（NHS --- 下一跳服务器）。剩下的分支都需要知道中心的隧道IP 和物理接口IP，他们需要将自己的物理接口IP和隧道IP发送给中心
（如果分支的物理接口的IP地址发生变化，则需要立即将对应关系重新发送）。这样，NHS将会收集所有分支的地址映射关系。之后需要通讯时，查看对应关系，封装对应的接口IP地址即可。分支之间需要
进行通讯，则先将数据发给中心，由中心进行转发。
----- 这种中心站点到分支站点的架构 --- HUB-SPOKE架构
因为MAGRE搭建的逻辑拓扑是一个多节点的网络，但是，发送信息时依然是点到点的发送，无法使用广播或者组播行为，所以，这样的网络我们可以称为NBMA网络。（他属于逻辑上搭建出的NBMA网络，真正意义上物理设备搭建出的NBMA网络是帧中继。）
三、DSVPN---动态智能VPN
动态智能隧道技术，简称DSVPN，实现了总部（Hub）与分支（Spoke），分支与分支之间动态建立隧道。解决了在建立隧道时分支动态地址变化的问题。
DSVPN主要是利用MGRE结合NHRP来动态建立隧道的，一般运用在大型网络中
Shortcut方式
Spoke只需要有去Hub的路由（静态或OSPF），不需要有去其它分支的路由，通过Hub来得到其它Spoke的公网IP与Tunnel的对应关系
要注意在使用OSPF时网络类型必须为P2MP方式，不过此种方式更推荐使用静态路由
1910
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
