网络运输层之(3)GRE协议

Author: Once Day Date: 2024年4月8日

一位热衷于Linux学习和开发的菜鸟，试图谱写一场冒险之旅，也许终点只是一场白日梦…

漫漫长路，有人对你微笑过嘛…

全系列文档可参考专栏：通信网络技术_Once-Day的博客-CSDN博客。

参考文章:

什么是 GRE 隧道？| GRE 协议如何工作 | Cloudflare (cloudflare-cn.com)GRE技术介绍-新华三集团-H3C浅析GRE协议（通用路由封装协议）_gre协商过程-CSDN博客什么是通用路由封装（GRE）？ - 华为 (huawei.com)通用路由封装协议GRE 是什么？ - 知乎 (zhihu.com)通用路由封装协议GRE - 杨灏 - 博客园 (cnblogs.com)GRE VPN 技术原理笔记分享-云社区-华为云 (huaweicloud.com)通用路由封装 - 维基百科，自由的百科全书 (wikipedia.org)GRE Keepalive如何工作 - Cisco解决 GRE 和 IPsec 中的 IPv4 分段、MTU、MSS 和 PMTUD 问题 - Cisco了解GRE隧道Keepalive - Cisco配置 GRETAP 隧道来通过 IPv4 传输以太网帧 Red Hat Enterprise Linux 8 | Red Hat Customer

Portal虚拟网络gretap创建实例与流程分析-CSDN博客Linux下ip link创建gre隧道，为什么会连带创建gretap0和gre0 ？ - 知乎 (zhihu.com)

---

文章目录

网络运输层之(3)GRE协议1. 概述1.1 GRE协议介绍1.2 GRE使用场景1.3 GRE和VPN/IPsec/L2TP/PPTP之间的关系1.4 GRETAP介绍1.5 相关RFC文档

2. 报文格式2.1 GRE报文格式2.2 旧GRE报文格式(RFC1701)区别2.3 GRE隧道对MTU和MSS的影响

3. 工作流程3.1 报文封装和解封装流程3.2 GRE隧道keepalive检测

4. Linux Ubuntu配置GRE接口4.1 Linux内核支持GRE选项配置4.2 Linux上配置GRE接口

5. 总结

1. 概述

1.1 GRE协议介绍

GRE通用路由封装协议（Generic Rrouting Encapsulation）是一种网络协议，主要用于封装不同网络协议的数据包。

这种技术允许数据包在一个异种网络中被传输，即使这些网络原生不支持正在传输的数据包协议。GRE支持对组播报文的封装，这是一些其他隧道技术（如IPsec）无法做到的。GRE可以运行动态路由协议，允许异地设备之间动态地交换路由信息，这对于维护大规模分布式网络的连通性至关重要。GRE本身不提供加密或其他安全保护，因而通常不会单独使用于需要高安全性的环境。

例如，如果一个企业需要在使用不同版本互联网协议（如IPv6与IPv4）的两个局域网（LAN）之间建立连接，而连接这两个网的中间网络仅支持IPv4，那么GRE可以将IPv6的数据包封装在IPv4数据包中进行传输。这样，IPv6的数据包就可以“搭乘”IPv4网络，绕过协议不兼容的问题。

GRE协议的优缺点如下表所示:

优点	缺点
基于IP协议，可以在互联网上使用	隧道模式下封装开销较大，影响效率
支持点对点和点对多点通信	不支持组播和广播(GRE支持组播)
支持多种承载网络，包括IP、MPLS等	配置较为复杂，对网络管理要求较高
采用隧道技术，能够穿越NAT和防火墙	缺乏流量控制和拥塞控制机制
路由可扩展性好，支持动态路由协议	隧道集中终结易形成单点故障和性能瓶颈

1.2 GRE使用场景

GRE 协议有三种主要的应用场景。

（1）多协议本地网络通过单一协议骨干网实现互联。

