云原生虚拟网络之 VXLAN 协议

发表于 2年以前 | 总阅读数：373 次

第一次认识 VXLAN 是在看 k8s 里面用到的叫 flannel 的网络插件有个 VXLAN 模式，利用它实现了 Overlay Network（覆盖网络），可以把所有容器连通在一起。所以本篇文章，我们一起来看看 VXLAN 是怎么将不同容器之间的网络进行打通的。

概述

在看 VXLAN 之前，我们先来看看它的前辈 VLAN。VLAN 的全称是“虚拟局域网”（Virtual Local Area Network），它是一个二层（数据链路层）的网络，用来分割广播域，因为随着计算机的增多，如果仅有一个广播域，会有大量的广播帧（如 ARP 请求、DHCP、RIP 都会产生广播帧）转发到同一网络中的所有客户机上。

这样造成了没有必要的浪费，一方面广播信息消耗了网络整体的带宽，另一方面，收到广播信息的计算机还要消耗一部分CPU时间来对它进行处理。造成了网络带宽和CPU运算能力的大量无谓消耗。

在这种情况下出现了 VLAN 技术。这种技术可以把一个 LAN 划分成多个逻辑的 VLAN ，每个 VLAN 是一个广播域，VLAN 内的主机间通信就和在一个 LAN 内一样，而 VLAN 间则不能直接互通，广播报文就被限制在一个 VLAN 内。如下图所示。

然而 VLAN 有两个明显的缺陷，第一个缺陷在于 VLAN Tag 的设计，定义 VLAN 的 802.1Q规范是在 1998 年提出的，只给 VLAN Tag 预留了 32 Bits 的存储空间，其中只有12 Bits 才能用来存储 VLAN ID。当云计算数据中心出现后，即使不考虑虚拟化的需求，单是需要分配 IP 的物理设备都有可能数以万计甚至数以十万计，这样 4096 个 VLAN 肯定是不够用的。

VLAN 第二个缺陷在于它本身是一个二层网络技术，但是在两个独立数据中心之间信息只能够通过三层网络传递，云计算的发展普及很多业务有跨数据中心运作的需求，所以数据中心间传递 VLAN Tag 又是一件比较麻烦的事情；并且在虚拟网络中，一台物理机会有多个容器，容器与 VM 相比也是呈数量级增长，每个虚拟机都有独立的 IP 地址和 MAC 地址，这样带给交换机的压力也是成倍增加。

基于上面种种原因，VXLAN 也就呼之欲出了。

VXLAN 协议

协议报文

VXLAN（Virtual eXtensible LAN）虚拟可扩展局域网采用 L2 over L4 （MAC in UDP）的报文封装模式，把原本在二层传输的以太帧放到四层 UDP 协议的报文体内，同时加入了自己定义的 VXLAN Header。在 VXLAN Header 里直接就有 24 Bits 的 VLAN ID，同样可以存储 1677 万个不同的取值，VXLAN 让二层网络得以在三层范围内进行扩展，不再受数据中心间传输的限制。VXLAN 工作在二层网络（ IP 网络层），只要是三层可达（能够通过 IP 互相通信）的网络就能部署 VXLAN 。VXLAN 的整个报文结构如图：

上图我们可以看到 VXLAN 报文对原始 Original Layer2 Frame 进行了包装：

• VXLAN Header 8字节，其中包含24Byte 的 VNI 字段，用来定义VXLAN网络中不同的租户，可以存储 1677 万个不同的取值；
• UDP Header，其中 VXLAN 头和原始以太帧一起作为 UDP 的数据，头中目的端口号（VXLAN Port）固定为4789，源端口按流随机分配（通过 MAC，IP，四层端口号进行 hash 操作），这样可以更好的做 ECMP。；
• Outer IP Header 封装外层IP头，封装了目的IP地址和源IP地址，这里 IP 指的是宿主机的 IP 地址；
• Outer MAC Header 封装外层以太头，封装了源MAC地址，目的MAC地址，这里 MAC 地址指的是宿主机 MAC 地址；

工作模型

从上面图 VXLAN 网络网络模型中我们可以发现 VXLAN 网络中出现了以下几个组件：

• VTEP（VXLAN Tunnel Endpoints，VXLAN隧道端点）：VXLAN 网络的边缘设备，是 VXLAN 隧道的起点和终点，负责 VXLAN 协议报文的封包和解包，也就是在虚拟报文上封装 VTEP 通信的报文头部。。VTEP 可以是网络设备（比如交换机），也可以是一台机器（比如虚拟化集群中的宿主机）；
• VNI（VXLAN Network Identifier）：前文提到，以太网数据帧中VLAN只占了12比特的空间，这使得VLAN的隔离能力在数据中心网络中力不从心。而 VNI 的出现，就是专门解决这个问题的。一般每个 VNI 对应一个租户，并且它是个 24 位整数，也就是说使用 VXLAN 搭建的公有云可以理论上可以支撑最多1677万级别的租户；
• VXLAN 隧道：隧道是一个逻辑上的概念，在 VXLAN 模型中并没有具体的物理实体想对应。隧道可以看做是一种虚拟通道，VXLAN 通信双方（图中的虚拟机）认为自己是在直接通信，并不知道底层网络的存在。从整体来说，每个 VXLAN 网络像是为通信的虚拟机搭建了一个单独的通信通道，也就是隧道；

