前言 ：
我有一个应用程序，我正在testing，在RHEL 6上运行。 我testing的设置是安装在embedded式设备上的应用程序，通过以太网电缆连接到与运行Linux的PC上的虚拟机进行通信的PC。 PC和embedded式设备上的虚拟机（在VMWare Workstation上）都有一个静态IP地址，因为它们需要通过以太网电缆相互通信。
在这种情况下，应用程序需要使用pub-sub工具进行通信RTI DDS 。 这已经在一个无线环境和另一个有线环境中用不同的PC而被testing过，但是在同一个虚拟机上，并且在pub-sub的这两个环境中都已经工作了。
问题：
在当前设置下testingpub-sub时，通过wireshark可以看到从embedded式设备传送的所有碎片数据包被传送到PC的主操作系统（在这种情况下是windows）。 但是，当分片数据包从主操作系统发送到虚拟机操作系统时，虚拟机只接收在wireshark看到的最后一个数据包，其余数据被丢弃。
到目前为止，我们已经试图禁用firewalls和pinging设备，这些设备都能正常工作，没有问题。 因此，我们不知道为什么数据包被丢弃。
有什么方法可以debuggingnetworking数据包被丢弃的方式和原因，甚至可能通过wireshark，因为我们正在使用该工具？
在一般意义上，我怀疑MTU（帧大小）是问题的根源。 我有几个原因和一些build议。
首先，这种行为因L2而异（只发生在有线stream量而不是无线）。 这本身就是可疑的，并表明在界面层面存在问题。
其次，数据包碎片是MTU错位的一个症状。 数据包碎片本身并不是一个问题，但它不是最佳的，因为它会产生开销和额外的故障点。
第三，您的Linux访客虚拟机仅接收到“收到的最后一个数据包”，这是某些VMware网卡和版本的已知问题。
现在，由于主机正在接收任何情况，并且由于MTU大小仅影响发送的数据包 ，因此无法更改虚拟机上的MTU并期望有任何不同。 但是，您可以执行以下操作：
运行ping -f -l (your host vm adapter mtu, which is a #) your.guest.ip.or.name ，就像ping -f -l 1500 myguest 。
如果它使用当前MTU的-l值，那么我错了，忽略。 否则，保持降低-l值直到它做出响应，然后将主机虚拟适配器设置为具有该MTU。 见http://www.thincomputing.net/2011/06/28/mtu-size-mismatch-a-major-cause-of-disconnections/
某些操作系统和某些vNic以及某些pipe理程序存在已知问题。 我在下面列出了一些已知的vmware问题的研究，但只是尝试在guest虚拟机上使用不同的vNIC驱动程序。 如果您正在使用E1000，请尝试更新的一个。 如果您使用vmxnet3，请尝试2或E1000。 等等。如果修复了这个问题，你可以保留它，或者查看你之前find的具体驱动程序，找出如何从vmware中修复它。
将主机上的MTU从现在（可能在1500年左右）降低到1380年左右。如果问题消失，请继续增加，直到达到1468左右。