Kubernetes网络自学系列 | Linux隧道网络的代表：VXLAN

Posted 2023-01-02 COCOgsta

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Kubernetes网络自学系列 | Linux隧道网络的代表：VXLAN相关的知识，希望对你有一定的参考价值。

素材来源：《Kubernetes网络权威指南》

一边学习一边整理内容，并与大家分享，侵权即删，谢谢支持！

附上汇总贴：Kubernetes网络自学系列 | 汇总_COCOgsta的博客-CSDN博客

1.7 Linux隧道网络的代表：VXLAN

VXLAN（Virtual eXtensible LAN，虚拟可扩展的局域网），是一种虚拟化隧道通信技术。它是一种overlay（覆盖网络）技术，通过三层的网络搭建虚拟的二层网络。RFC7348中是这样介绍VXLAN的：

A framework for overlaying virtualized layer 2 networks over lay 3 networks.

简单来讲，VXLAN是在底层物理网络（underlay）之上使用隧道技术，依托UDP层构建的overlay的逻辑网络，使逻辑网络与物理网络解耦，实现灵活的组网需求。它不仅能适配虚拟机环境，还能用于容器环境。由此可见，VXLAN这类隧道网络的一个特点是对原有的网络架构影响小，不需要对原网络做任何改动，就可在原网络的基础上架设一层新的网络。

不同于其他隧道协议，VXLAN是一个一对多的网络，并不仅是一对一的隧道协议。一个VXLAN设备能通过像网桥一样的学习方式学习到其他对端的IP地址，也可以直接配置静态转发表。

一个典型的数据中心VXLAN网络拓扑图如图1-20所示。

图1-20 VXLAN网络拓扑图

图1-20中的VM指的是虚拟机，Hypervisor指的是节点的虚拟机管理器。VXLAN不仅能用在基于虚拟机的虚拟化系统中，还被广泛应用于容器集群。

1.7.1 为什么需要VXLAN

相信不少读者知道VLAN，VLAN技术的缺陷是VLAN Header预留的长度只有12bit，故最多只能支持2的12次方（4096）子网的划分，无法满足云计算场景下主机数量日益增长的需求。VXLAN能突破VLAN的最多4096个子网的数量限制，以满足大规模云计算数据中心的需求。具体来说，VXLAN技术解决以下几个问题：

·当前VXLAN的报文Header内有24bit，可以支持2的24次方个子网，并通过VNI（Virtual Network Identifier）区分不同的子网，相当于VLAN中的LAN ID；

·多租网络隔离。越来越多的数据中心（尤其是公有云服务）需要提供多租户的功能，不同用户之间需要独立地分配IP和MAC地址。如何保证这个功能的扩展性和正确性是待解决的问题；

·云计算业务对业务灵活性要求很高，虚拟机可能会大规模迁移，并保证网络一直可用，也就是大二层的概念。解决这个问题同时保证二层的广播域不会过分扩大，这也是云计算网络的要求。

传统的二层或三层的网络在应对这些挑战时显得捉襟见肘，虽然很多改进型的技术能够增加二层的范围，但是要做到对网络改动尽量小的同时保证灵活性非常困难。

1.7.2 VXLAN协议原理简介

VXLAN隧道网络方案相比改造传统的二层或三层网络，对原有的网络架构影响小。隧道网络不需要原来的网络做任何改动，可直接在原来的网络基础上架设一层新的网络。

图1-21所示为VXLAN的工作模型，它创建在原来的IP网络（三层）上，只要是三层可达（能够通过IP互相通信）的网络就能部署VXLAN。在VXLAN网络的每个端点都有一个VTEP设备，负责VXLAN协议报文的封包和解包，也就是在虚拟报文上封装VTEP通信的报文头部。物理网络上可以创建多个VXLAN网络，可以将这些VXLAN网络看作一个隧道，不同节点上的虚拟机/容器能够通过隧道直连。通过VNI标识不同的VXLAN网络，使得不同的VXLAN可以相互隔离。

VXLAN的几个重要概念如下：

·VTEP（VXLAN Tunnel Endpoints）：VXLAN网络的边缘设备，用来进行VXLAN报文的处理（封包和解包）。VTEP可以是网络设备（例如交换机），也可以是一台机器（例如虚拟化集群中的宿主机）；