需求：不同协议的本地网络（如 IP、IPX、AppleTalk 等）需要通过单一协议（通常是 IP）的骨干网进行互联。解决方案：在本地网络的边界路由器上启用 GRE，将不同协议的数据帧封装在 GRE 隧道内，通过骨干网传输。在另一端的边界路由器上解封装，恢复原始的数据帧并转发到目标网络。这样就实现了不同协议网络之间的透明互联。

（2）扩大步数受限网络（如 RIP）的范围。

需求：由于路由协议（如 RIP）的步数限制，导致网络规模受到限制，无法实现大规模网络的互联。解决方案：在需要互联的网络之间建立 GRE 隧道，将 RIP 路由更新报文封装在 GRE 隧道内传输。由于 GRE 隧道本身不增加路由步数，因此可以突破原有的步数限制，实现大规模网络的互联。同时，通过在隧道上配置静态路由或动态路由协议，可以实现隧道两端网络的路由学习和转发。

（3）与 IPsec 结合使用，提供安全的 VPN 服务。

需求：远程接入用户或分支机构需要通过公共网络（如互联网）安全地接入总部网络，并保护数据的机密性和完整性。解决方案：在远程接入设备（如 PC、路由器）和总部网络的 VPN 网关之间建立 GRE over IPsec 隧道。首先，在隧道两端之间协商 IPsec 安全联盟（SA），对 GRE 隧道的数据进行加密和认证。然后，将需要传输的数据封装在 GRE 隧道内，再将 GRE 数据包封装在 IPsec 隧道内进行传输。这样就实现了数据在公共网络上的安全传输，防止了窃听和篡改。

GRE协议虽然传输的流量是不加密的，但可以通过结合IPSec技术，先建立GRE隧道对报文进行GRE封装，然后再建立IPSec隧道对报文进行加密，以保证报文传输的完整性和私密性。下面是一种常见的GRE使用拓扑图:

1.3 GRE和VPN/IPsec/L2TP/PPTP之间的关系

VPN是通过公共网络建立的虚拟专用通信网络的统称，用于连接远程用户、公司分支机构到公司内部网。主要有以下几种类型:

VPDN(Virtual Private Dial Network)：通过PSTN/ISDN等拨号方式接入，主要使用L2TP、PPTP等隧道协议实现。VPRN(Virtual Private Routing Network)：通过IP网络构建，使用GRE或MPLS实现网络层的VPN。VPWS(Virtual Private Wire Service)：通过IP网络模拟传统租用线，提供点到点二层VPN。VPLS(Virtual Private LAN Service)：多点接入的二层VPN，在IP网上延伸局域网。

GRE、L2TP、IPsec、PPTP都是VPN常用的隧道技术，用于在公网上建立点到点的逻辑通道，它们的区别在于:

GRE是通用路由封装协议，用于在两个不同协议的网络间创建未加密的隧道，常与IPsec结合使用。L2TP二层隧道协议，支持认证，多用于远程拨号VPN接入，比PPTP安全性更高。IPsec在IP层对数据进行加密认证，确保安全性，但只能对单播不能对组播加密。PPTP点到点隧道协议，是早期的VPN隧道协议，安全性相对较低。

在典型VPN组网中，GRE/IPsec常用于骨干网的隧道构建，L2TP/PPTP用于接入层用户拨号接入，通过结合使用来构建全面的VPN网络。

例如，GRE和L2TP都是一种隧道协议，但侧重很不同，如下表所示：

	GRE协议	L2TP协议
协议类别	网络协议	用户接入协议
关注领域	只关注网络端的隧道连通	除网络连通外还涉及到用户侧的接入
报文	报文结构比较简单，仅包含GRE头和隧道负载	报文结构复杂，隧道模式下需要封装PPP协议， 网络模式下需要封装以太网帧

1.4 GRETAP介绍

GRETAP (Generic Routing Encapsulation Transparent Aggregation Protocol) 是一种网络协议，用于在以太网链路上透明地聚合和转发数据包。

GRETAP则是GRE的一种变体，专门用于封装以太网帧，主要特点和应用如下:

基于GRE (Generic Routing Encapsulation) 隧道技术，可以在两个以太网交换机之间建立点对点的隧道连接。

