Overlay网络丢包或延迟升高如何定位？检查MTU、网卡与节点状态

Overlay网络出现丢包或延迟升高时，单看 ping 只能说明某类探测报文的结果，不能直接证明是链路、MTU、网卡、节点负载还是应用本身造成的。更可靠的判断方式，是在同一时间窗口内同时观察本地出口、DNS解析、路由路径、Overlay端点、网卡计数器、节点资源和应用响应阶段。

一套可复用的 Linux Overlay网络故障排查方法，应按“低风险、由外到内”的顺序进行：先确认本地网络和解析是否异常，再比较网关、底层节点与Overlay地址的丢包情况；随后检查路径MTU、网卡错误计数和节点状态；最后用TCP连接耗时、服务端资源和应用日志确认是否已经进入服务器或应用层。不要在只看到延迟升高后立即修改MTU或关闭网卡卸载功能，先保留基线并确认多个指标是否同步变化。

一、先建立同一时间窗口和故障边界

排查前应明确以下信息：

• 发起请求的节点、容器或网络命名空间；
• 目标是Overlay对端地址、节点管理地址，还是实际业务端口；
• 故障开始和结束的大致时间；
• 影响的是所有请求，还是新建连接、特定大报文或特定服务；
• 是否只有一个节点异常，还是多个节点同时出现问题。

同一个Linux主机上，宿主机和容器可能使用不同的路由表、DNS配置和网卡视图。若业务流量来自容器，测试命令应尽量在业务容器或相同网络命名空间中执行，否则宿主机测试正常并不能排除容器侧故障。

可以先保存一份只读基线：

date -Is
hostname
ip -br addr
ip route
ip -s link
ss -s

若环境允许，建议在故障持续的5至10分钟内重复采样，而不是只执行一次命令。下面的判断表可用于确定第一落点：

二、先排除本地网络和DNS因素

1. 确认实际出接口和下一跳

不要根据配置文件猜测流量路径，直接让内核查询目标地址的路由：

ip route get <目标IP>

重点看输出中的：

• dev：实际使用的接口；
• src：选择的源地址；
• via：下一跳网关；
• 是否出现了比预期更具体的路由。

如果目标地址属于Overlay网段，先确认它是否确实通过Overlay接口或对应的路由表转发。若命令显示流量从普通物理接口直接发出，问题可能不是Overlay封装本身，而是路由优先级、策略路由或地址选择发生了变化。

接着分层测试：

ping -4 -c 20 -W 2 <本地网关IP>
ping -4 -c 20 -W 2 <远端节点管理IP>
ping -4 -c 20 -W 2 <远端Overlay地址>

这三个目标应尽量使用同一发起环境。结果含义如下：

• 本地网关已经丢包：优先查看本机接口、网卡计数器和节点负载；
• 网关正常、远端管理地址异常：继续检查底层路径和远端节点；
• 管理地址正常、Overlay地址异常：重点转向封装接口、PMTU、邻居状态和Overlay端点；
• 三者都正常但业务仍慢：不要继续围绕ICMP反复测试，应进入TCP和应用层。

ping的丢包率只代表ICMP探测结果。中间设备可能对ICMP限速，因此某一跳显示丢包但后续跳和业务都正常，并不能单独证明该跳转发丢包。

2. 区分DNS耗时和网络传输耗时

如果系统使用了systemd-resolved，可以查看当前解析器和执行查询：

resolvectl status
resolvectl query <业务域名>

也可以使用dig观察查询耗时：

dig <业务域名> A
dig +stats <业务域名> A

如果dig的查询时间明显升高，而直接访问目标IP的TCP连接耗时稳定，问题更接近DNS解析器不可达、递归查询变慢、缓存失效或业务网络命名空间中的解析配置异常。

DNS变慢通常只影响新建连接。一个已经建立的长连接不会因为下一次DNS查询变慢而立刻增加网络延迟。因此应同时比较：

• 域名访问；
• 直接使用解析结果IP访问；
• 新建连接和复用连接；
• 宿主机与业务容器内的解析结果。

如果业务使用HTTPS，直接改成IP测试可能触发证书或Host不匹配。更适合使用curl --resolve，在保持域名和Host的同时指定测试地址：

curl --resolve app.example.test:443:<目标IP> \
  --connect-timeout 3 --max-time 10 \
  -sS -o /dev/null \
  -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} start=%{time_starttransfer} total=%{time_total} code=%{http_code}\n' \
  https://app.example.test/health

这里的dns较高，说明解析阶段可能有问题；connect较高，说明TCP建立连接耗时增加；start较高而前面阶段正常，通常要检查服务端排队、业务处理或后端依赖。

三、使用ping、tracepath和traceroute定位路径差异

1. 用ping比较不同层次的目标

建议至少记录以下三组结果：

ping -4 -c 50 -W 2 <网关IP>
ping -4 -c 50 -W 2 <远端节点管理IP>
ping -4 -c 50 -W 2 <远端Overlay地址>

不要只关注平均延迟，还要观察：

• 丢包率；
• 最大延迟与平均延迟的差距；
• 是否出现周期性尖峰；
• 多次执行时异常是否稳定重现。

例如，平均延迟从2毫秒升到8毫秒，但最大延迟偶尔达到300毫秒，通常比“平均延迟升高”更值得关注。它可能对应队列堆积、网卡接收处理不及时、CPU争用或重传等待。

2. 用tracepath观察PMTU和路径变化

tracepath除了尝试显示路径，还会报告路径MTU，是排查Overlay大报文问题的重要工具：

tracepath -n <目标IP>

重点观察：

• pmtu：路径可用的最大MTU；
• 是否在某一跳后出现明显变小；
• 是否出现no reply或路径中断；
• 最终是否能到达目标。

tracepath显示的某一跳没有响应，不等于该跳一定丢包。许多路由设备会限制TTL超时报文，但仍然正常转发后续流量。只有当丢包或延迟从某一跳开始，并持续影响后续跳和最终目标时，才更支持路径中间出现问题。

3. 需要时用traceroute或mtr交叉验证

普通UDP或ICMP探测可能被过滤，可以按实际业务端口尝试TCP模式：

traceroute -n -T -p <业务端口> <目标IP>

不同发行版的traceroute参数可能略有差异，执行前可用以下命令确认帮助信息：

traceroute --help

如果系统已安装mtr，可以进行有限次数的统计测试：

mtr -rwzc 50 <目标IP>

不要使用高频率、无限次数的探测替代正常监控。判断mtr结果时，应看最终目标一列以及从某一跳开始是否持续异常，而不是看到任意中间跳出现百分比丢包就下结论。

四、重点检查Overlay的MTU和实际PMTU

Overlay会在原始报文外增加封装头。物理接口MTU为1500时，内层可用MTU不一定仍是1500。以常见的基于UDP的封装为例，IPv4外层可能需要约50字节的封装空间，IPv6外层通常还会更多；如果同时存在VLAN、额外隧道或其他封装，实际可用值还会继续降低。

因此不能只看物理接口显示为1500，就认为Overlay业务一定能传输1500字节的内层报文。

1. 查看物理接口和Overlay接口

ip -br link
ip link show dev <物理接口>
ip link show dev 
ip -d link show dev 

如果使用的是VXLAN等可识别的Linux链路类型，ip -d link通常可以显示封装相关信息。还可以查看邻居和二层转发表：

ip neigh show dev 
bridge fdb show dev 

ip neigh中出现FAILED或长时间INCOMPLETE，说明邻居解析或对端可达性存在问题；FDB中缺少预期的远端记录，则需要结合具体Overlay实现检查端点状态和转发学习情况。

2. 使用不可分片探测验证大报文

IPv4路径可以使用DF位测试。以物理路径MTU为1500为例，ping -s指定的是ICMP数据部分，IPv4和ICMP头部还会占用28字节：

ping -4 -M do -c 5 -W 2 -s 1472 <目标IP>
ping -4 -M do -c 5 -W 2 -s 1400 <目标IP>

如果1472字节失败而1400字节成功，说明路径可能无法承载1500字节的IPv4报文，或相关设备没有正确返回PMTU信息。此结果需要结合tracepath和业务测试确认，因为防火墙过滤ICMP也可能造成类似现象。

IPv6环境应使用tracepath6或发行版支持的IPv6 PMTU探测方式：

tracepath6 -n <目标IPv6>

探测时最好分别测试：

• 节点管理地址；
• Overlay对端地址；
• 实际业务服务地址；
• TCP业务和UDP业务（如果两者都存在）。

3. 修复MTU时不要只改一端

如果确认Overlay有效PMTU小于当前配置，应按照封装开销重新计算内层MTU，并在通信两端保持一致。以物理MTU 1500、单层常见IPv4封装为参考，内层MTU可能接近1450，但这不是所有环境的固定值。IPv6外层、VLAN或多层封装都可能使结果不同。

临时修改Linux接口前，先记录当前值和接口状态：

ip link show dev 
ip -d link show dev 

确认影响范围后再执行：

sudo ip link set dev  mtu <新MTU>

该操作可能使现有连接短暂中断，也可能在网络管理服务或节点重启后被覆盖。回滚时使用变更前记录的值：

sudo ip link set dev  mtu <原MTU>

如果接口由容器网络、节点编排组件或系统网络管理服务创建，应在对应的持久化配置中修改，而不是只执行临时命令。修改前应备份原配置，并先在一台节点或维护窗口内验证。不要同时修改所有节点，否则出现问题时难以区分是MTU调整、路由变化还是端点状态变化造成的。

MSS调整有时能让TCP业务避开过大的报文，但它不能解决UDP大报文，也不能替代正确的路径MTU配置。看到“网页恢复正常”并不代表所有Overlay业务都已经修复。

五、检查网卡错误计数和接收处理能力

1. 观察计数器的增量，而不是只看累计值

先查看接口统计：

ip -s link show dev <物理接口>

在故障窗口前后各执行一次，比较计数器增量。重点关注：

• RX errors、TX errors；
• dropped；
• overruns；
• carrier；
• 是否出现明显的接收或发送丢弃。

驱动支持的详细计数可以通过ethtool查看：

sudo ethtool <物理接口>
sudo ethtool -S <物理接口>

不同网卡驱动的字段名称并不统一，常见字段可能包括CRC错误、接收队列丢弃、环形缓冲区溢出、发送超时等。ethtool -S中有累计数值并不等于当前正在出错，必须和时间窗口内的增量对应。

例如：

• RX errors和CRC类错误持续增加，更接近链路接收或驱动层异常；
• RX dropped增加而错误计数不变，可能是接收队列、内核处理能力或策略丢弃；
• TX timeout、carrier变化与延迟尖峰同时出现，应检查接口状态和节点内核日志；
• 网卡计数稳定，但Overlay仍丢包，应把重点转向MTU、路由、端点状态或节点资源。

可以查看近期内核告警：

dmesg --level=err,warn | tail -n 100

如果系统通过日志服务集中管理，也应按故障时间检索对应节点的内核日志。不要只看当前日志最后几行，因为网络接口反复重置、链路短暂抖动或驱动告警可能发生在故障开始时。

2. 不要把网卡卸载功能当作首个修复手段

查看卸载能力：

ethtool -k <物理接口>

TSO、GSO、GRO等功能可能影响抓包中的报文形态，也可能让宿主机看到的包大小与线上的实际分段方式不同。它们本身不等于故障原因。未经基线对比就关闭卸载功能，可能增加CPU负载，反而放大节点拥塞。

如确实需要进行对照测试，应先保存ethtool -k输出，只在一台节点、短时间、低风险业务窗口内逐项调整，并记录变更前的原始状态。测试完成后按原状态恢复，而不是假设所有选项都应统一设置为on或off。

六、确认Overlay节点和服务器负载是否同步异常

网络延迟升高经常与CPU争用、内存压力、I/O等待或软中断处理不及时同时发生。只看CPU平均使用率可能漏掉单核瓶颈、CPU steal或I/O队列堆积。

在故障窗口执行：

uptime
vmstat 1 5
mpstat -P ALL 1 5
free -h
ss -s

如果系统安装了sysstat，还可以查看设备I/O：

iostat -xz 1 5

重点关注以下关联：

• vmstat中的r持续高于可运行CPU数量，可能存在CPU调度排队；
• %wa升高，说明进程等待I/O，应用响应可能变慢；
• 虚拟机环境中的%st升高，表示宿主机争用CPU时间；
• 内存不足、频繁回收或交换活动可能造成服务和网络处理抖动；
• ss -s中的TCP连接数、重传相关状态和接收队列同时增加，说明连接处理或服务端消费能力可能不足。

检查Overlay接口和邻居状态：

ip link show
ip -d link show
ip neigh

如果接口处于DOWN、邻居长期FAILED，或者某个节点的Overlay端点信息缺失，应将该节点与正常节点做逐项对比。不要在没有记录状态的情况下直接重启网络服务或节点；重启可能清除现场，也可能影响同机上的其他业务。若必须重启，应先确认业务容灾能力、保存日志和计数器，并准备按原服务配置恢复。

七、把网络测试和应用响应阶段对应起来

1. 使用curl拆分请求耗时

对HTTP或HTTPS服务，可以使用以下格式观察各阶段：

curl -sS -o /dev/null \
  --connect-timeout 3 \
  --max-time 10 \
  -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} pretransfer=%{time_pretransfer} starttransfer=%{time_starttransfer} total=%{time_total} code=%{http_code}\n' \
  https://app.example.test/health

这些字段可按以下方式理解：

• time_namelookup：DNS解析结束；
• time_connect：TCP连接建立；
• time_appconnect：TLS握手完成，非HTTPS通常为0；
• time_starttransfer：收到服务端第一字节；
• time_total：整个请求完成。

典型判断如下：

• dns升高：优先检查解析器和业务网络命名空间；
• connect升高：检查路由、丢包、SYN重传、服务监听和节点负载；
• starttransfer升高但连接阶段稳定：重点检查应用队列、线程池、数据库或后端依赖；
• total明显高于starttransfer：检查响应传输、发送队列、分段、带宽或大报文处理。

2. 查看TCP重传和连接状态

对于已经建立的连接，可以查看TCP详细信息：

ss -ti dst <目标IP>

如果输出中出现较高的rto、重复重传、拥塞窗口明显收缩等信息，应与网卡丢包计数、Overlay PMTU和路径测试放在同一时间线上分析。单个连接偶尔重传不一定代表全局故障，但多个连接同时出现重传，且应用响应时间同步升高，就需要重点排查传输路径或服务器接收处理能力。

必要时可在获得授权的前提下短时间抓取报文：

sudo timeout 30 tcpdump -ni <接口> -s 96 'host <目标IP> and (tcp or icmp)'

抓包可能暴露地址、端口甚至部分应用内容，即使设置了较小的截取长度也不能视为完全无敏感信息。应限制时间和过滤范围，不要在未授权的生产环境长期运行；若改为写入文件，测试结束后按安全要求保管或删除。

抓包中可以关注：

• SYN是否反复重传；
• 建连后是否出现重复ACK；
• 是否有明显的ICMP“需要分片”或不可达报文；
• 请求发出后，服务端是否及时返回数据；
• 大报文是否在同一阶段大量重传。

八、通过多指标联动形成判断

以下数据是用于说明判断过程的示例，不代表某个实际节点的监控结果。

场景一：Overlay大报文失败，MTU更可疑

在同一时间窗口内观察到：

• 本地网关丢包为0，延迟约2毫秒；
• 远端节点管理地址也基本稳定；
• Overlay地址出现8%的丢包，延迟从3毫秒升到70毫秒；
• tracepath显示有效PMTU为1450；
• 1500字节路径的DF探测失败，1400字节探测成功；
• 网卡CRC、carrier和接收丢弃计数没有增加；
• 节点CPU、I/O等待和内存压力正常。

这组指标共同指向“Overlay有效MTU低于当前业务路径假设”，而不是单纯的节点过载。此时应核对封装层数、两端Overlay接口MTU、底层路径MTU以及是否存在错误的分片或PMTUD处理，再进行单节点、可回滚的MTU调整。

场景二：网络探测正常，但应用首字节延迟高

另一组示例数据可能是：

• 网关、管理地址和Overlay地址的ping都稳定；
• tracepath的PMTU与预期一致；
• 网卡错误和丢弃计数没有明显增量；
• curl中的DNS和TCP连接耗时正常；
• time_starttransfer从80毫秒增加到1.2秒；
• vmstat中的运行队列和I/O等待同时升高；
• 应用日志显示请求排队时间增加。

这时继续修改MTU或路由通常不会解决问题。更合理的方向是检查服务线程池、后端依赖、磁盘I/O、连接池和应用队列，并把应用错误率、请求耗时分位数与节点资源放在同一时间线中。

场景三：网卡计数器和Overlay丢包同时增加

如果Overlay丢包开始的时间与某物理接口RX dropped、队列溢出或carrier变化一致，同时节点CPU软中断处理能力不足，那么问题更接近接口接收、驱动状态或节点处理能力。此时应先保留计数器、内核日志和接口状态，与同集群正常节点比较；不要先通过修改DNS或增加应用超时来掩盖底层丢包。

九、修复后的验证顺序

每次只改变一个主要变量，并保留变更前后的结果。修复MTU后，不要同时改路由、关闭网卡卸载和重启节点，否则无法确认真正的修复因素。

建议按以下顺序复测：

1. 在与故障相同的网络命名空间内，重新测试网关、远端节点和Overlay地址。
2. 使用多个报文大小进行DF探测，确认小报文和接近有效PMTU的大报文都能稳定通过。
3. 使用tracepath确认PMTU已经与设计值一致，路径没有出现新的异常跳点。
4. 再次查看ip -s link和ethtool -S，确认错误、丢弃和重传计数不再持续增加。
5. 用业务实际端口执行多次curl，比较DNS、连接、TLS、首字节和总耗时。
6. 在复测期间同时记录节点CPU、内存、I/O等待、连接数和应用错误率。

可以用短循环观察请求耗时是否稳定：

for i in $(seq 1 10); do
  date -Is
  curl -sS -o /dev/null \
    --connect-timeout 3 \
    --max-time 10 \
    -w 'connect=%{time_connect} start=%{time_starttransfer} total=%{time_total} code=%{http_code}\n' \
    https://app.example.test/health
  sleep 1
done

成功验证不应只表现为某一次ping恢复正常，而应至少同时满足：路径PMTU符合预期、连续探测没有持续丢包、网卡错误计数不再增长、业务连接阶段恢复、应用首字节和错误率回到正常基线。对于原本存在周期性故障的环境，还应在一个完整业务高峰或足够长的观察窗口内继续监控，避免把暂时恢复误判为彻底解决。

下一次故障窗口应同时保留的指标

为了避免再次陷入“只看一个数字”的判断，建议在同一时间轴保存以下组合：

• 网关、远端管理地址、Overlay地址的丢包率和延迟；
• tracepath报告的PMTU；
• DNS查询耗时；
• 网卡RX/TX错误、丢弃、队列和carrier变化；
• 节点CPU运行队列、I/O等待、内存压力和连接数；
• TCP重传、连接建立耗时；
• 应用的首字节延迟、总耗时、状态码和错误率。

当这些指标按照时间先后关联起来时，通常可以区分三类问题：只有解析阶段变慢，说明更接近DNS；路径和网卡指标先异常，说明应优先排查网络、MTU或节点接口；网络连接正常而首字节和应用错误率升高，则应进入服务器负载和应用处理链路。这样的联合观察比单独依据某次ping结果，更适合定位Overlay网络中间歇性丢包和延迟升高问题。