Недавно я столкнулся с проблемами, когда неправильные MAC-адреса заполняли таблицы arp некоторых виртуальных машин Windows, работающих в облаке облачного провайдера. Например, если я пингую 10.1.2.3, некоторые виртуальные машины Windows показывают другой MAC-адрес, чем большинство других виртуальных машин. В результате эти несколько виртуальных машин Windows не могут достичь 10.1.2.3, но остальные виртуальные машины (как Windows, так и Linux) могут.
После запуска захвата пакетов источником неверных MAC-адресов, по-видимому, является MS-NLB-PhysServer-XX_, который включен вопубликованный список wireshark. Я не использую никакой MS-NLB, поэтому очень запутанно, что это за источник. Мой поставщик облачных услуг говорит, что это не от них. У меня такие вопросы:
- Есть ли хороший способ идентифицировать исходное устройство по его MAC-адресу, если я не являюсь его владельцем? Например, мне интересно, исходит ли оно от балансировщиков нагрузки нашего облачного провайдера.
- По каким причинам это исходное устройство может иметь неправильные MAC-адреса, которые оно отправляет другим устройствам? Например, почему у него неправильный MAC-адрес для 10.1.2.3 и других вновь созданных сетевых интерфейсов?
- По каким причинам только часть виртуальных машин получает неверные MAC-адреса из этого источника, а другие виртуальные машины в той же подсети получают правильные MAC-адреса из других источников?
решение1
Мы тоже столкнулись с этим, это происходит на наших узлах EKS Windows после перезагрузки. У нас есть узлы, которые присоединяются к домену для GMSA, что требует перезагрузки, поэтому эти экземпляры сразу увидели проблему.
Я открыл тикет в службу поддержки, и они предложили обходной путь: запустить скрипт выключения, выполнив следующее:
powershell.exe /c "get-hnsendpoint | remove-hnsendpoint"
exit
Было отмечено, что выход важен, поскольку он предотвращает зависание при отключении в течение определенного периода времени.
Я использовал этот ответ как основу для автоматизации этого процесса -https://stackoverflow.com/a/47709154
решение2
Если вы не являетесь владельцем другого устройства, я предполагаю, что это происходит потому, что оно находится в совершенно другой сети, а это значит, что вы не увидите его MAC-адрес, а увидите адрес ближайшего к вам устройства, которое будет направлять трафик на это другое конечное устройство.
Помните, что сквозная связь не осуществляется на уровне канала передачи данных (т. е. на уровне 2).
Наиболее вероятным сценарием здесь может быть то, что ваша маршрутизация настроена неправильно.некоторыйваших виртуальных машин и на уровне ОС, а не на уровне таблицы маршрутизации сети вашего облачного провайдера... или они находятся в разных сетях (возможно, в подсети AWS?) и имеют разные таблицы маршрутизации.
решение3
Добавляю это тоже как ответ.
У нескольких поставщиков облачных услуг естьдовольносвоеобразный взгляд на сетевое взаимодействие и относятся к нему так, что профессионал в области сетевых технологий счел бы его просто возмутительным; однако, это их способ работы, и нам просто приходится с этим смириться.
В Azure MAC-адреса просто не имеют никакого смысла; все записи таблицы ARP всегда указывают на 12-34-56-78-9a-bc, потому что все сетевые взаимодействия Azure обрабатываются на уровне IP, а ARP не существует и не работает вообще; виртуальная машина Azure не может просто закричать «У меня есть этот IP-адрес» (он же «беспричинный ARP»), потому что платформа Azure должна знать об этом, чтобы направлять трафик на эту виртуальную машину. Кластеризация Azure работает таким странным образом, что вам приходится размещать перед кластером очень необычный балансировщик нагрузки.
Честно говоря, я не знаю, как это работает в AWS, но полагаю, что это так же странно, если не хуже.