·VNI（VXLAN Network Identifier）：VNI是每个VXLAN的标识，是个24位整数，因此最大值是224=16777216。如果一个VNI对应一个租户，那么理论上VXLAN可以支撑千万级别的租户。

·tunnel：隧道是一个逻辑上的概念，在VXLAN模型中并没有具体的物理实体相对应。隧道可以看作一种虚拟通道，VXLAN通信双方（图中的虚拟机）都认为自己在直接通信，并不知道底层网络的存在。从整体看，每个VXLAN网络像是为通信的虚拟机搭建了一个单独的通信通道，也就是隧道。

图1-21 VXLAN的工作模型

前文提到，VXLAN其实是在三层网络上构建出来的一个二层网络的隧道。VNI相同的机器逻辑上处于同一个二层网络中。VXLAN封包格式如图1-22所示。

图1-22 VXLAN封包格式

VXLAN的报文就是MAC in UDP，即在三层网络的基础上构建一个虚拟的二层网络。为什么这么说呢？VXLAN的封包格式显示原来的二层以太网帧（包含MAC头部、IP头部和传输层头部的报文），被放在VXLAN包头里进行封装，再套到标准的UDP头部（UDP头部、IP头部和MAC头部），用来在底层网络上传输报文。

可以看出，VXLAN报文比原始报文多出了50个字节，包括8个字节的VXLAN协议相关的部分，8个字节的UDP头部，20个字节的IP头部和14个字节的MAC头部。这降低了网络链路传输有效数据的比例，特别是对小包。

需要注意的是，UDP目的端口是接收方VTEP设备使用的端口，IANA（Internet Assigned Numbers Authority，互联网号码分配局）分配了4789作为VXLAN的目的UDP端口。

VXLAN的配置管理使用iproute2包，这个工具是和VXLAN一起合入内核的，我们常用的ip命令就是iproute2的客户端工具。VXLAN要求Linux内核版本在3.7以上，最好为3.9以上，所以在一些旧版本的Linux上无法使用基于VXLAN的封包技术。

1.7.3 VXLAN组网必要信息

总的来说，VXLAN报文的转发过程就是：原始报文经过VTEP，被Linux内核添加上VXLAN包头及外层的UDP头部，再发送出去，对端VTEP接收到VXLAN报文后拆除外层UDP头部，并根据VXLAN头部的VNI把原始报文发送到目的服务器。

以上过程看似并不复杂，但前提是通信双方已经知道所有通信信息。第一次通信之前有以下问题待解决：

·哪些VTEP需要加到一个相同的VNI组？

·发送方如何知道对方的MAC地址？

·如何知道目的服务器在哪个节点上？

第一个问题最好回答，VTEP通常由网络管理员进行配置。另外两个问题可以归结为同一个问题：VXLAN网络的通信双方如何感知彼此并选择正确的路径传输报文？要回答这两个问题，还得回到VXLAN协议报文上，看看一个完整的VXLAN报文需要哪些信息。

·内层报文：通信双方的IP地址已经明确，需要VXLAN填充的是对方的MAC地址，VXLAN需要一个机制来实现ARP的功能；

·VXLAN头部：只需要知道VNI。它一般是直接配置在VTEP上的，即要么是提前规划的，要么是根据内部报文自动生成的；

·UDP头部：最重要的是源地址和目的地址的端口，源地址端口是由系统生成并管理的，目的端口一般固定为IANA分配的4789端口；

·IP头部：IP头部关心的是对端VTEP的IP地址，源地址可以用很简单的方式确定，目的地址是虚拟机所在地址宿主机VTEP的IP地址，需要由某种方式来确定；

·MAC头部：确定了VTEP的IP地址，MAC地址可以通过经典的ARP方式获取，毕竟VTEP在同一个三层网络内。

总结一下，一个VXLAN报文需要确定两个地址信息：内层报文（对应目的虚拟机/容器）的MAC地址和外层报文（对应目的虚拟机/容器所在宿主机上的VTEP）IP地址。如果VNI也是动态感知的，那么VXLAN一共需要知道三个信息：内部MAC、VTEP IP和VNI。

一般有两种方式获得以上VXLAN网络的必要信息：多播和控制中心。多播的概念是同一个VXLAN网络的VTEP加入同一个多播网络。如果需要知道以上信息，就在组内发送多播来查询。控制中心的概念是在某个集中式的地方保存所有虚拟机的上述信息，自动告知VTEP它需要的信息即可。