通信过程

VXLAN 网络中通常 VTEP 可能会有多条隧道，VTEP 在进行通信前会通过查询转发表 FDB 来确定目标 VTEP 地址，转发表 FDB 用于保存远端虚拟机/容器的 MAC 地址，远端 VTEP IP，以及 VNI 的映射关系，而转发表通过泛洪和学习机制来构建。目标MAC地址在转发表中不存在的流量称为未知单播（Unknown unicast）。VXLAN 规范要求使用 IP 多播进行洪泛，将数据包发送到除源 VTEP 外的所有 VTEP。目标 VTEP 发送回响应数据包时，源 VTEP 从中学习 MAC 地址、VNI 和 VTEP 的映射关系，并添加到转发表中。

下面我们看看首次通信过程看看 VTEP 是如何学习的：

1. 由于是首次进行通信，VM-A 上没 VM-B 的 MAC 地址，所以会发送 ARP 广播报文请求 VM-B 的 MAC 地址。VM-A 发送源 MAC 为 VM-B 、目的 MAC 为全F、源 IP 为 IP-A、目的 IP 为 IP-B 的 ARP 广播报文，请求VM-B 的 MAC 地址；

2. VTEP-1 收到 ARP 请求后，根据二层子接口上的配置判断报文需要进入 VXLAN 隧道。VTEP-1 会对报文进行封装，封装的外层源 IP 地址为本地 VTEP（VTEP-1）的 IP 地址，外层目的 IP 地址为对端 VTEP（VTEP-2 和VTEP-3）的 IP 地址；外层源 MAC 地址为本地 VTEP 的 MAC 地址，而外层目的 MAC 地址为去往目的 IP 的网络中下一跳设备的 MAC 地址；

3. 报文到达VTEP-2和VTEP-3后，VTEP对报文进行解封装，得到VM-A发送的原始报文。然后 VTEP-2 和 VTEP-3 根据二层子接口上的配置对报文进行相应的处理并在对应的二层域内广播。VM-B 和 VM-C 接收到 ARP 请求后，比较报文中的目的IP地址是否为本机的IP地址。VM-C 发现目的IP不是本机IP，故将报文丢弃；VM-B 发现目的IP是本机IP，则对ARP请求做出应答；

4. VM-B 会根据请求的 ARP 包进行 ARP 应答报文为单播报文，报文源 MAC 为MAC-B，目的 MAC 为 MAC-A，源 IP 为 IP-B 、目的 IP 为 IP-A；

5. VTEP-2 接收到 VM-B 发送的 ARP 应答报文后，识别报文所属的 VNI，VTEP-2 对报文进行封装。封装的外层源IP地址为本地 VTEP（VTEP-2）的 IP 地址，外层目的IP地址为对端 VTEP（VTEP-1）的IP地址；外层源MAC地址为本地 VTEP 的 MAC 地址，而外层目的MAC地址为去往目的IP的网络中下一跳设备的MAC地址；

6. 报文到达 VTEP-1 后，VTEP-1 对报文进行解封装，得到 VM_B 发送的原始报文。同时，VTEP-1 学习VM_B 的MAC地址、VNI 和远端 VTEP 的IP地址（IP-2）的对应关系，并记录在本地 MAC 表中。之后，VTEP-1 将解封装后的报文发送给VM-A；

7. 至此，VM-A 就收到了 ARP 广播报文响应 VM-B 的 MAC 地址；

除了上面这种多播的方式进行学习的方式来获取 MAC <--> VNI <--> VTEP IP这一组映射关系以外还有一种方式，就是分布式的控制中心。

例如 Flannel 的 VXLAN 模式网络中的 VTEP 的 MAC 地址并不是通过多播学习的，而是通过 apiserver 去做的同步（或者是etcd）。每个节点在创建 Flannel 的时候，各个节点会将自己的VTEP信息上报给 apiserver，而apiserver 会再同步给各节点上正在 watch node api 的 listener(Flanneld)，Flanneld 拿到了更新消息后，再通过netlink下发到内核，更新 FDB（查询转发表）表项，从而达到了整个集群的同步。这个 apiserver 就起到了分布式的控制中心的作用，不再需要发送多余的请求去满网络访问获取对应的映射信息。

一个例子

下面，我们自己动手弄一个 VXLAN 网络，然后抓包看一下，是不是和我们上面长篇大论讲述的结论是一致的。需要注意的是，在自己虚拟机上实验的时候，为了避免不必要的麻烦，记得关防火墙，centos命令是：systemctl stop firewalld

