Предисловие:
У меня есть приложение, которое я сейчас тестирую и работающее на RHEL 6. Настройка для моего теста - это приложение, установленное на встроенном устройстве, подключенном кабелем Ethernet к ПК, который взаимодействует с виртуальной машиной на том ПК, на котором запущен Linux. Виртуальная машина (на VMWare Workstation) на ПК и встроенное устройство имеют статический IP-адрес, поскольку им необходимо связываться друг с другом по кабелю Ethernet.
Приложение должно обмениваться данными, используя pub-sub инструмент в этом случае RTI DDS. Это было протестировано в беспроводной среде и другой проводной среде с другим ПК, но с той же виртуальной машиной, и в обеих этих средах работает pub-sub.
Проблема:
При тестировании pub-sub на текущей настройке мы можем увидеть wireshark все фрагментированные пакеты, доставленные от встроенного устройства, доставляются в основную операционную систему ПК (в данном случае Windows). Однако, когда фрагментированные пакеты отправляются из основной операционной системы в операционную систему виртуальных машин, виртуальная машина получает только последний полученный пакет, как показано на wireshark а остальные отбрасываются.
До сих пор мы пытались отключить firewalls и pinging устройства друг от друга, которые все работают правильно и не имеют проблем. Таким образом, мы не смогли понять, почему отбрасываются пакеты.
Каким способом можно отладить, как и почему отбрасываются сетевые пакеты, возможно, даже возможно через wirehark, поскольку в настоящее время мы используем этот инструмент?
В общем, я подозреваю, что MTU (размер кадра) является корнем проблемы. У меня есть несколько причин и несколько предложений.
Во-первых, это поведение зависит от уровня L2 (это происходит только с проводным трафиком, а не с беспроводным). Это само по себе подозрительно и предполагает наличие проблемы на уровне интерфейса.
Во-вторых, фрагментация пакетов является признаком несовпадения 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.
Если это работает при использовании -l значение вашего текущего MTU, то я ошибаюсь и игнорирую. В противном случае продолжайте понижать -l значение до тех пор, пока он не ответит, затем установите для виртуального адаптера хоста этот MTU. Видеть http://www.thincomputing.net/2011/06/28/mtu-size-mismatch-a-major-cause-of-disconnections/
Существуют известные проблемы с некоторыми ОС, определенными vNic и некоторыми гипервизорами. Я включил некоторые исследования известных проблем с vmware ниже, но просто попробуйте использовать другой драйвер vNIC на гостевой машине. Если вы используете E1000, попробуйте один из более новых. Если вы используете vmxnet3, попробуйте 2 или E1000. И т. Д. Если это исправит, вы можете либо оставить его, либо найти конкретный драйвер, который у вас был ранее, чтобы узнать, как исправить его с помощью vmware.
Уменьшите MTU на вашем хосте с того места, где оно было сейчас (вероятно, около 1500), до примерно 1380. Если проблема исчезнет, продолжайте увеличивать его, пока не достигнете 1468. Оставьте это.