通过GRETAP隧道，可以将一个以太网网段扩展到另一个物理位置，实现二层网络的扩展和互联。

支持多种上层协议，如IP、IPX、AppleTalk等，具有很好的兼容性。

提供数据封装和解封装功能，在隧道入口将以太网帧封装在GRE报文中，在隧道出口解封装并还原原始帧。

采用类似于VLAN的标签(Tunnel ID)来标识不同的GRETAP隧道，支持多条隧道并行传输。

主要应用场景包括:连接物理位置分散的局域网、实现数据中心或企业网络二层互联、构建overlay网络等。

与VXLAN、NVGRE等其他隧道协议相比，GRETAP的优势是配置简单、兼容性好，但缺点是隧道数量受限，扩展性不如VXLAN等协议。

GRETAP在某些特定场合下为以太网扩展和互联提供了一种灵活的解决方案，不过随着大二层技术的发展，越来越多的场景开始采用VXLAN等新型隧道协议。

1.5 相关RFC文档

下面是与GRE协议相关的主要RFC文档列表：

RFC 1701 - Generic Routing Encapsulation (GRE)，定义GRE的基本封装格式和协议字段。RFC 1702 - Generic Routing Encapsulation over IPv4 networks，描述如何在IPv4网络上应用GRE封装进行数据传输。RFC 2784 - Generic Routing Encapsulation (GRE)，对GRE进行了扩展和修订，成为新的GRE协议标准规范。RFC 2890 - Key and Sequence Number Extensions to GRE，定义GRE的序号和密钥扩展，用于实现更可靠和安全的GRE隧道传输。RFC 7676 - IPv6 Support for Generic Routing Encapsulation (GRE)，将GRE扩展到IPv6，定义在IPv6网络上应用GRE的封装格式和传输方式。RFC 8086 - GRE-in-UDP Encapsulation，指定将GRE封装在UDP内的方法，解决一些网络对GRE报文的过滤和阻塞问题。

2. 报文格式

2.1 GRE报文格式

GRE报文格式(RFC 2784)如下图所示:

GRE报文分为三个组成部分，每层对应一个协议概念，如下所示：

传输协议头部(Transport Protocol或者Delivery Protocol)，即隧道外部协议，通常是IP报文头部。

封装协议头部(Encapsulation Protocol)，这里就是GRE报文头部，也称为运载协议(Carrier Protocol)

净荷(载荷，Payload Packet)，封装前的报文称为净荷，封装前的报文协议称为乘客协议(Passenger Protocol)。

GRE头部字段解释如下：

字段	长度	描述
C	1 bit	校验和验证。 如果该位为1，表示GRE头插入了校验和（Checksum）字段。 如果该位为0，表示GRE头不包含校验和字段。
K	1 bit	关键字。 如果该位为1，表示GRE头插入了关键字（Key）字段。 如果该位为0，表示GRE头不包含关键字字段。
Recursion	3 bits	用来表示GRE报文被封装的层数。 完成一次GRE封装后将该字段加1，如果封装层数大于3，则丢弃该报文。 该字段的作用是防止报文被无限次的封装。
Flags	5 bits	预留字段。当前必须设为0。
Version	3 bits	版本字段，必须置为0。Version为1是使用在RFC2637的PPTP中。
Protocol Type	16 bits	乘客协议的协议类型，比如0x0800表示IPv4，0x86DD表示IPv6。
Checksum	16 bits	对GRE头及其负载的校验和字段。
Key	31 bits	关键字字段，隧道接收端用于对收到的报文进行验证。

2.2 旧GRE报文格式(RFC1701)区别

RFC2784移除了一些旧GRE协议的字段，如下所示：

Routing Present ®位Strict Source Route (S)位递归控制字段确认号字段

RFC 1701规定的GRE头部格式如下:

RFC 1701的GRE头部字段描述如下:

