在将服务器从 centos 5 升级到 centos 7（内核版本 3.10.0-693）后，我在服务器上偶然发现了一个重大问题：网卡 eth0 在接收（rx）数据时存在规律性丢包，每一两秒丢一个包。
我首先怀疑可能是网卡的 ring buffer 容量不足，于是使用「ethtool」工具进行检查：
shell> ethtool -g eth0Ring parameters for eth0:Pre-set maximums:RX: 256RX Mini: 0RX Jumbo: 0TX: 256Current hardware settings:RX: 256RX Mini: 0RX Jumbo: 0TX: 256
虽然 ring buffer 确实显得较小，但当前硬件设置已达到预设的最大值，无法进一步扩大。为了进一步确认网卡是否存在丢包问题，我继续使用「ethtool」进行检查：
shell> ethtool -S eth0no stats availableshell> ethtool -i eth0driver: virtio_netversion: 1.0.0firmware-version:expansion-rom-version:bus-info: 0000:00:04.0supports-statistics: nosupports-test: nosupports-eeprom-access: nosupports-register-dump: nosupports-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/eth0shell> cd /sys/devices/pci0000:00/0000:00:04.0/virtio1/net/eth0shell> cd statisticsshell> grep . * | grep rxrx_bytes:633037730314rx_compressed:0rx_crc_errors:0rx_dropped:206975rx_errors:0rx_fifo_errors:0rx_frame_errors:0rx_length_errors:0rx_missed_errors:0rx_nohandler:0rx_over_errors:0rx_packets:4717658080
虽然 rx_dropped 值不为零，但 rx_errors 等错误计数器都为零，这表明 ring buffer 没有溢出，否则 rx_fifo_errors 等错误计数器不可能为零。因此可以推断：网卡已经将数据完整地传递给了操作系统，丢包问题出在操作系统层面。
为了确定操作系统在哪里丢包，我使用了 dropwatch 工具：
shell> dropwatch -l kasInitializing kallsyms dbdropwatch> startEnabling monitoring...Kernel monitoring activated.Issue Ctrl-C to stop monitoring6 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/kallsymsffffffff815869b0 t __netif_receive_skb_coreffffffff81587170 t __netif_receive_skbffffffff815871d0 t netif_receive_skb_internalffffffff81587290 T netif_receive_skbffffffff81587300 t napi_gro_completeffffffff81587400 T napi_gro_flushffffffff81587490 T napi_complete_doneffffffff81587550 T napi_completeffffffff81587570 T sk_busy_loopffffffff81587830 t net_rx_actionffffffff81587bb0 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 的工作原理。
白瓜面试
白瓜面试 – AI面试助手,辅助笔试面试神器
40 查看详情
为了确定我们问题中丢包的协议类型，我使用了 systemtap 工具：
#! /usr/bin/env stapprobe kernel.function("__netif_receive_skb_core").label("drop") { printf("0x%04Xn", ntohs($skb->protocol))}// output0x0004
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），具体细节就不展开讨论了，有兴趣的可以自行查阅。
以上就是记一次有惊无险的丢包调试经历的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/480871.html
微信扫一扫 
支付宝扫一扫 
