MTU设置不当导致丢包的典型特征是小包正常而大包丢弃，伴随TCP重传率升高、P99延迟突增，但ping和端口连通性正常；确认需验证路径最小MTU，排查PMTUD是否被防火墙拦截，并统一调整全链路MTU值。
MTU 设置不当导致的丢包，特点是“小包正常、大包丢弃”，且往往伴随 TCP 重传率升高、P99 延迟突增，但 ping 和端口连通性完全正常。这类问题不触发网卡错误计数，也不出现在 iptables 日志里，容易误判为网络抖动或应用层故障。
确认是否是 MTU 问题的典型现象
先看业务表现是否吻合以下特征：
- HTTP 小请求（如 GET /health）成功，但上传 2MB 文件或直播推流持续卡顿
- tcpdump 抓包能看到大量 TCP 重传（retransmission），尤其是 MSS 接近 1460 的报文反复出现
- 用
ping -s 1472 目标IP（1472 + 28 字节 IP+ICMP 头 = 1500）能通，但ping -s 1473就超时或无响应 -
ip link show dev eth0显示 MTU 是 1500，但路径中某段（如隧道、VLAN、云厂商虚拟网关）实际只支持 1400 或 1350
逐跳验证路径 MTU 是否一致
不能只看本机网卡 MTU，关键要确认**端到端路径**的最小 MTU：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 用
mtr --mtu 目标IP（部分新版 mtr 支持）或分段测试：ping -M do -s 1400 目标IP（-M do禁用分片），逐步增大-s值直到不通，找到路径最大有效载荷 - 检查中间设备：CNI 插件（如 Cilium 默认隧道 MTU=1450）、云平台 VPC 路由器（阿里云经典网络默认 1500，但 NAT 网关可能压到 1400）、物理交换机 VLAN 接口 MTU
- 查内核路由缓存：
ip route get 目标IP看是否带mtu 1400标记；若有，说明已探测到路径限制并做了 PMTUD
检查是否被 PMTUD 或防火墙干扰
Linux 默认启用路径 MTU 发现（PMTUD），但常被以下情况破坏：
- 中间防火墙或安全组 拦截了 ICMP “Fragmentation Needed” 类型报文（Type 3, Code 4），导致发送端无法得知路径 MTU 缩小，仍发大包后被静默丢弃
- 确认：
cat /proc/sys/net/ipv4/ip_no_pmtu_disc应为 0（启用）；若为 1，则强制禁用 PMTUD，需手动调小 MTU - 临时验证：在客户端执行
echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc，再设ip link set eth0 mtu 1400，观察丢包是否消失
调整与固化 MTU 设置
修复不是简单改一个数字，要匹配整条链路：
- 若确认路径最小 MTU 是 1400，所有环节统一设为 1400：
ip link set eth0 mtu 1400 - 持久化：写入网卡配置文件（如 CentOS 的
/etc/sysconfig/network-scripts/ifcfg-eth0加MTU=1400；Ubuntu 的 Netplan YAML 中加mtu: 1400） - 容器环境特别注意：CNI 配置（如 Cilium 的
mtu: 1450）、Pod 网络命名空间内也要同步调整，否则 host 网卡改了，容器内仍是 1500