字段名	位数	描述
C (Checksum Present)	1	校验和标志位。 1: Checksum和Offset字段存在 0: Checksum和Offset字段不存在
R (Routing Present)	1	路由标志位。 1: Routing字段存在 0: Routing字段不存在
K (Key Present)	1	密钥标志位。 1: Key字段存在 0: Key字段不存在
S (Sequence Number Present)	1	序列号同步标志位。 1: Sequence Number字段存在 0: Sequence Number字段不存在
s (Strict Source Route)	1	严格源路由标志位。 1: 严格源路由 0: 宽松源路由
Recur (Recursion Control)	3	控制GRE递归封装的最大层数，0-7。通常为0。
Flags	5	保留，必须为0。
Ver (Version)	3	GRE版本，当前必须为0。
Protocol Type	16	封装在GRE中的协议类型，如0x0800表示IPv4。
Checksum (可选)	16	GRE头部及payload的校验和。
Offset (可选)	16	GRE头部后附加字段的偏移量。
Key (可选)	32	用于身份验证的密钥。
Sequence Number (可选)	32	序列号,用于报文重组和去重。
Routing (可选)	变长	源路由列表，支持严格/宽松源路由。

相比RFC 2784 ，RFC 1701的GRE提供了更多特性，如:

支持源路由选择(R/S位及Routing字段)支持递归封装(Recur字段)支持认证/加密(Key字段)支持排序和去重(Sequence Number)支持校验(Checksum)

这些附加特性也增加了GRE的复杂度和开销，所以在后续的RFC 2784中简化并移除了一些不常用的特性。

2.3 GRE隧道对MTU和MSS的影响

MTU和MSS都是用来限制通过网络传输的数据包最大长度的度量单位：

MTU测量数据包的总大小，包括报文头部(从Ether帧的负载开始计算，比如IP报文头部)。超过 MTU 值的数据包将被分成几段或分解成较小的数据包，使之适合在网络上传输。MSS仅测量有效负载，比如TCP协议的负载，这个会去掉IP和TCP头部的开销。

GRE隧道协议会在数据包原有大小基础上增加几个字节，在数据包的MSS和MTU设置中必须考虑这个因素。

如果MTU设为1500 字节，MSS设为1460 字节，则增加GRE 12字节头部后将导致数据包超过MTU限值：

1460 字节 [有效负载] + 20 字节 [TCP 标头] + 20 字节 [IP 标头] + 12 字节 [GRE 标头+ IP 标头] = 1512字节

因此，数据包将被分段，减慢数据包传递，并增加算力开销，因为超出 MTU 的数据包必须分解然后重新组合。

通过减少 MSS 长度以包含 GRE 标头，可以避免这种情况。

如果将MSS设置为1448而不是1460，那么加上GRE 12字节头部后的数据包不会超过MTU 值 1500：

1448 字节 [有效负载] + 20 字节 [TCP 标头] + 20 字节 [IP 标头] + 12 字节 [GRE 标头+ IP 标头] = 1500 字节

尽管避免了分段，但结果却是有效载荷变小，这意味着需要额外的数据包来传递数据，并增加毫秒级的数据传输延迟。不过，使用 GRE 比不使用 GRE 可以使这些数据包选择更快的网络路径，进而可以弥补损失的时间。

3. 工作流程

3.1 报文封装和解封装流程

GRE报文传输流程示意图如下:

上述流程以一个Ping Request报文为例子，介绍了如何从10.10.4.0/24网络里通过Gre0和Gre1这对GRE隧道到达10.10.6.0/24网络。

主机A创建ICMP REQUEST报文，源IP为主机A的IP(10.10.4.4)，目的IP为主机B的IP(10.10.6.6)。主机A将此ICMP报文发送给网络A的网关设备(Device A)。网关设备Device A从物理接口(Eth0)收到这个ICMP报文后，通过路由查找，发现其下一跳地址是Gre0接口(隧道接口)。报文进入网关设备Device A的Gre0接口，开始创建GRE头部:

Protocol Type字段设为0x0800，表示封装的是IPv4报文其他字段如Checksum、Key、Sequence Number等根据配置添加。GRE头部添加在原始的ICMP报文之前。 Gre0接口给报文创建新的IP头部:

