У нас есть система из нескольких полок. Контроллеры полки подключены к коммутатору LAN полки. Полки соединены между собой через порты коммутатора LAN.
Простой пример двух полок:
Полка 1 CPU <-----> Полка 1 LAN Switch <-----> Полка 2 LAN Switch <-----> Shelf 2 CPU
После запуска полки согласовывают с помощью так называемых сообщений обнаружения в собственной сети VLAN свою роль и идентификатор полки. Для этого мы используем многоадресные UDP-пакеты.
Сетевые интерфейсы:
Shelf 1 UDP multicast packets shelf 2
eth.VLAN --- eth <---------------------------------> eth --- eth.VLAN
NwIfIp NwIfIp
Адреса MA C на сетевых интерфейсах уникальны, поскольку на каждой полке имеется сохраненная уникальная МА C адрес. IP-адреса сетевого интерфейса содержат идентификатор полки и, таким образом, обычно являются уникальными. Но в этом особом случае после запуска случается так, что разные полки имеют один и тот же идентификатор полки до согласования данных полки. Таким образом, на интерфейсе eth.VLAN шельфа 1 и полки 2 есть два идентичных IP-адреса. Многоадресные UDP-пакеты от полки 1, полученные полкой 2, игнорируются сокетом, поскольку исходный IP-адрес идентичен адресу сетевого интерфейса eth.VLAN. , Пока IP-адреса разные, все работает нормально.
Есть ли способ заставить многоадресный сокет UDP принимать пакеты с исходным IP-адресом, равным адресу получаемого сетевого интерфейса?
Найдена следующая ссылка .
Почему многоадресные сообщения с тем же IP-адресом источника игнорируются
Они утверждали, что включение обратной связи с IP_MULTICAST_L OOP решит проблему. Но в нашем случае это не так. Мы возвращаем отправленное сообщение обратно, но сообщения извне с тем же IP-адресом по-прежнему игнорируются.
Мы пробовали несколько вариантов sock (IP_ADD_SOURCE_MEMBERSHIP, IP_UNBLOCK_SOURCE), но ничего не помогло.
Есть какие-нибудь идеи? решить проблему?