[网络协议]网络协议学习：通用网络虚拟化封装GENEVE

背景

之前介绍过通用路由封装协议GRE和虚拟可扩展局域网VxLAN，他们都是隧道协议的一种实现。
这两种协议的初衷和实现形式都是类似的。从初衷上说，这两种协议都是想实现一种对原始网络数据的一种扩展和封装：以一定的格式封装原始网络数据，再辅以一定的元数据（metadata），来实现附加的功能。例如，VxLAN中的网络标识符VNI就是一种元数据，实现的功能是对租户进行区分。
但是，随着网络的扩展以及业务的发展，有时候需要一种符合自己网络情况以及业务逻辑的协议，例如采用自己独特的业务元数据。这时候就需要一种技术来实现一种通用的封装方式，来符合自己的需求。这种封装最好可长可短，来实现自己的逻辑

GENEVE

GENEVE(Generic Network Virtualization Encapsulation,通用网络虚拟化封装)，是一种虚拟化隧道通信技术，定义于RFC 8926
，相比于之前类似的技术，GENEVE的一点重大区别在于：协议的元数据本身是可扩展的。GENEVE提供了可扩展的GENEVE header，让业务更加灵活。

实现

其实可变长的字段，在其他的领域是有过类似的产物的。例如在MySQL数据库中，就支持可变长的字段varchar，来实现存储可变长字符串。在MySQL的默认存储引擎InnoDB的实现下，如果采用COMPACT行格式，其记录格式如下：

图源互联网
为了实现可变长字符串的存储，需要在记录的时候，对要存储的实际内容的长度开一个字段进行记录，当然如果表中的字段不存在可变长的（例如全部为char、int类型这种），这个字段也可以不被使用。
例如如果表a存在两列：varchar(20) col1和varchar(20) col1，当我在执行inset，插入字符串(‘aa’,‘bbb’)，实际落盘的数据行需要首先存储这两个字符串的长度2和3（实际存储是倒序的二进制的，此处不深入探究实际机制仅讨论存储方案），然后在右边真实数据里面插入实际字符串’aa’和’bbb’。

那么，类似的可变长的也可以运用在网络传输中。

报文结构

IPv4的Geneve数据包格式如下：

其中，Geneve Header的内容如下：

其中各字段含义如下：

这里的O和C字段是出于性能考虑，GENEVE报文的可扩展性很好，那就意味着其长度可能比较长，处理起来就比较耗资源，加入这两个字段可以使得Endpoint能够更灵活的处理数据。
在兼容性上，如果不考虑Variable Length Options，GENEVE与VxLAN是不冲突的，一些现有的针对VXLAN的优化可以直接应用在GENEVE上。
在考虑ECMP的情况下，ECMP设备看到的不是虚机的IP/MAC，而是Tunnel Endpoint的IP/MAC。也就是说，连接到同一台Tunnel Endpoint的机器的外层报文除了UDP port都是相同的。GENEVE协议认为应该使用source port的整个16bit（而不是常用的50000-65535）做Overlay流区分（RFC 8926 Section 2.3）

参考

RFC 8926
网络虚拟化协议GENEVE
网络虚拟化基础协议之Geneve