源IP为Gre0接口的local IP(本端地址)。目的IP为Gre0接口的remote IP(对端地址)。协议字段设为47，表示这是一个GRE封装报文。新的IP头部添加在GRE头部之前。 网关设备Device A通过路由查找(查找6.6.6.7的下一跳地址)，将此GRE over IP报文从相应的物理接口(Eth0)发送出去。GRE报文通过公网到达另一端网关设备Device B。网关设备Device B剥离外层IP头，根据协议字段47判断这是一个GRE报文，然后送入Gre1隧道接口里解封装处理。网关设备Device B的Gre1隧道接口会剥离报文的GRE头部，根据Protocol Type 0x0800判断内层是一个IPv4报文。现在Device B得到了原始的ICMP REQUEST报文，它根据报文的目的IP(查找10.10.6.6的下一跳)，将其转发给Host B。Host B收到ICMP REQUEST报文，并回复ICMP REPLY报文。ICMP REPLY报文将再次通过GRE隧道返回给Host A，流程与请求方向类似。

整个过程可以概括为：原始IP报文被添加上GRE头部、新的IP头部，形成GRE over IP的封装报文，通过隧道传输。隧道出口解封装，得到原始IP报文，再转发给目的主机。

需要注意，Gre接口需要配置路由条目才能将流量导入到接口中，路由的下一跳地址为Gre接口的私网地址，而不是local/remote等公网地址。

3.2 GRE隧道keepalive检测

通用路由封装（GRE）的Keepalive功能是一种网络协议机制，旨在确保网络连接的持续性和可靠性。在GRE隧道中，Keepalive机制通过定期发送探测消息来检测和维持隧道两端的活动状态。

避免形成数据黑洞，Keepalive检测功能用于在任意时刻检测隧道链路是否处于Keepalive状态，即检测隧道对端是否可达。如果对端不可达，隧道连接就会及时关闭，避免形成数据空洞。定期探测，Keepalive检测功能开启后，GRE隧道本端会定期(例如，每次间隔5秒)向对端发送Keepalive探测报文。若对端可达，则本端会收到对端的回应报文，若对端不可达，则收不到对端的回应报文。支持单端启用，如果在隧道一端配置了Keepalive功能，无论对端是否配置Keepalive，配置的Keepalive功能在该端都生效；隧道对端收到Keepalive探测报文，无论是否配置Keepalive，都会给源端发送一个回应报文。

GRE的keepalive探测包构成如下:

内层IP头：源IP为隧道目的端IP，目的IP为隧道源端IP。内层GRE头，协议类型PT字段为0。外层IP头和GRE头，封装原始的keepalive包，用于在公网上传输。

隧道对端接收到keepalive包后，会解封装，检查内层GRE头的PT字段。若为0，则识别为keepalive包，并丢弃它，同时重置keepalive计数器。

4. Linux Ubuntu配置GRE接口

4.1 Linux内核支持GRE选项配置

Linux 内核支持GRE接口需要启用以下相关配置。

功能	配置宏	描述
GRE 隧道支持	CONFIG_NET_IPGRE	启用通用 GRE 隧道支持,是使用 GRE 的基础。
GRE 隧道设备支持	CONFIG_NET_IPGRE_DEMUX	启用此选项可以支持多个 GRE 隧道设备，每个设备可以单独配置。
GRE 广播和组播支持(可选)	CONFIG_NET_IPGRE_BROADCAST	启用 GRE 隧道的广播和组播支持,允许 GRE 隧道传输广播和组播数据包。
Netfilter 连接跟踪支持(可选)	CONFIG_NF_CT_PROTO_GRE	如果需要对 GRE 数据包进行连接跟踪和状态检查(如防火墙规则)，则需要启用此选项。
GRE IPv6报文支持	CONFIG_IPV6_GRE	启用GRE over IPv6支持。
IP 隧道驱动程序(可选)	CONFIG_NET_IPIP	虽然此选项主要用于 IPIP 隧道，但某些 GRE 实现可能也依赖于它。

在 Linux 内核的 make menuconfig 配置界面中，这些选项通常位于以下位置:

Networking support --->

