嘿，咱们一步步来解决这两个和OpenStack巨帧相关的问题：

简单说：技术上可以部署，但一定会引发通信问题，非常不建议这么做。

原因是这样的：如果你的OpenStack内部网络用了VXLAN或GRE这类overlay隧道技术（这是很常见的部署方式），VM发出的巨帧数据包会被加上额外的隧道头部（比如VXLAN会增加约50字节）。这意味着最终发送到物理网络的数据包大小是「内部网络MTU + 隧道封装开销」。

如果你的物理网络不支持巨帧（比如默认的1500 MTU），封装后的数据包会远大于物理网络能承载的上限。要么数据包会被分片（如果没设置DF位），要么直接被丢弃（如果设置了DF位），这两种情况都会破坏VM之间的可靠通信。

如果确实需要在内部网络启用巨帧，必须保证物理网络的MTU足够大，能容纳封装后的数据包（比如内部MTU是9000，VXLAN的话物理MTU至少要9050）。如果没法调整物理网络的MTU，那应该把内部网络的MTU设置为「物理MTU - 隧道封装开销」，这样才能正常通信。

咱们按系统的流程来排查：

• 检查计算节点上虚拟网桥的MTU配置
  查看两台计算节点上的集成网桥（br-int）和隧道网桥（br-tun，如果用了overlay网络）的MTU设置。用命令ip link show br-int和ip link show br-tun确认。如果内部网络MTU是9000且用VXLAN，这些网桥的MTU至少要设为9050。如果它们的MTU不够，数据包在计算节点就会被丢弃。

• 验证隧道端点的MTU设置
  对于overlay网络，检查每个计算节点上的VXLAN/GRE隧道接口（比如vxlan0）的MTU，它必须和br-tun的MTU一致。用ip link show vxlan0查看。

• 测试物理网络路径的MTU
  就算交换机配置了9K MTU，计算节点之间的整条物理链路可能存在瓶颈。直接在两台计算节点之间执行ping <对方计算节点IP> -s 8972 -M do测试。如果这个ping不通，问题出在物理网络（比如某个交换机端口还是1500 MTU、线缆故障等），和VM或OpenStack无关。

• 核对Neutron的网络MTU配置

  • 用openstack network show <网络名称或ID> -c mtu确认内部网络的MTU是否正确设为9000。
  • 查看ML2插件配置文件（比如/etc/neutron/plugins/ml2/ml2_conf.ini），确保path_mtu参数和你的网络环境匹配。
  • 如果是基于OVS的部署，检查OVS的配置文件里有没有MTU相关的限制。

• 检查VM操作系统层面的MTU设置
  就算你给VM网卡配置了9K MTU，也要确认操作系统是否正确识别。在VM里执行ip addr show <VM网卡名称>查看。另外，确保操作系统没有防火墙规则或网络过滤器拦截大数据包，有些Linux发行版可能需要额外的驱动调整才能完全支持巨帧。

• 查看网络日志找线索
  检查Open vSwitch日志（/var/log/openvswitch/）、计算/控制节点上的Neutron服务日志，以及物理交换机的日志。找类似「MTU超出限制」或者和帧大小相关的丢包错误信息。

• 去掉DF位测试以定位问题
  你用的ping命令里的-M do参数设置了「不分片（DF）」位，只要路径上任何一段MTU不够，数据包就会被丢弃。试试去掉-M do执行ping <VMIP> -s 8972 -I <网卡名称>。如果这样能通，那肯定是路径上存在MTU不匹配，导致设置DF位时丢包，不设置时可以分片通信。

内容的提问来源于stack exchange，提问作者N.S.