1.7.4 VXLAN基本配置命令

VXLAN接口的基本管理如下。

1. 创建VXLAN接口

这条命令会创建一个叫作VXLAN0的新接口，它使用在eth0上的多播组239.1.1.1通信。初始化时没有转发表。目的端口号是IANA规定的4789。在VXLAN中，一般将VXLAN接口（在我们的例子中即vxlan0）叫作VTEP（VXLAN tunnel endpoint），VXLAN子网的报文需要从VTEP出去。

多播组主要通过ARP洪泛来学习MAC地址，即在VXLAN子网内广播ARP请求，然后对应节点进行响应。但多播不是VXLAN所必需的，下文会进行解释。

如果网络不复杂，则可以认为某一节点上所有子网IP的MAC和节点上的VTEP的MAC一致，直接用VTEP MAC封装报文。至于VTEP的MAC地址，可以用bridge命令手工配置。

2. 删除VXLAN接口

与普通网络接口一样，ip link delete命令就能删除一个VXLAN接口：

3. 查看VXLAN接口信息

常规命令ip -d link show可以查看VXLAN网卡信息：

4.VXLAN转发表

可以使用bridge命令创建、删除或查看VXLAN接口的转发表。

创建一条转发表项：

00:17:42:8a:b4:05即对端VTEP的MAC地址，192.19.0.2即对端VTEP的IP地址。

删除一条转发表项：

查看VXLAN接口的转发表：

注：网络设备都以MAC地址唯一地标识自己，而交换机要实现设备之间的通信就必须知道自己的哪个端口连接着哪台设备，因此就需要一张MAC地址与端口号一一对应的表，以便在交换机内部实现二层数据转发。这张二层转发表就是FDB表。它主要由MAC地址、VLAN号、端口号和一些标志域等信息组成。如果收到数据帧的目的MAC地址不在FDB地址表中，那么该数据将被发送给除源端口外，该数据包所属VLAN中的其他所有端口。把数据发给其他所有端口的行为称为洪泛。

那么，FDB表是怎么形成的呢？很简单，交换机会在收到数据帧时，提取数据帧中的源MAC、VLAN和接收数据帧的端口，组成FDB表的条目。当下次看到相同VLAN时，相同MAC地址的报文就直接从记录的端口“丢”出去。

1.7.5 VXLAN网络实践

了解了VXLAN必要的背景知识后，我们将通过几个例子说明如何搭建基于VXLAN的overlay网络，顺便阐述上文提到的多播和控制中心这两种方式的原理。

1. 点对点的VXLAN

让我们先从最简单的点对点的VXLAN网络说起。点对点VXLAN即两台机器构成一个VXLAN网络，每台机器上有一个VTEP，VTEP之间通过它们的IP地址进行通信。点对点VXLAN网络拓扑如图1-23所示。

图1-23 点对点VXLAN网络拓扑图

首先，使用ip link命令创建VXLAN接口：

上面这条命令创建了一个名为vxlan0，类型为vxlan的网络接口，一些重要的参数如下：

·id 42：指定VNI的值，有效值在1到224之间；

·dstport：VTEP通信的端口，IANA分配的端口是4789。如果不指定，Linux默认使用8472；

·remote 192.168.1.3：对端VTEP的地址；

·local 192.168.1.2：当前节点VTEP要使用的IP地址，即当前节点隧道口的IP地址；

·dev eth0：当前节点用于VTEP通信的网卡设备，用来获取VTEP IP地址。注意，这个参数和local参数含义相同，读者在使用过程中二选一即可。

执行完之后，系统就会创建一个名字为vxlan0的网卡，可以用ip -d link命令查看它的详细信息：

接下来，为刚创建的VXLAN网卡配置IP地址并启用它：

执行成功后会发现路由表项多了下面的内容，所有目的地址是172.17.1.0/24网段的包要通过vxlan0转发：

同时，vxlan0的FDB表项中的内容如下：

这个表项的意思是，默认的VTEP对端地址为192.168.1.3。换句话说，原始报文经过vxlan0后会被内核添加上VXLAN头部，而外部UDP头的目的IP地址会被冠上192.168.1.3。

