最近又遇到一个类似的问题，也是在tcpdump抓到的包里没有找到应该看到的包，搞得很迷惑。这次是现场技术给研发挖了一个坑，给带偏了。研发自己抓包，发现根本就是没有丢在主机和虚拟机之间，也不是Linux内核丢掉了包。

那怎么回事呢？如果研发从主机上抓的没有问题，而是技术支持在虚拟机上抓的有问题。就这个对比问题的发生情况，我们有几个怀疑点，一个是就是人与人的不同，另一个是抓的地方不一样，经过缜密的分析，环境的问题不大，倒是人的差别不小。因为大家对于tcpdump的使用习惯非常的不同，现场由于对现场产品的操作的高要求，可能会考虑所抓包的大小问题，当然是期望在抓取文件比较小的时候，同时可以定位问题；而研发的这种潜意识要小一些，不是将磁盘空间的大小排在第一位，而是将调查问题的原因考虑在第一位。这样导致的一个差别，就是tcpdump工具使用的选项上有区别。
比如这个-s的使用：-s snaplen；这个是固定抓取包的大小，如果实际的包太大，也会抓取不全。
–snapshot-length=snaplen

Snarf snaplen bytes of data from each packet rather than the default of 262144 bytes. Packets truncated because of a limited snapshot are indicated in the output with ``[|proto]‘’, where protois the name of the protocol level at which the truncation has occurred.
Note that taking larger snapshots both increases the amount