Wireshark看到Ethernet frame check sequence incorrect??
 

鵝有user反映mail server連不到後端的Exchange,連過去一看小封包是Ok的,但大封包會看到一坨Ethernet frame check sequence incorrect(L2都過不了了,那L3/L4不work也是天經地義的:think: )....

鵝當下的反應是把NIC(BCM5719:flash: )的offloading關掉,關掉後問題的確是解決了(未使用到的bge1 RXCSUM/TXCSUM/TSO4 default是on的,bge0的RXCSUM/TXCSUM/TSO4是被鵝關掉的:ase)....

可是後來仔細一想,現代的Ethernet MAC在遇到bad frame時應該會直接drop掉才對(i.e. Wireshark理論上是看不到L2的bad frame的),那為啥鵝會看到那些Ethernet frame check sequence incorrect,而且把offloading關掉之後,問題也解決了(誤打誤撞:o)...

後來鵝試著在lab重建現場,最方便而且還算精確的方式是在ESXi上透過DirectPath I/O讓VM直接控制Ethernet MAC,然後產生大量traffic,看能不能重現一樣的狀況,如果看到一樣的狀況就只好推測是OS/driver相容性之類的問題,沒有的話就可能是user site的問題,建了兩個Linux VM測了半天,傳了上TB的garbage,就是沒看到一樣的狀況,問題是鵝家的產品是based on BSD的,BSD VM卻無法透過DirectPath I/O直接控制NIC(VM的kernel boot起來時有看到Ethernet MAC,但要initial PHY時失敗,所以不work:o),換插另一張I社的X340-T4時Linux和BSD就都可以work,不過這樣就失去重建現場的意義了,請問一下有網友搞過類似的測試嗎:confused::confused:....

許多年以前,我有看過所謂的 Ethernet Frame Oversized 這種Error messages ....

當初的環境是很多的問題造成 !! 條列如下

1. 純Layer 1 的Hub
2. UTP網路線亂做(色線照排,沒依照568B/568A做法)
3. 螃蟹卡橫行

鵝大的狀況,只有考慮末端點的問題,沒考慮中間經過的L2 switch的問題??
我目前所管轄的end user site 還有古老的D-Link L2 switch hub (褐色鐵殼) , 很想把它給OOXX掉.... :ase

剛在Mobile01有網友提供了一膽看法,鵝順便轉貼一下了,那些Ethernet frame check sequence incorrect看來是本機發出的封包(48.53->48.169:think: ),不是收到的封包,而且鵝確定Wireshark中Validate Ethernet checksum if possible是enable的(不然不會顯示那些錯誤:think: ),就算driver層有bug造成TSO/TXCSUM不work,MAC層產生的Ethernet checksum通常還是對的,而不會有看到checksum error的機會(libpcap capture的點不同的話,是有可能看到checksum還是0x0的封包,但在此checksum是已經填了,只是填錯了:flash: ),不過事隔這一段期間,鵝已經從那個職位畢業了,所以也看不到現場了:ase:ase....

鵝大，我有解過一樣的問題，後來我發現是Broadcom某系列晶片的Checksum offloading有一些bug，關掉就沒事了。

你可參考這篇文章，問題應該和你描述相同。

https://social.technet.microsoft.co...rum=winserverPN