在另外一台机器上（192.168.1.3）也进行相同的配置，要保证VNI也是42，dstport也是4789，并修改VTEP的local和remote IP地址到相应的值。测试两个VTEP的连通性，如下所示：

通过点对点组网模型实践了VXLAN网络的基本要点，下面介绍多节点怎么组成VXLAN网络进行通信。

2. 多播模式的VXLAN

要组成同一个VXLAN网络，VTEP必须能感知到彼此的存在。多播组本来的功能就是把网络中的某些节点组成一个虚拟的组，所以VXLAN最初想到用多播来实现是很自然的事情。

注：如果VXLAN要使用多播模式，那么底层的网络结构需要支持多播的功能。

这个实验和前面一个非常相似，只不过主机之间不是点对点的连接，而是通过多播组成一个虚拟的整体。多播模式的VXLAN网络拓扑如图1-24所示。

图1-24 多播模式的VXLAN网络拓扑

虽然加入同一个多播组听起来挺复杂，但实际上使用比较简单，和点对点模型相比就多了group参数，命令如下：

同样，为刚创建的VXLAN网卡配置IP地址并启用它：

这里最重要的参数是group 224.1.1.1，它表示将VTEP加入一个多播组，多播地址是224.1.1.1。

注：多播地址让源设备能够将分组发送给一组设备。属于多播组的设备将被分配一个多播组IP地址，多播地址范围为224.0.0.0~239.255.255.255。

运行上面的命令之后，一样添加了以下路由信息：

不同的是FDB表项的内容：

dst字段的值变成了多播地址224.1.1.1，而不是之前对方的VTEP地址，意思是原始报文经过vxlan0后被内核添加上VXLAN头部，其外部UDP头的目的IP地址会被冠上多播地址224.1.1.1。

同理，对所有需要通信的节点进行上述配置，可以验证它们能否通过172.17.1.0/24网络互相通信。

配置完成之后，VTEP通过IGMP加入同一个多播组224.1.1.1。

我们来分析多播模式下VXLAN通信的全过程：

（1）主机1的vxlan0发送ping报文到主机2的172.17.1.3地址，内核发现源地址和目的IP地址在同一个局域网内。需要知道对方的MAC地址，而本地又没有缓存，故先发送一个ARP查询报文。

（2）ARP报文源MAC地址为主机1上vxlan0的MAC地址。目的MAC地址为255.255.255.255（广播地址），并根据配置添加VXLAN头部VNI=42。

（3）不知道对端VTEP在哪台主机上但又配置了多播组，根据配置，VTEP会往多播地址224.1.1.1发送多播报文。

（4）多播组中所有的主机都会收到这个报文，内核发现是VXLAN报文，根据VNI发送给对应的VTEP。

（5）主机2的VTEP去掉VXLAN头部，取出真正的ARP请求报文。同时，VTEP会记录源MAC地址和IP地址信息到FDB表中，这便是一次学习过程。如果发现ARP不是发送给自己的，则直接丢弃；如果是发送给自己的，则生成ARP应答报文。

（6）应答报文目的MAC地址是发送方VTEP的MAC地址，不需要多播。对端VTEP已经通过源报文学习到了VTEP所在主机的MAC地址，故会直接单播发送给目的VTEP。

（7）应答报文通过底层网络直接返回发送方主机，发送方主机根据VNI把报文转发给VTEP，VTEP解包取出ARP应答报文，添加到VTEP缓存中，并根据报文学习到目的VTEP所在的主机地址，添加到FDB表中。

（8）VTEP双方（隧道网络双方）已经通过一次ARP报文知道了建立ICMP通信需要的所有信息，因此后续的ICMP报文都是在这条逻辑隧道中单播进行的。

总结以上过程：一个VXLAN网络的ping报文要经历ARP寻址+ICMP响应两个过程。当然，VTEP设备学习到对方ARP地址后就可以免去ARP寻址的过程。

3.VXLAN+ 桥接网络

尽管上面的方法能够通过多播实现自动化的overlay网络构建，但是通信的双方只有一个VTEP。在实际生产中，每台主机上都有几十台甚至上百台虚拟机或者容器需要通信，因此需要找到一种方法将这些通信实体组织起来，再经过隧道口VTEP转发出去。

通过前面的介绍我们知道，Linux网桥可以连接多块虚拟网卡，因此可以使用网桥把多个虚拟机或者容器放到同一个VXLAN网络中，VXLAN+网桥的网络拓扑如图1-25所示。

