Многоадресная рассылка Redhat Enterprise Linux 6 - PullRequest
Новая
       37

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

0 голосов
/ 26 марта 2012

Я пишу приложение, которое получает многоадресные данные на новом сервере 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 мог видеть эти данные.Отсутствуют библиотеки или пакеты?

Спасибо.

Ответы [ 3 ]

3 голосов
/ 29 марта 2012

Прежде всего, стоит проверить, что в 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), вероятно, имеют был вызван правильно, и на правильном NIC. Обратите внимание, что в столбце «Группа» перечислены адреса групп многоадресной рассылки в шестнадцатеричном и обратном виде, поэтому номер 238.6.6.36 будет указан как 240606EE.

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

2 голосов
/ 11 декабря 2012

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

1 голос
/ 29 марта 2012

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

...