下面我们打算用 docker 来进行实验，思路就是在两个容器宿主机上各创建一个VXLAN接口，并且将VXLAN接口接入docker网桥的端口上，如下图：

对于 docker 来说，是无法直接跨节点通信的，我们这里使用 VXLAN 来模拟跨节点通信。

docker 默认使用的是 172.17.0.0/16 网段，docker容器的IP地址都会从 172.17.0.2 开始分配。为了能利用--ip参数自定义IP地址的功能，需要先创建一个自定义网络，指定网段172.18.0.0/16。

[root@localhost ~]# docker network create --subnet 172.18.0.0/16 mynetwork

## mynetwork 新的bridge网络被创建
[root@localhost ~]# docker network ls
NETWORK ID     NAME        DRIVER    SCOPE
eb07bfe03ee3   bridge      bridge    local
7014433d34cf   host        host      local
87133e370c6c   mynetwork   bridge    local
82472e531205   none        null      local

我们还可以看到 docker 为我们新的网络创建了一个新的网桥：

[root@localhost ~]# brctl show
bridge name     bridge id               STP enabled     interfaces
br-87133e370c6c         8000.0242233b251a       no              veth385f866
                                                        vxlan_docker
docker0         8000.024213087f4b       no

创建一个新的容器，如下：

## VM1
[root@localhost ~]# docker run -itd --net mynetwork --ip 172.18.0.10 centos
## VM2
[root@localhost ~]# docker run -itd --net mynetwork --ip 172.18.0.11 centos

--net指定自定义网络
--ip指定IP地址
centos指定image

上面我们虽然创建好了网络，但是我们直接进去是无法通信的：

[root@localhost ~]#  docker exec -it 5a2e519610bb /bin/bash

[root@5a2e519610bb /]# ping  172.18.0.11
PING 172.18.0.11 (172.18.0.11) 56(84) bytes of data.
From 172.18.0.10 icmp_seq=1 Destination Host Unreachable

--- 172.18.0.11 ping statistics ---
11 packets transmitted, 0 received, +8 errors, 100% packet loss, time 10007ms
pipe 4

下面我们在两个容器宿主机上各创建一个VXLAN接口，并且将VXLAN接口接入docker网桥的端口上：

## VM1
[root@localhost ~]#  ip link add vxlan_docker type vxlan id 200 remote 192.168.13.132 dstport 4789 dev ens33
[root@localhost ~]#  ip link set vxlan_docker up
[root@localhost ~]#  brctl addif br-87133e370c6c vxlan_docker

## VM2
[root@localhost ~]#  ip link add vxlan_docker type vxlan id 200 remote 192.168.13.131 dstport 4789 dev ens33
[root@localhost ~]#  ip link set vxlan_docker up
[root@localhost ~]#  brctl addif br-26d918129b18 vxlan_docker

上面我们分别使用 ip link add为 VM1 和 VM2 分别创建了创建 VNI 为200的 VXLAN 网络接口，名称为vxlan_docker；然后使用 brctl addif 把新创建的VXLAN接口vxlan_docker接入到 docker 网桥中。

然后我们进入到容器中发现可以 ping 通了：

[root@5a2e519610bb /]# ping  172.18.0.11
PING 172.18.0.11 (172.18.0.11) 56(84) bytes of data.
64 bytes from 172.18.0.11: icmp_seq=1 ttl=64 time=1.14 ms
64 bytes from 172.18.0.11: icmp_seq=2 ttl=64 time=0.620 ms
^C
--- 172.18.0.11 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 0.620/0.879/1.139/0.261 ms

下面在宿主机上抓包看看：

[root@localhost ~]#  tcpdump -i ens33 host 192.168.13.131 -s0 -v -w vxlan_vni_1.pcap

上面我们看到，首先是发送出 ARP 请求获取 MAC 地址，外层是 UDP 报文，目的端口是4789，目的 IP 是宿主机 VM2 的 IP；VXLAN 报文头 VNI 是200 ；ARP 请求源 MAC 地址是 VM1 里面发送消息的容器 MAC 地址，目的地址没有获取到，为 ff:ff:ff:ff:ff:ff；

在收到回包之后，172.18.0.11回复 ARP 响应包告知 MAC 地址是 02:42:ac:12:00:0b，然后就可以正常发送 ICMP 包了。

总结

本篇内容，从介绍 VLAN 开始讲述 VLAN 有哪些缺点，以及为什么会有 VXLAN。然后讲了 VXLAN 的协议报文是如何封装的，整体的工作模型是怎样的，以及 VXLAN 通信过程熟悉了它是怎么运作的，最后通过一个例子实战自己动手在两个节点上实现容器间的相互通信。相信到了这里，对 VXLAN 应该有了不少了解。