图1-25 VXLAN+网桥的网络拓扑

和上面的多播模式相比，这里只是多了一块网桥，连接同一个主机上的不同容器的veth pair。我们还没有介绍如何创建容器，因此用前面介绍的network namespace代替容器，其实原理都是一样的。我们将创建一个network namespace，并通过一对veth pair将namespace中的eth0网卡连接到网桥。同时，VXLAN网卡也连接到网桥。

首先，创建VXLAN网卡，使用的是多播模式：

然后创建网桥bridge0，把VXLAN网卡vxlan0绑定到上面，并启动它们：

下面创建network namespace和一对veth pair，并把veth pair的其中一端绑定到网桥，然后把另一端放到network namespace并绑定IP地址172.17.1.2：

用同样的方法在另一台主机上配置VXLAN网络，绑定172.17.1.3到另外一个network namespace中的eth0。

从172.17.1.2 ping 172.17.1.3发现整个通信过程和前面的实验类似，只不过容器发出的ARP报文会先经过网桥，再转发给vxlan0；然后在vxlan0处由Linux内核添加VXLAN头部；最后通过多播的方式查询通信对端的MAC地址。

逻辑上，VXLAN网络下不同主机上的network namespace中的网卡被连接到了同一个网桥上。

1.7.6 分布式控制中心

因为并不是所有的网络设备都支持多播，再加上多播方式带来的报文浪费，在实际生产中VXLAN的多播模式很少被采用。

我们来回顾为什么要引入多播。从多播的流程可以看出，其实隧道网络发送报文最关键的就是要知道对方虚拟机/容器的MAC地址及所在主机的VTEP IP地址。对overlay网络来说，它的网段范围是分布在多个主机上的，因此传统ARP报文的广播无法直接使用。要想做到overlay网络的广播，必须把报文发送到所有VTEP在的节点，这才使用了多播。如果能够事先知道MAC地址和VTEP IP信息，直接告诉发送方VTEP，就不需要多播了。

在虚拟机和容器的场景中，当虚拟机或者容器还没有进行网络通信时，我们就可以知道它的IP和MAC（可能是用某种方式获取，也可能是事先控制这两个地址），分布式控制中心保存了这些信息。除此之外，控制中心还保存了每个VXLAN网络的VTEP，以及这些VTEP的地址。有了这些信息，VTEP就能在发送报文时直接查询并添加头部，不需要多播去满网络地“问”。

在分布式控制中心，一般情况下，这种架构在每个VTEP所在的节点都运行一个agent，它会和控制中心通信，获取隧道通信需要的信息并以某种方式告诉VTEP。

下面我们用一个手动配置VTEP组和FDB表的例子结束本节的讨论。

1.7.7 自维护VTEP组

如果有一种方法能够不通过多播，把overlay的广播报文发送给所有的VTEP主机，则也能完成相同的功能。当然，在维护VTEP网络组之前，必须提前知道哪些VTEP要组成一个网络，以及这些VTEP在哪些主机上。在我们创建VXLAN网卡时，不使用remote或group参数就能达成以上目的，例如：

这个VTEP创建时没有指定多播地址，当第一个ARP请求报文发送时，它也不知道要发送给谁，但是我们可以手动添加默认的FDB表项，例如：

如果不知道对方VTEP的地址。内核就会选择默认的FDB表项将网络包发送到192.168.8.101和192.168.8.102，相当于手动维护了一个VTEP的多播组。

在所有节点的VTEP上更新对应的FDB表项，就能实现overlay网络的连通。整个通信流程和多播模式相同，唯一的区别是，VTEP第一次通信时会给所有组内成员发送单播报文，当然也只有一个VTEP会做出应答。

使用一些自动化工具，定时更新FDB表项，就能动态地维护VTEP的拓扑结构。

这个方案解决了在某些underlay网络中不能使用多播的问题，但并没有解决多播的另外一个问题：每次查找MAC地址要发送大量的无用报文，如果VTEP组节点数量很大，那么每次查询都发送N个报文，其中只有一个报文真正有用。

手动维护FDB表项

如果提前知道目的容器的MAC地址和它所在主机的IP地址，则可以通过更新FDB表项来减少广播的报文数量。

