MTU 配置不当引发的血案：一次诡异的网络丢包，排查了整整两天

📌 一句话摘要

本文详细记录了一起因 Kubernetes 集群中 Cilium VXLAN 隧道 MTU 配置不当导致网络丢包的故障排查过程，并系统梳理了 MTU 原理、排查方法和生产环境最佳实践。

📝 详细摘要

文章以一次真实的线上故障为引子，讲述了作者在混合云 K8s 环境中，因直播推流出现间歇性卡顿而展开的为期两天的排查经历。问题根因定位为 Cilium 1.15 升级后，VXLAN 隧道接口的 MTU 仍为 1500，但 VXLAN 封装会额外增加 50 字节开销，导致超过物理网卡限制的数据包被丢弃。文章不仅完整复盘了从现象确认、抓包分析到定位根因的全过程，还以此为契机，系统性地梳理了 MTU 基础知识（如 MTU vs MSS、PMTUD、分片重组）、不同场景下的 MTU 配置方案（物理机、虚拟机、容器、云环境、VPN）、以及一套完整的排查工具箱（诊断命令、测试脚本、抓包分析、内核参数调优）。最后，文章总结了 K8s 环境下的 MTU 最佳实践、高级场景（IPv6、eBPF、RDMA）的处理，并给出了生产环境的配置规范和自动化运维建议。

💡 主要观点

- K8s 环境中 VXLAN 隧道 MTU 配置不当是常见网络故障根因。 VXLAN 封装会带来 50 字节额外开销，若 Pod 网络 MTU 未相应减小（如设为 1450），大包会因超过物理链路 MTU 而被丢弃，导致间歇性丢包和 TCP 重传。

PMTUD 失效是导致 MTU 问题难以定位的主要原因之一。 PMTUD 依赖 ICMP 消息，但防火墙常会拦截 ICMP 包，形成 PMTUD 黑洞。Cilium 1.15 默认关闭 PMTUD 功能，加剧了此类问题。

排查 MTU 问题应遵循从现象到根因的标准化流程。 通过确认大包丢失小包正常的现象，使用 ping -M do、tracepath、tcpdump 抓 ICMP 错误等工具快速诊断，再检查所有接口、隧道和云环境 MTU 来定位问题点。

生产环境应建立 MTU 配置规范和自动化检查机制。 标准化 MTU 值（如 1450）、通过 Ansible 等工具自动化配置、增加丢包率和重传率的监控告警、定期运行健康检查脚本，是预防 MTU 问题的关键。

💬 文章金句

- MTU 这个东西，一遇到问题，你就会发现水很深。

• 升级前要看 Release Notes：Cilium 1.15 的变更导致了这个问题，如果升级前仔细看了 Release Notes，可能就不会踩坑。
• VXLAN 封装开销：外层以太网头 14 字节 + 外层 IP 头 20 字节 + 外层 UDP 头 8 字节 + VXLAN 头 8 字节，总共 50 字节。
• 如果中间有任何设备不支持 9000 MTU，就会出问题。

📊 文章信息

AI 初评：88

来源：dbaplus社群

作者：dbaplus社群

分类：软件编程

语言：中文

阅读时间：36 分钟

字数：8936

标签： MTU, Kubernetes, Cilium, VXLAN, 网络排障

阅读完整文章