NLB многоадресной рассылки Windows с клиентами Linux

У меня (от имени клиента, во всяком случае) есть некоторые проблемы с доступом Linux к многоадресному NLB-кластеру, расположенному на Hyper-V (ожидаю получения дополнительной информации о том, какая версия, но я не думаю, что версия слишком актуальна, потому что это кажется проблема на стороне клиента).

В кластере NLB есть два члена. Каждый из них имеет свой собственный MAC-адрес (01:xx:xx:xx:xx:xx), как обычно в многоадресном режиме. Они оба также отвечают на общий MAC-адрес многоадресной рассылки для кластера (03:xx:xx:xx:xx:xx), что, как кажется, работает многоадресный NLB.

Проверка IP-адреса кластера с компьютера с Windows работает нормально, консоль отображает вывод, который вы ожидаете увидеть (отправлено 4, получено 4 и т. Д.). Если вы используете Wireshark во время пинга, вы можете увидеть, что поток выглядит примерно так:

ClientIP-ClientMAC -> ClusterIP-ClusterMAC : ICMP echo request
ClusterIP-Node1MAC -> ClientIP-ClientMAC   : ICMP echo response
ClusterIP-Node2MAC -> ClientIP-ClientMAC   : ICMP echo response (duplicate response from the second node)
ClientIP-ClientMAC -> ClusterIP-ClusterMAC : ICMP destination unreachable (seems to be the client discarding the second ping response, and using the ClusterMAC because that's what's in its ARP table, even though that's not the MAC that the frame was received from)

Таким образом, исходный поток немного странный, но кажется, что это почти так; важно то, что пинг в этом сценарии работает.

Однако в сети также есть устройство на базе Linux. Это не в состоянии успешно пропинговать кластер NLB, и когда tcpdumping подобный сеанс пинга, он в основном заканчивается после отправки эхо-запроса. Таблица ARP является правильной и показывает MAC-адрес многоадресной рассылки IP-адреса кластера (03:xx:xx:xx:xx:xx), исходящий кадр имеет правильный MAC-адрес. Однако в tcpdump ответ не отображается.

Возможно ли, что ядро ​​Linux видит возвращение кадра ответа ICMP, отметив, что MAC-адрес - это другой MAC-адрес, отличный от того, который использовался в исходящем кадре, и затем отбрасывает его перед tcpdump (или ping, работающим в пространстве пользователя).) есть шанс увидеть это?