这次我们在创建VXLAN设备时添加了nolearning参数，这个参数告诉VTEP不要通过收到的报文学习FDB表项的内容，因为我们自己会进行维护：

然后，添加FDB表项，告诉VTEP容器/虚拟机MAC地址与对应主机IP地址的映射关系：

如果知道了对方的MAC地址，则VTEP搜索FDB表项就知道应该发送到哪个对应的VTEP了。需要注意的是，这个情况还是需要默认的表项（那些全零的表项），在不知道容器IP和MAC的对应关系时，通过默认方式发送ARP报文查询对方的MAC地址。

和上一个方法相比，这个方法并没有任何效率上的提升，只是把自动学习FDB表项换成了手动维护（当然，实际情况一般是由自动化程序来维护），第一次发送ARP请求还是会往VTEP组发送大量单播报文。

这个方法给了我们很重要的提示：如果事先知道VXLAN网络的信息，则VTEP需要的信息都是可以自动维护的，不需要学习。

手动维护ARP表项

除了FDB表项，ARP表项也是可以维护的。如果能通过某个方式知道容器的IP和MAC地址的对应关系，只要更新到每个节点，就能实现网络的连通。

这里有个问题，我们需要维护的是每个容器里的ARP表项，因为最终通信的双方是容器。到每个容器里（所有的network namespace）更新对应的ARP表，是一件工作量很大的事情，而且容器的创建和删除还是动态的。Linux提供了一个解决方案，使VTEP可以作为ARP代理，回复ARP请求。也就是说，只要VTEP知道对应的IP地址和MAC地址的映射关系，在接收到容器发来的ARP请求时就可以直接做出应答。这样的话，我们只需要更新VTEP上的 ARP表项就行了。

下面这条命令和上面的相比多了proxy参数，这个参数告诉VTEP承担ARP代理的功能，即如果收到ARP请求并且知道结果就直接做出应答。

当然，我们还是要手动更新FDB表项来构建VTEP组：

还需要为VTEP添加ARP表项。所有要通信容器的IP地址和MAC地址的映射关系都要加进去：

在要通信的所有节点配置完之后，容器就能互相ping通。当容器要访问彼此，并且第一次发送ARP请求时，这个请求并不会发给所有的VTEP，而是由当前VTEP做出应答，大大减少了网络上的报文。

借助自动化的工具做到实时的表项（FDB和ARP）更新，这种方法能高效实现overlay网络的通信。

动态更新FDB和ARP表项

尽管前一种方法通过动态更新FDB和ARP表项避免了多余的网络报文，但还有一个问题：为了让所有的容器能够正常通信，必须提前添加所有容器到ARP和FDB表项中。因为并不是所有的容器都会互相通信，所以添加的有些表项（尤其是ARP表项）是用不到的。

Linux提供了另外一种方法，使内核能够动态地通知节点要和哪个容器通信，应用程序可以订阅这些事件。如果内核发现需要的ARP或者FDB表项不存在，则会发送事件给订阅的应用程序，这样应用程序可以从内核拿到这些信息更新表项，做到更精确的控制。

要收到L2（FDB）miss，必须满足几个条件：

·目的MAC地址未知，即没有对应的FDB表项；

·FDB中没有全零的表项，即默认规则；

·目的MAC地址不是多播或者广播地址。

要实现这种功能，创建VTEP的时候需要加上额外的参数：

这次多了两个参数l2miss和l3miss：

·l2miss：如果设备找不到MAC地址需要的VTEP地址，就发送通知事件；

·l3miss：如果设备找不到需要IP对应的MAC地址，就发送通知事件。

ip monitor命令能监听某个网卡的事件：

如果从本节点的容器ping另外一个节点的容器，就先发送L3miss，下面就是一个L3miss的通知事件：

l3miss说明了VTEP不知道它对应的MAC地址，因此要手动添加ARP记录，如下所示：

上面这条命令设置的nud reachable参数的意思是，这条记录有一个超时时间，系统发现它无效一段时间后会自动删除，无须用户手动删除。ARP记录被删除后，当需要通信时，内核会再次发送L3 miss通知事件。nud是Neighbour Unreachability Detection的缩写，根据需要这个参数也可以设置成其他值，比如permanent，表示这个记录永远不会过时，系统不会检查它是否正确，也不会删除它。

这时还是不能正常通信，内核出现了L2miss的通知事件：