Как получить многоадресные данные на нестандартном интерфейсе многосетевого сервера
У меня есть сервер Linux с двумя сетевыми картами (eth0 и eth1), и я установил eth0 по умолчанию в "ip route". Теперь я хотел бы получать многоадресные пакеты на eth1. Я добавил "224.0.20.0/24 dev eth1 proto static link scope" в таблицу маршрутизации и подключаюсь следующим образом:
sock = socket(PF_INET, SOCK_DGRAM, IPPROTO_IP);
// port 12345, adress INADDR_ANY
bind(sock, &bind_addr, sizeof(bind_addr));
// multicast address 224.0.20.100, interface address 10.13.0.7 (=eth1)
setsockopt(sock, IPPROTO_IP, IP_ADD_MEMBERSHIP, &imreq, sizeof(imreq));
В соответствии с ip maddr он подключается к этой группе на правом интерфейсе, и tshark -i eth1 показывает, что я на самом деле получаю многоадресные пакеты.
Однако я не получаю никаких пакетов при звонке recvfrom(sock), Если я установлю "ip route default" на eth1 (вместо eth0), я получу пакеты через recvfrom. Это проблема с моим кодом или настройкой сети, и как правильно это сделать?
(обновление) решение: Кафе намекнуло, что это может быть та же самая проблема; действительно: после выполнения echo 0 > /proc/sys/net/ipv4/conf/eth1/rp_filter Теперь я могу получать многоадресные пакеты!
3 ответа
caf о том, что это дубликат получения многоадресной рассылки на сервере с несколькими интерфейсами (linux), ответил на это! (И я публикую это как ответ для ясности.) А именно, echo 0 > /proc/sys/net/ipv4/conf/eth1/rp_filter решает мою проблему.
Попробуйте добавить маску сети и указать 10.13.0.7 в качестве шлюза в записи таблицы маршрутизации.
Правильно, если у вас есть две сетевые карты с gw по умолчанию только на одной из них.
Многоадресная рассылка использует одноадресные маршруты для определения пути к источнику. Это означает, что если многоадресный путь отличается от одноадресного, то многоадресный путь завершится. Это механизм предотвращения петель, называемый проверкой RPF.
В этом случае приложение, связанное с NIC, фактически было вынуждено присоединиться к IGMP, когда маршруты одноадресной передачи были изучены от другого NIC со шлюзом по умолчанию. Так что проверка провалилась. Таким образом, нет данных.
Вам не нужно добавлять какие-либо статические маршруты. Это должно просто работать, когда вы изменяете значение rp_filter на 0.