Многоадресная рассылка Redhat Enterprise Linux 6

Я пишу приложение, которое получает многоадресные данные на новый сервер Redhat Enterprise Linux 6. Группа поддержки дает мне приложение, которое используется для проверки того, может ли сервер получать многоадресный поток данных.

Как только я запускаю тестовое приложение, а также запускаю tcpdump, я вижу поступающие многоадресные данные, например,

12:58:21.645968 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 729
12:58:21.648369 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 969
12:58:21.649406 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 893
12:58:21.651823 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 604
12:58:21.654079 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 913
12:58:21.656724 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 1320
12:58:21.658194 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 124
12:58:21.658226 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 217
12:58:21.658348 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 182
12:58:21.658625 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 1014
12:58:21.659592 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 135
12:58:21.659842 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 242
12:58:21.660674 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 242
12:58:21.660743 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 84
12:58:21.662327 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 84
12:58:21.669154 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 161
12:58:21.669365 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 166
12:58:21.670792 IP 10.26.12.22.60002 > 238.230.230.100.60002: UDP, length 49
12:58:21.670796 IP 10.26.12.22.60002 > 238.230.230.100.60002: UDP, length 49
12:58:21.670798 IP 10.26.12.22.60002 > 238.230.230.100.60002: UDP, length 49
12:58:21.670799 IP 10.26.12.22.60002 > 238.230.230.100.60002: UDP, length 49

Но приложение не может принять какой-либо поток данных, т. е. приложение работает так, как будто подписка на многоадресные данные не удалась.

Служба поддержки уверяет, что с тестовым приложением проблем нет, потому что на других серверах оно работает нормально. Поскольку у меня новый сервер, возможно, некоторые настройки на сервере неверны.

Мне интересно, какие настройки Linux мне искать, которые потенциально могут помешать приложению получать многоадресные данные, даже если tcpdump может видеть данные. Отсутствуют библиотеки или пакеты?

Спасибо.


linux multicast redhat tcpdump
person 2607    schedule 26.03.2012    source источник

Ответы (3)


arrow_upward
3
arrow_downward

Во-первых, стоит проверить, что в RHEL 6 включена поддержка многоадресной рассылки на уровне ядра. (вероятно, но у меня нет RHEL 6 для проверки) Убедитесь, что файл /proc/net/igmp существует.

Также убедитесь, что диапазон многоадресных адресов направляется на ожидаемый интерфейс. Если это неверно, у вас могут быть некоторые интересные симптомы, когда вы получаете многоадресную рассылку только тогда, когда tcpdump (беспорядочно) обнюхивает пакеты. Это также может иметь место, если ваша сетевая карта не поддерживает должным образом многоадресную рассылку. Некоторым старым сетевым адаптерам также может потребоваться установить неразборчивый режим для получения любой многоадресной рассылки, независимо от настройки многоадресной рассылки, показанной в ifconfig.

Еще одна вещь, которую нужно сделать, это проверить содержимое файла /proc/net/igmp во время работы вашего тестового приложения. Файл /proc/net/igmp будет содержать список всех адресов групп многоадресной рассылки, которые активно получает сервер. Если в столбце «Группа» есть запись, соответствующая групповому адресу многоадресной рассылки, который должно получать тестовое приложение (в вашем случае 238.6.6.36 и 238.230.230.100), то параметры сокета IP_ADD_MEMBERSHIP (или IP_ADD_SOURCE_MEMBERSHIP), вероятно, имеют был вызван правильно и на правильном сетевом адаптере. Обратите внимание, что в столбце Группа перечислены адреса группы многоадресной рассылки в шестнадцатеричном формате и наоборот, поэтому 238.6.6.36 будет отображаться как 240606EE.

Ваша ситуация может быть более сложной, если у вас есть многоадресный маршрутизатор (например, Xorp, igmpproxy), работающий на той же машине, на которой вы запускаете тестовое приложение. В этом случае вам также следует изучить файлы /proc/net/ip_mr_vif и /proc/net/ip_mr_cache, чтобы убедиться, что в них есть соответствующие записи.

person Andrew Edgecombe    schedule 29.03.2012
comment
Спасибо Андрей за добрый ответ. Поскольку я не эксперт по сетям, я передам это в службу поддержки. - person 2607; 29.03.2012
comment
Полезная информация, у меня такая же проблема. Не знал о /proc/net/igmp, но использовал netstat -g. Все еще не нашел проблему - person easytiger; 12.06.2014

arrow_upward
2
arrow_downward

Пожалуйста, проверьте уровень коммутатора. В моем случае я застрял с кластеризацией. Мой кластер будет работать только на многоадресной рассылке. Но я столкнулся с потерей пакетов в многоадресной рассылке. Это было слишком странно для меня. Но в конце концов я получил решение от одного из моих лучших друзей (Google). Я только что отключил IGMP на своем уровне коммутатора, и он работает нормально.

person user1894704    schedule 11.12.2012

arrow_upward
1
arrow_downward

У меня была похожая проблема на машине RHEL 6. Я решил это, добавив требуемый порт UDP в разрешенные порты через брандмауэр. Попробуйте добавить udp порт 50002.

person Steve Huston    schedule 28.03.2012
comment
Спасибо за ваш ответ. И selinux, и iptable отключены на сервере. Что происходит, так это то, что перед обработкой многоадресных данных приложение требует моментальный снимок из другого источника одноадресных данных, и этот порт источника одноадресной рассылки не открыт. - person 2607; 29.03.2012