服务器网卡 RX 方向errors包一直在增长，换模块换尾纤都不好使，
眼看业务上线要延期
客户精神要崩溃，运维心想要遭罪
一、问题现象
服务器侧的运维人员在服务器上使用 ifconfig 命令发现每台服务网卡上都有错包，且一直在不停增长
通过图片可以看到网卡RX 方向有大量的 errors包，服务器侧运维人员反应一直在增长，而且有十几台服务器都有这种情况。
站在网络工程师的角度，第一时间肯定想着更换光模块更换光纤了，我的同事也是这么想的，结果在机房哐哐一顿搞，连续搞了好几天，也从其他接入交换机接入尝试过，情况还是一样，没有一点进展。到我接手的时候已经可以判断不是硬件问题，要搞清楚原因就要把错包抓出来看看到底是啥。
二、研究与发现
我先是协调服务器运维侧的人在服务器上进行了抓包，tcpdump 直接抓接口上的所有数据包，因为还没有上业务流量不是很大，这也给我们排错提供了便利，如果接口流量太大，errors包占比很小的话这个问题就真的棘手了。
我一边抓包一边打开网络论坛检索相关信息，CSDN、博客园、等网站 就搜服务器错包排查案例，看了十多个帖子，也算找到了一些有效信息。
2.1 linux网卡处理数据包流程
首先网络报文通过物理网线发送到网卡
网络驱动程序会把网络中的报文读出来放到 ring buffer 中，这个过程使用 DMA（Direct Memory Access），不需要CPU 参与
内核从 ring buffer 中读取报文进行处理，执行 IP 和 TCP/UDP 层的逻辑，最后把报文放到应用程序的 socket buffer 中
应用程序从 socket buffer 中读取报文进行处理
2.2 ethtool命令
ethtool ethx //查询ethx网口基本设置，其中 x 是对应网卡的编号，如eth0、eth1等等
ethtool –h //显示ethtool的命令帮助(help)
ethtool –i ethX //查询ethX网口的相关信息
ethtool –d ethX //查询ethX网口注册性信息
ethtool –r ethX //重置ethX网口到自适应模式
ethtool –S ethX //查询ethX网口收发包统计
ethtool –s ethX [speed 10|100|1000] [duplex half|full] [autoneg on|off] //设置网口速率10/100/1000M、设置网口半/全双工、设置网口是否自协商
linux内核相关的知识我是看的是似懂非懂，一直半解，在ethtool这个命令里面倒是有一个对本次排查非常有用的一个参数。
ethtool –S ethX //查询ethX网口收发包统计
如上图所示，这条命令可以看 linux 中看到更详细的统计信息。errors错包类型有很多种，这里我想的就是在这些统计信息字段里面找到跟网卡统计数量对得上的字段，然后误打误撞还真的找到了。
我先根据正则表达式发现这个 rx_oversize_pkts_phy 字段有点可疑
然后让服务器运维方确定这个字段和网卡的errors错包数量是不是一致的，结果发现差不多。
服务器那几个逼玩ansble还是挺6的，后面又用ansble批量把其他服务器跑了一遍
至此发现了所有服务器上网卡统计errors 包的类型都是 rx_oversize_pkts_phy
三、wireshark分析与排查
在wireshark中打开服务器上抓到的包，很快又发现了一连串非常可疑的数据包
通过MAC前缀发现是一个打印机厂家！！！
由于服务器没上业务，网卡数据包本来就没多少，其中大部分都是去发往这几台打印机的广播报文，到这里我几乎可以肯定这些就是我要找的垃圾数据，终于找到你，还好我没放弃！【手动痛哭】
后面我在交换机上通过源MAC查找，发现都是从一条专线发上来的，因为交换机和云池服务器都是trunk对接 而且放通了巨多vlan，所以专线的用户跟很多服务器都在一个广播域。
后面解决就简单了，直接把几台打印机的MAC 在专线接入交换机上做了 MAC黑洞过滤掉。下发黑洞后联系服务器方查看，果然网卡上的errors包不再增长了。
三、复盘总结
其实一直到最后我没搞清楚为什么服务器网卡会把打印机的包定义为 rx_oversize_pkts_phy包，我怀疑是服务器使用的私有协议，协议号0xd09e太大了，超出标准限制。
最后说一下为什么所有服务器会一直收到广播包，这里除了处于同一个广播域，还涉及交换机的处理机制，因为打印机和他的客户端使用私有的协议通信，通信方式不得而知，可能打印机是其他方式回复信息，所以交换机表项中一直没有学到打印机的MAC地址，遇到未知单播会直接泛洪处理。
三层交换机的处理过程:
1、交换机收到数据帧后，根据端口类型不同，进行不同的标签操作
2、以源 MAC 地址进行 MAC 地址表查找(在同一个 vlan 内查找): a、找不到对应的 MAC地址表(没有进行 MAC 地址学习),将源 MAC 和接口绑定形成一条新的 MAC 地址表项 b、能找到对应的 MAC 地址表项，但是端口号不一致(主机更换了接口)，用新的端口号覆盖原端口号;c、能找到对应的 MAC 地址表项，端口号也一致，清空该表项的老化时间(默认5min)
3、将目的 MAC和本设备的 MAC 地址进行比较:
3.1、相同则进行解封装(拆除数据链路层头部)，移交上层处理;
3.2、不同则进行 MAC 地址表的查找以目的 MAC 地址进行MAC 地址表查找(在同一个 van 内查找): a能找到对应的 MAC地址表项，从对应的接口转发该数据;b、找不到对应的 MAC 地址表项，在 vlan 内进行泛洪处理(除收到数据帧的接口以外，所有接口全部转发); c、找到对应的 MAC 地址表项，但是出接口和收到报文的接口是同一个，交换机就会丢弃该数据帧拆除数据链路层后，
4、拿目的p 和本设备的 P 地址进行比较:
4.1 相同则解封装(拆除网络层头部)，移交上层处理;
4.2 不同则进行 IP 路由表查找以目的IP 和路由的掩码进行“与”运算(0 和任何数都是0，只有1和1是1)，运算的结果和掩码对应的目的网段相同则匹配该路由:
能找到对应的路由(该路由是所有路由中掩码最长的一条)，则检查下一跳地址;
不能找到对应的路由，则丢弃该报文检查下一跳地址:1、下一跳地址不是直连下一跳地址，以查找到的下一跳地址再次进行路由查找;2、下一跳地址是直连下一跳，则以下一跳地址进行 ARP 表查找，找到对应的 MAC 地址，完成数据链路层封装，从对应的接口转发
反正我就是这样每次遇到这种问题就各种论坛搜索研究、百度。
在我看来每次使用wireshark都像一次奇妙的探险，这其中的趣味光看我的文章可能感受不到，还是要用多看多分析，猜测加上验证，才能体会wireshark的魅力。