Networking options --->

[*] IP: GRE demultiplexer

[*] IP: broadcast GRE over IP

-*- The IPv6 protocol --->

[*] IPv6: GRE demultiplexer

[*] IPv6: broadcast GRE over IPv6

Device Drivers --->

[*] Network device support --->

<*> IP: GRE over IP

<*> IPv6: GRE over IPv6

<*> IP: IPIP tunnel

Netfilter Configuration --->

[*] IP virtual reassembly in netfilter

[M] "conntrack" connection tracking match support

[M] "conntrack" connection tracking match support for GRE

在实际运行的ubuntu服务器上，可以检查/boot目录下配置文件，如下:

onceday@ubuntu1:~$ cat /boot/config-5.15.0-100-generic |grep GRE

CONFIG_NET_IPGRE_DEMUX=m

CONFIG_NET_IPGRE=m

CONFIG_NET_IPGRE_BROADCAST=y

CONFIG_IPV6_GRE=m

CONFIG_NF_CT_PROTO_GRE=y

CONFIG_OPENVSWITCH_GRE=m

在这台ubuntu设备上，可以看到相关的GRE功能Linux内核都已经支持了。

4.2 Linux上配置GRE接口

测试和验证GRE功能需要两台Linux服务器，这里使用VirtualBox的虚拟机来搭建环境(3.1节报文封装和解封装流程所示拓扑)。

(1) 在服务器ubuntu1和ubuntu2上配置物理接口enp0s9(或者其他接口)的地址，两者之间要能Ping通(内部网络或者网卡桥接)。

# ubuntu1配置6.6.6.6/24地址

onceday@ubuntu1:~$ ip link set enp0s9 up

onceday@ubuntu1:~$ ip addr add 6.6.6.6/24 dev enp0s9

# ubuntu2配置6.6.6.7/24地址

onceday@ubuntu1:~$ ip link set enp0s9 up

onceday@ubuntu2:~$ ip addr add 6.6.6.7/24 dev enp0s9

# 两者之间可以Ping通

onceday@ubuntu1:~$ ping 6.6.6.7

PING 6.6.6.7 (6.6.6.7) 56(84) bytes of data.

64 bytes from 6.6.6.7: icmp_seq=1 ttl=64 time=0.807 ms

(2) 在两个服务器上分别配置GRE虚拟子接口，local和remote就是enp0s9接口的IP地址。

创建GRE隧道接口，gre1是隧道接口名称，remote指定对端隧道IP，local指定本端隧道IP，ttl设置封装包的TTL。

ip tunnel add gre1 mode gre remote 6.6.6.7 local 6.6.6.6 ttl 255

配置隧道接口的IP地址。

ip addr add 10.10.5.1/30 dev gre1

启用隧道接口。

ip link set gre1 up

配置路由，将相应网段的流量引导到GRE隧道上。

ip route add 10.10.0.0/16 dev gre1

服务器ubuntu1配置操作输出信息如下:

onceday@ubuntu1:~$ ip tunnel add gre1 mode gre remote 6.6.6.7 local 6.6.6.6 ttl 255

onceday@ubuntu1:~$ ip addr add 10.10.5.1/30 dev gre1

onceday@ubuntu1:~$ ip link set gre1 up

onceday@ubuntu1:~$ ip route add 10.10.0.0/16 dev gre1

onceday@ubuntu1:~$ ip addr

4: enp0s9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000

link/ether 08:00:27:93:6f:37 brd ff:ff:ff:ff:ff:ff

inet 6.6.6.6/24 scope global enp0s9

valid_lft forever preferred_lft forever

inet6 fe80::a00:27ff:fe93:6f37/64 scope link

valid_lft forever preferred_lft forever

8: gre1@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1476 qdisc noqueue state UNKNOWN group default qlen 1000

link/gre 6.6.6.6 peer 6.6.6.7

inet 10.10.5.1/30 scope global gre1

valid_lft forever preferred_lft forever

inet6 fe80::606:606/64 scope link

valid_lft forever preferred_lft forever

