Linux ip выключить мультикаст
Обновлено: 04.07.2024
Настройка параметров сети, предотвращает потерю данных и настраивает сетевой стэк на максимальную полосу пропускания.
Системный буфер
Для передачи/приема данных по протоколу UDP нужно настроить буфер операционной системы.
Параметры размера буфера настраиваются в файле /etc/sysctl.conf
Рекомендуется использовать следующие значения для сетевых адаптеров 1G:
Для 10G сетевых адаптеров:
Для 40G сетевых адаптеров:
Чтобы применить изменения, перезагрузите систему или выполните команду:
Вы можете проверить текущие значения с помощью следующей команды:
Размер буфера сетевой карты
Для высоконагруженых серверов необходимо настроить буфер сетевой карты. Это позволит избежать потерь в системном буфере.
Здесь мы видим, что rx-буфер увеличен до максимума. Обычно найти верное значение довольно сложно. Наиболее оптимальным является некоторое «среднее» значение. С высокочастотным и многоядерным процессором (> 3GHz) вы можете получить хорошие результаты с максимальным размером буфера.
Пример команды для увеличения буфера:
RP filter
rp_filter - является технологией обеспечивающей защиту и безопасность сервера при использовании мультикаст - рассылок.
Если ваш сервер имеет несколько сетевых интерфейсов, рекомендуем прописать маршруты для мультикаст-групп. Если это не возможно, вы должны изменить настройки rp_filter.
Добавьте в файл /etc/sysctl.conf следующую запись:
Где eth0 - имя интерфейса.
Чтобы применить изменения, перезапустите систему или выполните команду:
Версия IGMP
Многие операционные системы отправляют запрос на подписку к мультикаст-группе в формате igmp v3
Если сетевой коммутатор не может работать с этим протоколом, или протокол не сконфигурирован - попытка подписки на мультикаст группу будет неудачной. Протокол igmp v2 поддерживается большинством коммутаторов.
Версия IGMP может быть настроена в файле /etc/sysctl.conf
Например, настройка IGMPv2 для интерфейса eth1:
net.ipv4.conf.eth1.force_igmp_version=2
Чтобы применить изменения, перезапустите систему или выполните команду:
Вы можете проверить версию IGMP с помощью tcpdump выполнив команду:
Затем попробуйте подписаться на мультикаст. Например:
sysctl.conf
Для высоконагруженных серверов рекомендуется добавить следующие записи в файл /etc/sysctl.conf
Чтобы применить изменения, перезагрузите систему или выполните команду:
Ключевые слова: missed, dropped, fifo, error, rx.
Нужно проверить ошибки RX. Некоторые сетевые карты предоставляют более подробную информацию о потерях:
Потери могут быть не только на сетевых картах вашего сервера. Они также могут находиться на порту сетевого оборудования. Вы можете узнать, как это увидеть из документации производителя сетевого оборудования.
Настройка и диагностика сетевой подсистемы с помощью netutils
Данный набор утилит позволяет диагностировать сетевые потери, настраивать сетевую подсистему и проводить некоторую другую диагностику.
Установка
network-top
Эта утилита нужна для оценки применённых настроек и отображает равномерность распределения нагрузки (прерывания, softirqs, число пакетов в секунду на ядро процессора) на ресурсы сервера, всевозможные ошибки обработки пакетов. Значения, превышающие пороговые подсвечиваются.
rss-ladder
Эта утилита распределяет прерывания сетевой карты на ядра выбранного физического процессора (по умолчанию на нулевой).
server-info
Данная утилита позволяет сделать две вещи:
server-info --show : посмотреть, что за оборудование установлено в сервере. В целом похоже на lshw, но с акцентом на интересующие нас параметры.
server-info --rate : найти узкие места в аппаратном обеспечении сервера. В целом похоже на индекс производительности Windows, но с акцентом на интересующие нас параметры. Оценка производится по шкале от 1 до 10.
Прочие утилиты
автоматически увеличивает буфер выбранной сетевой карты до оптимального значения.
отключает плавающую частоту процессора.
Примеры использования:
Пример 1. Максимально простой.
Дано:
один процессор с 4 ядрами.
одна 1 Гбит/сек сетевая карта (eth0) с 4 combined очередями
входящий объём трафика 600 Мбит/сек, исходящего нет.
все очереди висят на CPU0, суммарно на нём ?55000 прерываний и 350000 пакетов в секунду, из них около 200 пакетов/сек теряются сетевой картой. Остальные 3 ядра простаивают
Решение:
распределяем очереди между ядрами командой rss-ladder eth0
увеличиваем ей буфер командой rx-buffers-increase eth0
Пример 2. Чуть сложнее.
Дано:
два процессора с 8 ядрами
две NUMA-ноды
Две двухпортовые 10 Гбит/сек сетевые карты (eth0, eth1, eth2, eth3), у каждого порта 16 очередей, все привязаны к node0, входящий объём трафика: 3 Гбит/сек на каждую
1 х 1 Гбит/сек сетевая карта, 4 очереди, привязана к node0, исходящий объём трафика: 100 Мбит/сек.
Решение:
1 Переткнуть одну из 10 Гбит/сек сетевых карт в другой PCI-слот, привязанный к NUMA node1.
2 Уменьшить число combined очередей для 10гбитных портов до числа ядер одного физического процессора:
3 Распределить прерывания портов eth0, eth1 на ядра процессора, попадающие в NUMA node0, а портов eth2, eth3 на ядра процессора, попадающие в NUMA node1:
4 Увеличить eth0, eth1, eth2, eth3 RX-буферы:
Напоминание:
В случае с сетевыми картами с одной очередью распределить нагрузку между ядрами можно с помощью RPS, но потери при копировании пакетов в память это не устранит.
Распределение прерываний осуществляется на базе расчета хеш функции (остаток от деления) от совокупности таких данных: protocol, source and destination IP, and source and destination port. Технология называется: Receive-side scaling (RSS).
Сразу оговорюсь, что в этой статье не будет рассматривать сама технология и протокол UDP, для этого лучше обратиться к UDP, а потом к Multicast.
Итак, вся работа начинается с создания сокета и его «настройки». В общих чертах выглядит это так
1. создать сокет
2. сделать bind
3. подключится с Multicast группе.
Теперь по порядку
Тут все просто и без подвохов
Первое что мы должны сделать, это позволить использовать PORT повторно, т.к. помимо нас кто-то еще может работать с этим портом.
Функция setsockopt позволяет задать опции для сокета. Интересным моментом является то, что значение опции передается по указателю на void, т.к. некоторые опции требует не просто флаг включено/выключено, а структуры с дополнительными то данными.
Далее нам необходимо связать сокет с портом. А может еще и адресом? Тут вступает в силу первая проблема особенность — различная идеология ядер Windows и Linux. А именно то, что под Windows мы не можем забиндиться на адрес Multicast группы (получаем ошибку) и должны биндиться на INADDR_ANY
На Linux мы можем так же забиндиться на INADDR_ANY, но в этом случае мы будем получать все дейтаграммы пришедшие на забинденный нами порт. Для того чтобы получать дейтаграммы только из нужной группы, необходимо забиндиться именно на адрес этой группы (ну и порт конечно не забыть).
Главной особенностью Multicast является то, что наш хост не будет получать данных до тех пор пока мы не подключимся к Multicast группе. Подключение на уровне пользователя выглядит как установка опции для сокета.
где ip_mreq.imr_multiaddr это адрес мультикаст группы. А ip_mreq.imr_interface это адрес интерфейса, на котором мы ожидаем получать дейтаграммы. INADDR_ANY в данном случае говорит о том, что мы оставляем это право за ядром, которое выберет интерфейс исходя из таблицы роутинга. Далее ядро проверит не подключены ли мы уже к этой группе, и если нет, то отправит запрос на ближайший Multicast сервер. Тот в свою очередь дальше и т.д. После чего нам на хост будут отправлять дейтаграммы, отправляемые в данную Multicast группу.
Но что делать с Windows который забинден на INADDR_ANY? Он что будет получать все дейтаграммы отправленные на слушаемый порт? Судя по всему ядро Windows, при указании этой опции для сокета, само производит фильтрацию получаемых данных. И таким образом на сокет доставляются данные только из подписанных групп.
На Linux для того, чтобы получать данные на сокет только от подключенной Multicast группы, необходимо забиндиться на ее же адрес.
Если вы мне не верите (а я сам в это в начале не поверил) то поверьте ему
Unix Network Programming 3 издание. глава 21.6 страница 599
— Чтобы получить дейтаграмму многоадресной передачи, процесс должен присоединиться к группе, а также связать при помощи функции bind сокет UDP с номером порта, который будет использоваться как номер порта получателя для дейтаграмм, отсылаемых данной группе.
…
Связывая порт, приложение указывает UDP, что требуется получать отправляемые на этот порт дейтаграммы. Некоторые приложения в дополнения к связыванию порта также связывают при помощи функции bind адрес многоадресной передачи с сокетом. Это предотвращает доставку сокету любых других дейтаграмм, которые могли быть получены для этого порта.
Разочарую вас, в boost все аналогично API, никакой адаптации под единую логику не производится. Таким образом, используя его для написание кроссплатформенного приложение вам все равно придется делать
Пока писал пост, понял, что путь, предложенный для Linux, скрывает одно ограничение. Мы должны работать по принципу один сокет — одна Multicast группа. Так как навряд ли возможно забиндиться сразу не несколько адресов.
Обрисую ситуацию. Есть сервер, он вещает данные в несколько мультикаст групп на один порт.
Есть клиент, он желает получать от сервера данные только в нескольких группах. Тогда ему нужно предпринять следующие действия:
1. биндиться на INADDR_ANY
2. далее фильтровать все полученные дейтаграммы в ручную определяя их destination 1 адрес.
Процесс фильтрации полученных на сокете дейтаграмм по destination адресу вытекает из того, что возможна ситуация когда на машине клиента есть еще другой софт который подключается к каким то другим группам но с тем же портом и тогда оба сокета будут получать дейтаграммы со всех подключенных групп на этом порту.
Но при этом на лицо проблема избыточности данных.
Ну собственно об тих особенностях работы с Multicast я и хотел вам рассказать, не зная которых вы рискуете наступить на грабли.
PS. Для того что бы все это прочувствовать предлагаю проделать следующие шаги.
1. Собрать receiver
2. Собрать sender
Далее на Linux запустить
3. Запустить: receiver 0.0.0.0 239.192.100.1
4. Запустить: receiver 0.0.0.0 239.192.100.2
5. Запустить: sender 239.192.100.1
6. Убедить что оба receiver'a получат данные
Далее тоже запустить на Windows
7. Убедиться что данные получит только тот кому мы их отправили.
Настройка статической multicast-маршрутизации на дистрибутивах ALT Linux.
Содержание
Рассмотрим типичную схему multicast-маршрутизации с выделенным сервером, имеющим два сетевых интерфейса:
- eth0 — публичный интерфейс, на который придет поток от провайдера;
- eth1 — интерфейс в локальную сеть, в которой находятся клиенты.
Multicast-маршрутизация осуществляется по протоколу IGMP. IGMP (англ. Internet Group Management Protocol — протокол управления группами Интернета) — протокол управления групповой (multicast) передачей данных в сетях, основанных на протоколе IP. В данном руководстве используется IGMP версии 1.
На шлюзе должна быть разрешена пересылка сетевых пакетов (forwarding) и запущен демон multicast-маршрутизации. Мы рекомендуем использовать в качестве такого демона igmpproxy. При этом клиенты должны явно присоединиться к MC-группе. Вы можете явно назначить multicast-маршруты без этого требования к клиентам, если используете пакет smcroute.
Примечание: интерфейсы в дистрибутивах на базе Пятой платформы будут соответственно breth0 и breth1, однако мы не рекомендуем делать на них маршрутизацию.
Для начала необходимо установить дистрибутив ALT Linux и пакет демон multicast-маршрутизации igmpproxy и программу настройки статических маршрутов smcroute из соответствующего репозитория:
Также необходимы пакеты iptables net-tools iproute2, в дистрибутивах ALT Linux они присутствуют по умолчанию.
Для мониторинга можно установить пакеты tcpdump, wireshark и iperf
Все манипуляции осуществляются под правами пользователя root.
Файл /etc/igmpproxy.conf:
Для дистрибутивов на базе Пятой платформы файл /etc/igmpproxy.conf вместо eth0 и eth1 исполь-зуйте breth0 и breth1 соответственно.
1. Шлюз должен быть настроен для маршрутизации сетевых пакетов:
- Находится в режиме "Шлюз" в модуле "Брандмауэр" в дистрибутивах на базе Пятой платформы;
- или настраиваем вручную: в файле /etc/net/sysctl.conf параметр net.ipv4.ip_forward должен быть установлен в "1":
Также в файл /etc/net/sysctl.conf добавляем параметры: отключаем reverse path filtering для eth0 и для ядер 2.6.x указываем версию IGMP (igmpproxy поддерживает только IGMPv1 и IGMPv2 на внутреннем интерфейсе):
Примечание: после внесения изменений в этот файл необходимо перезагрузить компьютер.
2. Проверяем готовность к маршрутизации:
3. Настраиваем цепочки iptables для работы со специальными multicast-подсетями:
Пошли слухи, что провайдер предоставляет iptv. Слил плейлист, а там адреса вида: udp://@234.5.2.1:20000, udp://@234.5.2.2:20000 и т.д.
Если подключить напрямую к winxp, то vlc кажет тв.
Хочется раздать это дело через самосборный роутер на домашнюю сеть. Поставил igmpproxy.
Провайдер на eth0 c сетью 192.168.1.0/24. Интернет через pppoe — ppp0 и там статический ip. Домашняя сеть eth1 с 10.0.0.0/24.
iptraf при прослушивании eth1 говорит следующее:
Последних пакетов очень много, но они быстро заканчиваются.Что мне стоит попробовать или сделать, чтобы заработало?
Как здорово! Но очень не хочется только из-за iptv ставить freebsd.
Странно, но на роутере вообще не получается получить доступ к iptv. Ни через mplayer, ни через vlc. Выходит, что проблема скорее всего не в igmpproxy.
А еще FreeBSD 8.0 падает на роутинге да. С большим количеством маршрутов.
ПоGoogle на тему параметров ipv4:
rp_filter
force_igmp_version
Но ни mplayer, ни vlc не работают.
ТС, загляни в соседний трэд, там вроде советы и тебе подходят.
P.S. iZEN, не смеши людей, [фряшеый] mrouted - это ППЦ, мало того, что основан на сдохшем DVMRP, но сам по себе R.I.P. и смердит изрядно. фряха и динамический роутинг мультикаста - это два взаимоисключающих понятия.
@sda00 Благодарю, но ничего не помогло =(
mrouted тоже не запустился.
ничего не могу понять. вроде запросы идут. если при поднятом igmpproxy:
которой до этого не было. при этом на eth1 пусто. только :1900, что указаны в начале топика. но это не нужно, как я понял.но телевидения нет =(
форвард/роутинг мультикаста (динамический) - это комплексная задача. не торопись. начни с простого. выруби на роутере фаер (flush), проверь ядро:
помни, что твой роутинг может управлять только исходищими пакетами. потом настрой простой конфиг igmpproxy:
(в твоём конфиге выше везде eth0 - ясен пень, что нихера не будет. )
Не знаю, что там внутри (исходники не смотрел), но репортаж о первом полёте ПАКФА записал именно с IP TV на FreeBSD
Читайте также: