记一次有惊无险的丢包调试经历-linux运维-PHP中文网

记一次有惊无险的丢包调试经历

爱谁谁

发布： 2025-06-26 12:34:26

原创

824人浏览过

在将服务器从 centos 5 升级到 centos 7（内核版本 3.10.0-693）后，我在服务器上偶然发现了一个重大问题：网卡 eth0 在接收（rx）数据时存在规律性丢包，每一两秒丢一个包。

记一次有惊无险的丢包调试经历

我首先怀疑可能是网卡的 ring buffer 容量不足，于是使用「ethtool」工具进行检查：

shell> ethtool -g eth0
Ring parameters for eth0:
Pre-set maximums:
RX:         256
RX Mini:    0
RX Jumbo:   0
TX:         256
Current hardware settings:
RX:         256
RX Mini:    0
RX Jumbo:   0
TX:         256

登录后复制

虽然 ring buffer 确实显得较小，但当前硬件设置已达到预设的最大值，无法进一步扩大。为了进一步确认网卡是否存在丢包问题，我继续使用「ethtool」进行检查：

shell> ethtool -S eth0
no stats available
shell> ethtool -i eth0
driver: virtio_net
version: 1.0.0
firmware-version:
expansion-rom-version:
bus-info: 0000:00:04.0
supports-statistics: no
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no

登录后复制

结果显示，kvm 的 virtio_net 驱动不支持统计数据，好在还有其他方法来获取信息：

shell> find /sys -name eth0
/sys/devices/pci0000:00/0000:00:04.0/virtio1/net/eth0
/sys/class/net/eth0
shell> cd /sys/devices/pci0000:00/0000:00:04.0/virtio1/net/eth0
shell> cd statistics
shell> grep . * | grep rx
rx_bytes:633037730314
rx_compressed:0
rx_crc_errors:0
rx_dropped:206975
rx_errors:0
rx_fifo_errors:0
rx_frame_errors:0
rx_length_errors:0
rx_missed_errors:0
rx_nohandler:0
rx_over_errors:0
rx_packets:4717658080

登录后复制

虽然 rx_dropped 值不为零，但 rx_errors 等错误计数器都为零，这表明 ring buffer 没有溢出，否则 rx_fifo_errors 等错误计数器不可能为零。因此可以推断：网卡已经将数据完整地传递给了操作系统，丢包问题出在操作系统层面。

为了确定操作系统在哪里丢包，我使用了 dropwatch 工具：

shell> dropwatch -l kas
Initializing kallsyms db
dropwatch> start
Enabling monitoring...
Kernel monitoring activated.
Issue Ctrl-C to stop monitoring
6 drops at ip_rcv+cf (0xffffffff815ca47f)
11 drops at ipv6_rcv+3ad (0xffffffff81643d7d)
75 drops at tcp_v4_rcv+87 (0xffffffff815f0197)
426 drops at sk_stream_kill_queues+50 (0xffffffff8157a740)
235 drops at tcp_rcv_state_process+1b0 (0xffffffff815e4fb0)
137 drops at tcp_v4_rcv+87 (0xffffffff815f0197)
11 drops at ipv6_rcv+3ad (0xffffffff81643d7d)
1 drops at __netif_receive_skb_core+3d2 (0xffffffff81586d82)
shell> grep -w -A 10 __netif_receive_skb_core /proc/kallsyms
ffffffff815869b0 t __netif_receive_skb_core
ffffffff81587170 t __netif_receive_skb
ffffffff815871d0 t netif_receive_skb_internal
ffffffff81587290 T netif_receive_skb
ffffffff81587300 t napi_gro_complete
ffffffff81587400 T napi_gro_flush
ffffffff81587490 T napi_complete_done
ffffffff81587550 T napi_complete
ffffffff81587570 T sk_busy_loop
ffffffff81587830 t net_rx_action
ffffffff81587bb0 t dev_gro_receive

登录后复制

dropwatch 通过监控 kfree_skb 的调用来监控操作系统可能的丢包行为。我们的问题是每一两秒丢一个包，因此我们将关注点放在了 __netif_receive_skb_core 函数上（丢包地址 0xffffffff81586d82 位于 ffffffff815869b0 和 ffffffff81587170 之间）。

查阅 Linux 源代码中的 __netif_receive_skb_core 函数定义，确认丢包原因：

static int __netif_receive_skb_core(struct sk_buff *skb, bool pfmemalloc)
{
    ...
    if (pfmemalloc && !skb_pfmemalloc_protocol(skb))
        goto drop;
    ...
drop:
    atomic_long_inc(&skb->dev->rx_dropped);
    kfree_skb(skb);
    /* Jamal, now you will not able to escape explaining 
     * me how you were going to use this. :-) 
     */
    ret = NET_RX_DROP;
    ...
}
static bool skb_pfmemalloc_protocol(struct sk_buff *skb)
{
    switch (skb->protocol) {
    case __constant_htons(ETH_P_ARP):
    case __constant_htons(ETH_P_IP):
    case __constant_htons(ETH_P_IPV6):
    case __constant_htons(ETH_P_8021Q):
    case __constant_htons(ETH_P_8021AD):
        return true;
    default:
        return false;
    }
}

登录后复制

当 pfmemalloc 为真，且 skb_pfmemalloc_protocol 函数判断包协议不支持时，就会丢包。此外，代码中调用了 kfree_skb，这也验证了 dropwatch 的工作原理。

为了确定我们问题中丢包的协议类型，我使用了 systemtap 工具：

#! /usr/bin/env stap
probe kernel.function("__netif_receive_skb_core").label("drop") {
    printf("0x%04X\n", ntohs($skb->protocol))
}
// output
0x0004

登录后复制

systemtap 几乎可以为所欲为，甚至可以替换前面提到的 dropwatch。

根据我们对 Linux 源代码的分析，skb_pfmemalloc_protocol 函数支持的包 protocol 如下：

#define ETH_P_ARP 0x0806 /* Address Resolution packet */
#define ETH_P_IP  0x0800 /* Internet Protocol packet */
#define ETH_P_IPV6 0x86DD /* IPv6 over bluebook */
#define ETH_P_8021Q 0x8100  /* 802.1Q VLAN Extended Header  */
#define ETH_P_8021AD 0x88A8  /* 802.1ad Service VLAN */

登录后复制

而 systemtap 脚本检测到的包 protocol 为 0x0004，也就是路由器发出的 802.3 包：

#define ETHERTYPE_8023 0x0004 /* IEEE 802.3 packet */

登录后复制

因为这是系统不支持的包，所以被丢弃了。

其实，只要了解了问题的根源，使用 tcpdump 也可以捕获被系统丢弃的包，只需打印出包的 ether type，然后过滤掉操作系统支持的协议包，剩下的就是丢掉的包：

shell> tcpdump -i eth0 -e | grep -v -E 'ARP|IP|802.1Q|802.1AD'
802.3,length 105: LLC,dsap STP (0x42) Individual,ssap STP (0x42) Command,ctrl 0x03: STP 802.1s,Rapid STP,CIST Flags [Learn, Forward, Agreement],length 102

登录后复制

需要说明的是，CentOS 的新旧版本在处理此类问题上的行为有所不同：面对不支持协议的包，虽然 CentOS 的新旧版本都会丢弃它，但旧版不会更新丢包计数器（rx_dropped），新版却会更新丢包计数器（rx_dropped），具体细节就不展开讨论了，有兴趣的可以自行查阅。

以上就是记一次有惊无险的丢包调试经历的详细内容，更多请关注php中文网其它相关文章！