最终可以看到gre1接口上面有接口IP(10.10.5.1)，这个IP用于流量引流的下一跳地址。

同理完成ubuntu2的配置操作：

onceday@ubuntu2:~$ ip tunnel add gre1 mode gre remote 6.6.6.6 local 6.6.6.7 ttl 255

onceday@ubuntu2:~$ ip addr add 10.10.5.2/30 dev gre1

onceday@ubuntu2:~$ ip link set gre1 up

onceday@ubuntu2:~$ ip route add 10.10.0.0/16 dev gre1

onceday@ubuntu2:~$ ip addr

3: enp0s9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000

link/ether 08:00:27:56:7b:06 brd ff:ff:ff:ff:ff:ff

inet 6.6.6.7/24 scope global enp0s9

valid_lft forever preferred_lft forever

inet6 fe80::a00:27ff:fe56:7b06/64 scope link

valid_lft forever preferred_lft forever

7: gre1@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1476 qdisc noqueue state UNKNOWN group default qlen 1000

link/gre 6.6.6.7 peer 6.6.6.6

inet 10.10.5.2/30 scope global gre1

valid_lft forever preferred_lft forever

inet6 fe80::606:607/64 scope link

valid_lft forever preferred_lft forever

完成以上配置之后，可以尝试进行ping操作，并且用TCP抓包看看GRE隧道报文。

onceday@ubuntu1:~$ ping 10.10.5.2

PING 10.10.5.2 (10.10.5.2) 56(84) bytes of data.

64 bytes from 10.10.5.2: icmp_seq=1 ttl=64 time=0.810 ms

64 bytes from 10.10.5.2: icmp_seq=2 ttl=64 time=0.991 ms

......

下面是对enp0s9接口抓包，可以看到外层报文和内层报文交互情况：

onceday@ubuntu1:~$ sudo tcpdump -vv -i enp0s9

tcpdump: listening on enp0s9, link-type EN10MB (Ethernet), snapshot length 262144 bytes

17:19:29.285962 IP (tos 0x0, ttl 255, id 4763, offset 0, flags [DF], proto GRE (47), length 108)

6.6.6.6 > 6.6.6.7: GREv0, Flags [none], length 88

IP (tos 0x0, ttl 64, id 1897, offset 0, flags [DF], proto ICMP (1), length 84)

ubuntu1 > 10.10.5.2: ICMP echo request, id 7, seq 1, length 64

17:19:29.286757 IP (tos 0x0, ttl 255, id 10776, offset 0, flags [DF], proto GRE (47), length 108)

6.6.6.7 > 6.6.6.6: GREv0, Flags [none], length 88

IP (tos 0x0, ttl 64, id 65215, offset 0, flags [none], proto ICMP (1), length 84)

10.10.5.2 > ubuntu1: ICMP echo reply, id 7, seq 1, length 64

到此，GRE隧道接口测试就完成了，操作很简单，重点是理解GRE报文的传输流程。

5. 总结

GRE协议比较简单，但是具体的报文传输流程和路由寻路就比较难以理解。对于终端，需要设置一个GRE接口，同时配置Local IP和remote IP，这两个IP用于封装GRE报文的外层IP头。

此外，GRE接口本身还需要一个接口IP，注意这个接口IP不能直接作为外部设备的下一跳(NextHop)，因为这是一个三层虚接口，没有MAC等链路层地址，所有是无法作为邻居表项存在的。

在终端上，需要对应的物理接口IP完成外部路由过程，而GRE接口IP，主要用于将物理接口的入流量(即准备进行封装的报文)导入到GRE接口中。

对于出流量(即准备进行解封的报文)，则不需要依赖路由导入，而是在解析IP协议时就可以分流到GRE模块中处理。所以GRE两个方向的流量路径是不一致的，这个一开始可能不好理解，建议多多手动实践来理解。

Once Day

也信美人终作土，不堪幽梦太匆匆......

如果这篇文章为您带来了帮助或启发，不妨点个赞👍和关注，再加上一个小小的收藏⭐！

(｡◕‿◕｡)感谢您的阅读与支持~~~