GENEVE对应的RFC8926是2020年11月份正式发布的,距今已经过去4年多了,目前主要支持的设备商还是国外的厂商。从飞塔防火墙的配置过程,我们可以看到,配置非常简单,实现应该也比较简单。
具体简单到什么地步呢?据说Ubuntu系统从16.04版本开始就支持GENEVE了,也就是2016年4月份,竟然比RFC8926的发布时间还早?其实这也没啥问题,RFC8926的前身是draft-gross-geneve草案,该草案始于2014年2月份,在2015年5月份演化为draft-ietf-nvo3-geneve草案,这时的协议规范就基本完善了,所以Ubuntu大概率是这时就开始了GENEVE协议的适配开发工作。
为了验证配置,我们使用两台Ubuntu主机测试对接GENEVE隧道,系统版本分别为18.04.6 LTS和23.10。
测试拓扑如下所示:
图片
测试前,我们先配通底层网络。Ubuntu18.04和Ubuntu23.10两个系统配置IP地址的方式有所不同,Ubuntu18.04的配置命令如下:
而Ubuntu23.10的配置命令为:
配置完成之后,两台主机就可以互通了。
图片
接下来,我们先配置Ubuntu18.04的GENEVE配置。
跟飞塔防火墙的配置过程类似,配置GENEVE也是创建一个隧道接口,创建时必需要指定对端的IP地址和VNI,其他的都是可选配置。目前还没遇到说修改GENEVE隧道端口号的,如果不幸遇到了,可以通过dstport来指定。
图片
可以看到,隧道接口创建之后处于DOWN状态,需要手工UP一下,再配置上接口的IP地址就好了。
图片
这里使能端口和配置IP地址没有严格的先后顺序,怎么操作都行。
到这里,Ubuntu18.04就配置完了,我们使用相同的操作,配置Ubuntu23.10。
图片
可以看到,配置完成的接口一直处于UNKNOWN状态,那这是否影响GENEVE隧道的通信呢?
图片
通信正常,没有影响。
现在看来,只要3条命令就能完成Ubuntu系统创建GENEVE隧道,那报文长啥样呢?我们抓包看一下。
图片
可以看到,我们在配置完一台主机之后,该主机立即向外发送GENEVE协商请求报文,报文内容竟然又是IPv6的组播报文,跟飞塔防火墙一模一样。这与RFC规范中的描述基本一致:
“Geneve隧道可以是两个隧道端点之间的点对点单播,也可以利用广播或组播寻址。在这方面不要求内部和外部寻址匹配。例如,在不支持组播的物理网络中,封装的组播流量可以被复制到多个单播隧道中,或者通过策略转发到单播位置(可能在那里复制)。”
而在两端都成功加入到组播组之后,两台主机就可以正常通信了。
我们再看一下ping包,直接显示的就是内层的IP地址。
图片
可以发现,报文的封装格式遵循GENEVE协议规范,从外到内依次是外层以太网报文头、外层IPv4报文头、外层UDP报文头、GENEVE报文头、内层以太网报文头、封装载荷。
以我们的抓包为例,外层以太网报文头分别是Ubuntu23.10和VSR的MAC地址,外层IPv4报文头分别是Ubuntu23.10和Ubuntu18.04的接口IPv4地址,外层UDP报文头的目的端口为UDP 6081端口,而源端口则不是固定的UDP 6081端口,请求报文的源端口为51016,响应报文的源端口为48931,似乎没有什么规则,这里与飞塔防火墙的实现有些许不一样。
再往内层就是GENEVE报文头,记录了VNI为100(0x64),内层以太网报文头为两个GENEVE虚拟接口的MAC地址;再内层的封装载荷就是原始的PING报文了。
既然Ubuntu和飞塔防火墙的实现有差异,那两者能对接吗?且听下文分解。