Openstack Jumbo Frame调整实践

Posted 2023-03-26

参考技术A IEEE 802.3以太网标准仅规定支持1500Byte的帧MTU，总计1518Byte的帧大小。（使用IEEE 802.1Q VLAN/QoS标签时，增加至1522Byte）而巨型帧往往采用9000Byte的帧MTU，合计9018/9022Byte的帧大小。

目前巨型帧尚未成为官方的IEEE 802.3以太网标准的一部分。所以不同硬件厂商的设备支持程度可能不尽相同。

使用巨型帧，增大的有效报文长度提升了带宽使用效率的提升（如下图）。与此同时，增长的报文也带来传输时延的增加，时延敏感型数据并不适合使用巨型帧传输。

从配置项的描述总结而言，global_physnet_mtu与physical_network_mtus共同定义了underlay physical network的MTU，path_mtu定义了overlay network的MTU。

在neutron.conf中

在ml2.ini中

该配置定义了所有underlay网络（flat，vlan）与overlay网络（vxlan，gre）的MTU值均为9000。

在neutron.conf中

在ml2.ini中

该配置定义了underlay网络provider2的MTU值为4000，provider3的MTU值为1500，其他如provider1的MTU值为9000。而overlay网络的MTU值为9000。

在neutron.conf中

在ml2.ini中

该配置定义了所有underlay网络MTU值为9000，overlay网络的MTU值均为4000。

flat和vlan网络，根据实际的物理网络映射与physical_network_mtus、global_physnet_mtu信息，获取最小可用MTU值。

Geneve，Gre，Vxlan类型网络，则根据global_physnet_mtu与path_mtu中选取最小的可用MTU值，减去各类型报文头部开销，获取实际可用MTU值。

在用户实际创建network资源时，若未显式指定网络MTU值，则使用该网络类型下系统定义的最大可用MTU。若显式指定MTU，neutron会检查用户定义MTU是否小于等于该网络类型下系统定义的最大可用MTU。

在使用Linux Bridge实现的Neutron网络中，Linux Bridge Agent在侦测到新的device后，会通过ip link set 操作，根据network中的MTU值，设置虚拟机绑定至Linux Bridge的tap设备的MTU值。反观Openvswitch实现的网络中却没有相关的设置。实际在使用过程中需要通过ovs-vsctl set Interface <tap name> mtu_request=<MTU Value>命令人工去设置tap设备的MTU值。

dhcp和router相关的tap设备在plug时，neutron会根据网络的MTU，在各tap设备所在的namespace内运行“ip link set <tap name> mtu <MTU value>”设置tap设备的MTU值。

Openstack从J版以后，neutron使用ovs patch port代替了linux veth实现OVS网桥之间的连接（出于性能提升的目的）。但依旧保留了veth连接的方式。在openvswitch_agent.ini中可以通过配置use_veth_interconnection=true启用veth连接网桥的功能。如果开启这项配置，默认的veth_mtu值为9000。当配置链路MTU大于9000时，需要修改openvswitch_agent.ini配置文件中veth_mtu的值，以免发生瓶颈效应。

虚拟机内部网卡配置MTU则是通过虚拟机DHCP请求IP地址时，顺便请求MTU值。在RFC2132 DHCP Option and BOOTP Vendor Extensions里明确定义了Interface MTU Option。DHCP Option Code 26 用两个字节的MTU数据，定义了网络接口的MTU值。如下表所示。

在DHCP agent中，dnsmasq的spawn_process会根据network的MTU值调整自身的启动参数。从而使虚拟机在DHCP过程中能正确地配置自身网卡的MTU值。

通过指定ICMP报文内容size以及IP报文不分片来探测MTU值设置是否正确。注意这里的size是指icmp data size。该size并不包含ICMP报文头部长度（8Byte）以及IP头部长度（20Byte）。

windows下

linux下

巨帧（jumbo frame）

最近重新接触到巨帧（jumbo frame）这个概念，第一次接触是在视频传输中，本来以为定义是一个定值的，故没有太大留意，这次重新查看了下，其定义是一个范围值，而且该范围还与厂家设置有关，故需要注意一下。

首先为什么要启用巨帧，具体来源理解还不深，不过带来最大的好处还是效率提高（尤其在高速网络中，该效率体现比较大）。在网络中定义该效率就是真实发送payload的时间/发送完整数据包（包含头部）的时间，wiki上的表大致有一个记录，当然这个定义还不是非常严格就是了，如果定义在网络中，那么还有一个竞争开销这里并没有包含，即CSMA/CD回退所产生的开销，不过这里如何度量会复杂一些。从下图中可以看到，标准模式的效率（也就是归一化吞吐量）是低于jumbo模式的。实际上这点如果从无线网络的发展来看，也是同样的思路。在一开始的无线网络802.11a/b/g，其都是没有引入太长的数据包长度考量的，毕竟本身传输速率有限，且效率影响不大。随着物理层速率增加，这点逐步开始被重视，即从协议802.11e中的txop，到802.11n中的帧聚合，其意都在通过增加数据包长度，来提高网络效率，这里有关细节以后可以再讨论，这里仅仅记录下。

那么接下来就是有关Jumbo帧定义的问题了，目前通常好像是将1500Byte至9000Byte这一段叫做Jumbo帧，然后从9000Byte至64000Byte叫做Super jumbo frames，也就是超巨帧。同时这里还有一个Baby giant frames的定义，暂时理的还不是很清楚，有的所述为，标准的二层MTU大小是1500Byte，如果由于封装头部的原因，使之大于1500Byte，比如802.1Q的封装头部，其整个帧大小就会是1522Byte，即该个就是小巨帧（这里未理清楚的就是这里是从1500Byte开始算起，还是从1518Byte开始算起，即Ethernet和802.3帧的区别，同样在巨帧中也有这个问题）。

然后有关Jumbo帧定义的起始点，目前有的是从1500Byte开始算起，有的是从1518Byte开始算起，原因应该就是Ethernet和802.3帧的区别，不过这里还没有考究过。有关Jumbo帧的结尾点，则定义看到过更多的版本，wiki上面算是列举了几种，如下

实际上一般查到的也是9216Byte，好像该设置上限是思科的上限，所以比较常用些。在Ethernet权威指南一书中，将该上限提高到了9720Byte，如下图

同时对于Jumbo frame的起始点，该书中所述也是从1500Byte起始的，实际上就是最大帧的大小定义为了1500Byte，同时这里所述巨帧一般是本地有效的，其原因应该是很多地方会filter该巨帧，比如说路由不开启支持巨帧，则无法传输出去。

在电脑上如果需要兼容巨帧，也是需要通过网卡驱动设置中，选择巨帧支持才可以。比如下图就是设置的情况，在该设置中，所支持巨帧的大小是从2K~9K的范围，不过至于为什么不一次性只采用一个设置，而可以精确到特定大小的巨帧，可能是为了性能优化而言。毕竟一般本地所采用巨帧都是一些特殊设备，如工业摄像头之类的，其帧通常也是选择6K大小，所以没有必要选择9K大小，从而可能在资源开辟上面能够提高一些性能。