伺服器網路卡 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的魅力。