調試網路數據包被丟棄的原因
前言：
我有一個我目前正在測試的應用程序在
RHEL 6. 我的測試設置是安裝在嵌入式設備上的應用程序，通過乙太網電纜連接到 PC，該 PC 與執行 Linux 的 PC 上的虛擬機通信。pc 上的虛擬機（在 VMWare 工作站上）和嵌入式設備都具有靜態 IP 地址，因為它們需要通過乙太網電纜相互通信。在這種情況下，應用程序需要使用
pub-sub工具進行通信RTI DDS。這已經在無線環境和另一個有線環境中使用不同的 PC 但相同的虛擬機進行了測試，並且在這兩個環境中 pub-sub 都有效。問題：
在目前設置上測試 pub-sub 時，我們可以看到
wireshark從嵌入式設備傳遞的所有碎片數據包都傳遞到 PC 的主作業系統（本例中為 windows）。然而，當碎片數據包從主作業系統發送到虛擬機作業系統時，虛擬機只接收到最後一個接收到的數據包，wireshark其餘數據包被丟棄。到目前為止，我們已經嘗試禁用
firewalls和pinging設備，這些設備都可以正常工作並且沒有問題。因此，我們無法深入了解數據包被丟棄的原因。有什麼方法可以調試網路數據包被丟棄的方式和原因，甚至可以通過wireshark來調試，因為我們目前正在使用該工具？
一般來說，我懷疑 MTU（幀大小）是問題的根源。我有幾個理由和一些建議。
首先，這種行為因 L2 而異（它只發生在有線流量而不是無線流量中）。這本身就是可疑的，表明介面級別存在問題。
其次，數據包碎片是 MTU 未對齊的症狀。數據包碎片本身不是問題，但它不是最佳的，因為它會產生成本和額外的故障點。
第三，您的 Linux 客戶虛擬機僅收到“收到的最後一個數據包”，這是某些 VMware NIC 和版本的已知問題。
現在，由於主機正在接收任何情況，並且由於MTU 大小僅影響發送的數據包，因此您無法更改 VM 上的 MTU 並期望有任何不同。但是，您可以執行以下操作：
建議
確定 MTU 是否有問題
跑吧
ping -f -l (your host vm adapter mtu, which is a #) your.guest.ip.or.name，喜歡ping -f -l 1500 myguest。如果它在您使用
-l目前 MTU 的值時有效，那麼我錯了，請忽略。否則，請繼續降低該-l值直到它響應，然後將您的主機虛擬適配器設置為具有該 MTU。見http://www.thincomputing.net/2011/06/28/mtu-size-mismatch-a-major-cause-of-disconnections/在 vmware 工作站中使用不同的 vNic驅動程序
某些作業系統和某些 vNic 以及某些虛擬機管理程序存在已知問題。我在下面對已知 vmware 問題進行了一些研究，但只是嘗試在來賓上使用不同的 vNIC 驅動程序。如果您使用的是 E1000，請嘗試其中一款較新的。如果您使用的是 vmxnet3，請嘗試 2 或 E1000。等等。如果這修復了它，您可以保留它或查找您之前擁有的特定驅動程序，以了解如何從 vmware 修復它。
在您的主機上嘗試較低的 MTU
將主機上的 MTU 從現在的位置（可能大約 1500）降低到大約 1380。如果問題消失，請繼續增加它，直到達到大約 1468。離開它。