Сети для самых маленьких. часть девятая. мультикаст / хабр

Мультикастовые MAC-адреса

Так какие же MAC-адреса получателей подставляются в заголовок Ethernet таких пакетов? Широковещательные? Нет. Существует специальный диапазон MAC-адресов, в которые отображаются мультикастовые IP-адреса.

Эти специальные адреса начинаются так: 0x01005e и следующий 25-й бит должен быть 0 (попробуйте ответить, почему так). Остальные 23 бита (напомню, всего их в МАС-адресе 48) переносятся из IP-адреса.

Здесь кроется некоторая не очень серьёзная, но проблема. Диапазон мультикастовых адресов определяется маской 224.0.0.0/4, это означает, что первые 4 бита зарезервированы: 1110, а оставшиеся 28 бит могут меняться. То есть у нас 2^28 мультикастовых IP-адресов и только 2^23 MAC-адресов — для отображения 1 в 1 не хватает 5 бит. Поэтому берутся просто последние 23 бита IP-адреса и один в один переносятся в MAC-адрес, остальные 5 отбрасываются.

Multicast MAC Address

Фактически это означает, что в один мультикастовый MAC-адрес будет отображаться 2^5=32 IP-адреса. Например, группы 224.0.0.1, 224.128.0.1, 225.0.0.1 и так до 239.128.0.1 все будут отображаться в один MAC-адрес 0100:5e00:0001.

Если взять в пример дамп потокового видео, то можно увидеть:

Дамп мультикаста

IP адрес — 224.2.2.4, MAC-адрес: 01:00:5E:02:02:04.

Есть также другие мультикастовые MAC-адреса, которые никак не относятся к IPv4-мультикаст (). Все они, кстати, характеризуются тем, что последний бит первого октета равен 1.

Естественно, ни на одной сетевой карте, не может быть настроен такой MAC-адрес, поэтому он никогда не будет в поле Source MAC Ethernet-кадра и никогда не попадёт в таблицу MAC-адресов. Значит такие кадры должны рассылаться как любой Unknown Unicast во все порты VLAN’а.

Всего, что мы рассматривали прежде, вполне достаточно для полноценной передачи любого мультикастового трафика от потокового видео до биржевых котировок. Но неужели мы в своём почти совершенном мире будем мирится с таким безобразием, как широковещательная передача того, что можно было бы передать избранным?

Вовсе нет. Специально для перфекционистов придуман механизм IGMP Snooping.

Мультикаст настройка

К сожалению, настройка во многом зависит от той модификации, к которой принадлежит ваш роутер. Перед пользователем стоит задача: правильно задействовать данную функцию на своем маршрутизаторе. Давайте коротко разберем тот вариант, который может подойти роутерам от компании ASUS. Для начала включаем любой девайс (телефон, планшет, ноутбук) и подключаем его к вашему домашнему Wi-fi. Открываем браузер и вводим адрес 192.168.1.1. Наверняка он будет правильным, но стоит на всякий случай его уточнить в инструкции (руководство пользователю) к роутеру. Логин и пароль, если вы ничего не меняли будет идентичным – admin.

На открывшемся сайте мы переходим во вкладку ЛВС – «Маршрут». Находим пункт многоадресная маршрутизация. Включаем его, ставим галочку. Конечно же, не забудем сохранить настройки. Далее открываем вкладку «управление девайсом» — WAN – «Интернет-соединения» и даем определенному порту, например, второму, эту задачу.

IPTV через приставку

Для работы IPTV через приставку рекомендуется использовать функцию «Bridge». Таким образом мы настраиваемLANпорты на режим свитчинга сWAN. Плюс ко всему, мы получаем возможность подключить кабель провайдера не в WAN, а в тот LAN порт, что объединен с WAN’ом. Сразу замечу, данную функцию поддерживают не все роутеры. Например, в роутерах TP-LINK эта функция присутствует в меню Network — Bridge (Сеть — Мост), в Asus она называется Choose WAN Bridge Port и т.п. Для функционирования IPTV необходимо лишь выбрать LAN порт, который мы будем использовать для подключения IPTV приставки.

Для тех кто хочет использовать большее количество приставок, имеется возможность выбрать два порта (Например, LAN3 и LAN4, если у вас две приставки). Если ваша модель wi-fi роутера не имеет поддержку «Bridge» и для вашего провайдера достаточно поддержки мультикаста (протокол IGMP), вы сможете смотреть IPTV через приставку.

Для того чтобы не искать проблемы передачи своего IP телевидения там, где ее нет, проверьте, работает ли телевидение без роутера. Для этого подключите компьютер к кабелю провайдера напрямую. Если IPTV не подаст жизненных признаков, то скорее всего проблема у вашего провайдера. Обратитесь в техническую поддержку. А в положительном случае прямого подключения, следует выяснить у тех. поддержки, достаточно ли мультикаста для работы IP телевидения.

Пользователям, чьи модели роутеров не поддерживают функции Bridge, но телевидение работает с перебоями («рассыпается» картинка и «заикается» звук) стоит обратить внимание на загруженность их роутеров. Особенно это касается тех, кто обладает большой скоростью скачивания, чрезмерной нагрузкой (большое количество активных торрент-закачек, работают в DC++ и т.п.)

Решить эти проблемы можно ограничением скорости скачивания, лимитировать количество одновременных соединений до 50. Для тех, кто использует модели без поддержки Bridge рекомендуется подключать не более одной приставки IPTV. Если вы используете две (или более приставки), а роутер не поддерживает функции Bridge, то вы можете использовать обычный свитч. Свитч необходимо установить перед роутером. К свитчу будут подключены две приставки IPTV, кабель вашего провайдера, а кабель от роутера в порт WAN.

Как настроить IPTV

Например, настройка IPTV на роутере D-Link DIR-300 и подобных моделей сводится к установке одной лишь галочки в пункте «Enable multicast streams»:

Лично для меня, настройка IP телевидения по проводному соединению сводилась к нескольким шагам (на примере роутера Asus 520GU):

Необходимо зайти в раздел WAN, предварительно активировав DHCP
перейти во вкладку Общее
найти пункт Выбор порта IPTV STB — выбираем из списка тот порт, к которому будет подключена IPTV-приставка.
Нажимаем Применить и все.

Это пример наиболее простых способов настройки IPTV.

Настройка IPTV на роутере ASUS

Теперь я опишу 2 способа настройки IPTV через роутер RT-G32 B

Внимание! Описанную инструкцию по настройке IPTV можно использовать и на других моделях роутеров Asus для наглядности, и не только Asus в практическом и теоретическом применении. 1 способ

Перейдите в раздел ЛВС —> Маршрут и поставьте галочку “Включить многоадресную маршрутизацию” – “Yes”. Сохраняем – “Применить”

1 способ. Перейдите в раздел ЛВС —> Маршрут и поставьте галочку “Включить многоадресную маршрутизацию” – “Yes”. Сохраняем – “Применить”.

В данном случае в локальную сеть будет транслироваться multicast поток для VLC плеера без изменений.

Преимущества данного способа:
1. Никаких дополнительных настроек VLC плеера производить не надо.

Недостатки:
1. Возможность подключения компьютера для просмотра IPTV только через витую пару (Ethernet-кабель).
2. Падение скорости интернет соединения на других компьютерах в локальной сети, в момент воспроизведения IPTV.
3. Сильная нагрузка на маршрутизатор.
4. Излишний multicast трафик внутри сети.

2 способ. Необходимо настроить функцию ”IPTV UDP Multicast to HTTP Proxy”. Перейдите в раздел ЛВС —> Маршруты и поставьте галочку “Включить многоадресную маршрутизацию” – “Yes”, и в поле ”IPTV UDP
Multicast to HTTP Proxy” выберите произвольный порт. Например, 2323. Сохраните изменения – “Применить”.

Преимущества данного способа:

Возможность смотреть IPTV на компьютере по WiFi соединению.
Остальные компьютеры в локальной сети не испытывают падения скорости при интернет-соединения.
Роутер не перегружается.
Multicast трафик во внутреннюю сеть не транслируется, а VLC плеер захватывает поток видео с wifi роутера.

Недостатки:

Необходимо изменить плейлист для используемого мультимедиа плеера.

Правки, которые необходимо внести в VLC плей-листом при использовании функции «IPTV UDP Multicast to HTTP Proxy»:

Откройте плей-лист в текстовом редакторе.
Найдите строки вида — udp://@239.23.0.200:1234/ и удалите часть, которую я выделил жирным. Изменять необходимо все.
На место удаленной части udp://@ вставьте — http://192.168.1.1:2323/udp/, где 192.168.1.1 — IP адрес вашего wi-fi роутера, а 2323 – прокси порт, который вы выбрали.
Результатом будет строка — http://192.168.1.1:2323/udp/239.23.0.200:1234/

Использование IPTV приставки:

Активация опцииChoose WAN Bridge Port и выбор одного или несколькихLAN портов роутерадля подключенияIPTVприставки.

Использование для просмотра IPTV ПК (проводное и беспроводное подключение)

Активация опцииEnable multicast routing», которая отключит фильтрацию multicastтрафика и станет активным перенаправление его во внутреннюю подсеть наLANинтерфейсы в случае необходимости. Не забывайте разрешить активность программы для просмотра IPTV в файрволе.

Automatic Multicast Tunnel Gateway [AMT protocol]

Возможность соединять multicast-enabled сеть и ipv4-only сеть (без мультикаст). Позволяет получать мультикаст трафик, там, где не включен мультикаст.

AMT протокол дает возможность искать и устанавливать соседство между relay-роутерами и gateway-роутерами.

Relay-роутеры — обычные мультикаст роутеры (с native-multicast), на которых аггрегируется большое кол-во AMT-туннелей.

Трафик до пользователей в multicast сети идет как multicast. Запросы трафика — multicast join.

Трафик до пользователей в ipv4-only сети получают в виде UDP unicast stream. Запросы делаю в виде UDP IGMP request.

Работает только с PIM-SSM.

Работает только с IPv4.

Multicast

Тип передачи multicast разрабатывался для сбережения пропускной
способности в IP сетях. Такой тип уменьшает трафик, позволяя хостам
отправить один пакет выбранной группе хостов. Для достижения нескольких
хостов назначения используя передачу данных unicast, хосту источнику
было бы необходимо отправить каждому хосту назначения один и тот же
пакет. С типом передачи данных multicast, хост источник может отправить
всего один пакет, который может достичь тысячи хостов получателей.

Примеры multicast передачи данных:

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

Multicast клиенты

Хосты, которые хотят получить определенные multicast данные, называются
multicast клиентами. Multicast клиенты используют сервисы инициированные
(начатые) клиентскими программами для рассылки multicast данных
группам.

Каждая multicast группа представляет собой один multicast IP адрес
назначения. Когда хост рассылает данные для multicast группы, хост
помещает multicast IP адрес в заголовок пакета (в раздел пункта
назначения).

Для multicast групп выделен специальный блок IP адресов, от 224.0.0.0 до 239.255.255.255.

IGMP Snooping

Идея очень простая — коммутатор «слушает» проходящие через него IGMP-пакеты.

Для каждой группы отдельно он ведёт таблицу восходящих и нисходящих портов.

Если с порта пришёл IGMP Report для группы, значит там клиент, коммутатор добавляет его в список нисходящих для этой группы.

Если с порта пришёл IGMP Query для группы, значит там маршрутизатор, коммутатор добавляет его в список восходящих.

Таким образом формируется таблица передачи мультикастового трафика на канальном уровне.

В итоге, когда сверху приходит мультикастовый поток, он копируется только в нисходящие интерфейсы. Если на 16-портовом коммутаторе только два клиента, только им и будет доставлен трафик.

IGMP Snooping

Гениальность этой идеи заканчивается тогда, когда мы задумываемся о её природе. Механизм предполагает, что коммутатор должен прослушивать трафик на 3-м уровне.

Впрочем, IGMP Snooping ни в какое сравнение не идёт с NAT по степени игнорирования принципов сетевого взаимодействия. Тем более, кроме экономии в ресурсах, он несёт в себе массу менее очевидных возможностей. Да и в общем-то в современном мире, коммутатор, который умеет заглядывать внутрь IP — явление не исключительное.

Задача № 3

Сервер 172.16.0.5 передает мультикаст трафик на группы 239.1.1.1, 239.2.2.2 и 239.0.0.x.

Настроить сеть таким образом, чтобы:

клиент 1 не мог присоединиться к группе 239.2.2.2. Но при этом мог присоединиться к группе 239.0.0.x.
клиент 2 не мог присоединиться к группе 239.1.1.1. Но при этом мог присоединиться к группе 239.0.0.x.

Это конец? WiFi и IP-телевидение в multicast-потоке не совместимы?

Для корректной работы UDP Proxy необходимо отключить IGMP Proxy. Одновременная работа двух этих функций невозможна!Для этого проделываем следующее:

Заходим в раздел Домашняя Сеть, выбираем вкладку IGMP Proxy. Снимаем галочку в строке Включить функцию IGMP Proxy. Нажимаем кнопку Применить.
Заходим в раздел Приложения и выбираем вкладку Сервер udpxy. В открывшемся окне отмечаем галочкой пункт Включить, нажимаем на кнопку Применить.

В случае использования настроек по умолчанию, udpxy-сервер будет работать в локальной сети по порту 4022, т.е. все клиенты должны обращаться по этому номеру TCP-порта.

IGMP

Internet group management protocol

IGMP не протокол маршрутизации. Работает между получателями и роутером, с которого отдается мультикаст в сегменте. Он просто передает информацию роутеру о заинтересованных получателях и получателях, которые хотят покинуть группу.

Для IPv6 используется точно такой же по принципу работы протокол MLD.

Сообщения

Report/Join message: отправляет хост, когда хочет подписаться на какую-то группу. DA = group address. После того как хост подписался на группу, он должен отвечать на query message от роутера. TTL = 1, т.к. сообщение должно долететь только до ближайшего маршрутизатора.

General query: роутер шлет general query на 224.0.0.1 всем хотсам (роутер при этом называется query-router (опрашивающий)). Хосты в ответ присылают группы, на которые они еще хотят быть подписаны. TTL тоже = 1.

Чтобы не дублировались ответы с одной группой от разных хостов, хосты шлют ответы с разным временным интервалом. Если хост видит, что о его группе сообщил другой хост, то он не будет отправлять ответ роутеру. Роутер итак сохранит интерфейс как downstream для данной группы.

Если в домене несколько query-роутеров, то в качестве активного будет выбран с наименьшим ip.

Leave message:

IGMP2: Хост отправляет leave message для конкретной группы на общий адрес 224.0.0.2.
IGMP1: Хост просто перестает отвечать на query от роутра. Если больше нет подписчиков на группу, роутер по истечению какого-то интервала перестает слать трафик в интерфейс.

Group-specific query:

IGMP2: Когда роутер получил leave от хоста, он отправляет general-specific query на адрес этой группы, чтобы понять есть ли еще заинтересованные получатели.

Разные версии протокола

IGMP v 1

Чтобы получить трафик от конкретной группы, хост отправляет роутеру report message.
Для отключения от группы хост просто перестает отвечать роутеру на query.
Таймаут, после которого роутер перестает вещать группу в downstream interface = 260.

(robustness count * igmp_query interval) + (1*IGMP response interval) = (2*125)+(1*10) = 260

IGMP v 2

Чтобы подписаться, хосты шлют report-message.
Чтобы отписаться, хосты шлют leave-group message.
Чтобы проверить наличие подписчиков, роутер шлет group-specific message.
Таймаут, после которого роутер перестает вещать: нет ответа от хостов в течение 2 сек (дефолт).

robusness count * IGMP last member query interval = 2*1 = 2

IGMP v 3

Все улучшения для v 2. .

Используется для SSM, поэтому report message (на адрес 224.0.0.22 — all IGMPv3) может содержать source information.

L2 switches

Свитчи обрабатывают мультикаст трафик как бродкаст, по умолчанию, т.е. шлет трафик во все порты.

IGMP-snooping позволяет выделить мультикаст трафик. С помощью IGMP сообщений, свитч может понять где получатели и слать трафик только к ним.
Делит порты на multicast-router interface (откуда приходят query, либо заданы статически), host-side interface (все остальные).

Передача трафика:

Весь трафик направлен в multicast-router интерфейс.
Если через IGMP-snooping свитч узнает о портах, за которыми сидят получатели, то шлет трафик туда.
224/8 сеть бродкастом идет во все порты, кроме входящего.

Стандартное расширение IGMP позволяет только обрабатывать query от роутера и сообщения от получателей. Не генерирует IGMP сообщения.

IGMP snooping proxy ведет себя как роутер для получателей (генерирует query), работает как получатели для роутера (генерирует leave и join сообщения).

Тем самым уменьшается кол-во report-сообщений для роутера.

Пример II

IGMP

IGMP — Internet Group Management Protocol1.IGMP Membership Report2.(*, 224.2.2.4)(172.16.0.5, 224.2.2.4)OIL — Outbound Interface Listshow ip mroute3.IGMP Query*Дамп отфильтрован по IGMP*General Query*Дамп отфильтрован по IGMP*4.IGMP LeaveGroup Specific Queryтолько*Дамп отфильтрован по IGMP*

И ещё раз

IGMPIGMP ReportIGMP General QueryIGMP Group Sepcific QueryIGMP LeaveQuerier

PIM

PIM — Protocol Independent MulticastCBT version 2 is not, and was not, intended to be backwards compatible with version 1; we do not expect this to cause extensive compatibility problems because we do not believe CBT is at all widely deployed at this stage.

PIM Dense Mode (DM)
PIM Sparse Mode (SM)

Dahua

Включение мультикаст выполняется командами CGI. Для включения мультикаст TS введите в браузере, чтобы включить многоадресную передачу RTP

и RTP по веб-адресу
http ://ip/cgi-bin/configManager.cgi? action = setConfig & Multicast.RTP .Enable = true IP-адрес моего IPC 10,25,2,237, поэтому эта рекомендация должна быть http ://10.15.2.237/cgi-bin/configManager.cgi? action = setConfig & Multicast.RTP .Enable = true WEB-страница позволяет ввести имя входа и пароль, а затем нажмите OK.

Многоадресная передача RTP: введите в командной строке, чтобы включить многоадресную передачу RTP и RTP на веб-адресе shttp ://ip/cgi-bin/configManager.cgi? action = setConfig & Multicast.RTP .Enable = truemy IP-адрес IPC равен 10.25.2.237.

Проверьте использование многоадресной информации: http ://ip/cgi-bin/configManager.cgi? action = getConfig & name = Multicast. Порт по умолчанию для RTP — 40000, а для RTP — 40001, порт RTP по умолчанию — 554

Вы может проверить порт RTP на веб-странице:

После ввода комментария можно увидеть следующее состояние RTP, оба параметра enable имеют значение true.

Обратите внимание, что для многоадресной передачи RTP должны быть включены RTP и , а порт RTSP должен быть четным.

Закройте брандмауэр, закройте все антивирусы, откройте VLC и найдите сетевой Steam.

Входной комментарий: rtsp ://10.15.2.237: 554/cam/realmonitor? channel = 1 & subtype = 0 & unicast = false

Введите play и теперь вы получите многоадресное видео.

Многоадресная передача UDP:

Изменение UDP совпадает с RTP

Введите http ://ip/cgi-bin/configManager.cgi? action = setConfig & Multicast.TS .Enable = true, чтобы включить протокол служб терминалов.

Inout http ://ip/cgi-bin/configManager.cgi? action = setConfig & Multicast.TS .MulticastAddr = ip to modity адрес многоадресной рассылки UDP

Адрес UDP по умолчанию — 224.1.2.3, диапазон изменения — 224.X.X.X.to 239.X.X.X

В VLC введите udp ://@ 224.1.2.3: 20000 (при наличии только 1 IPC в сети, однако при подключении нескольких IPC в локальной сети следует изменить адрес по умолчанию на другой).

OMNY PRO

Включение мультикаст выполняется в WEB интерфейсе.

Заходим Configuration—Advance Set—Access Platform—PU SetRegister Server> вводим адреса между 224—239 сегментом, например, 224.168.1.100, указываем порт 10102.

Сохраняем, устройство перезагружается. Открываем VLC плеер для проверки (Media /открыть URL/сеть) и вводим строку запроса udp://@224.168.1.100:10102 (соответствующий адрес и порт).

Новые модели имеют другое расположение настроек мультикаст:

Configuration>>network management>>Network Service>>MUC

OMNY Base

Включение мультикаст выполняется в WEB интерфейсе. Путь Settings/Network/RTSP — Multicast Settings / Enable Multicast, затем вводим адреса между 224—239 сегментом, например, 224.1.2.3, указываем порт 10000 и сохраняем.

Открываем VLC плеер для проверки (Медиа/открыть URL/сеть) и вводим строку запроса как RTSP.

tsp://172.16.18.124:554/live/main

Убедитесь, что в настройках вашего VLC плеера нет флажка RTP поверх RTSP (TCP).

Вот, пожалуй, и все. Мы же напоминаем, что наша компания «Запишем всё» с 2010 года занимается проектированием, монтажом, обслуживанием и ремонтом систем видеонаблюдения и видеодомофонов в Москве и Подмосковье.

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

Звоните +7 (499) 390-28-45 с 8-00 до 22-00 в любой день недели, в том числе и в выходные. Мы будем рады Вам помочь!

BIDIR PIM

Many-to-ManyПонятное дело, что инертный PIM SSM здесь совсем не подходит?Bidirectional PIM, BIDIR PIMИсточник1Источником2Источник1Источник2каждыйПолучательDF — Designated Forwarder

Если запрос PIM Join/Leave приходит на тот интерфейс, который в данном сегменте является DF, он передаётся в сторону RP по стандартным правилам.
Вот, например, R3. Если запросы пришли в DF интерфейсы, что помечены красным кругом, он их передаёт на RP (через R1 или R2, в зависимости от таблицы маршрутизации).

Если запрос PIM Join/Leave пришёл на не DF интерфейс, он будет проигнорирован.
Допустим, что клиент, находящийся между R1 и R3, решил подключиться и отправил IGMP Report. R1 получает его через интерфейс, где он выбран DF (помечен красным кругом), и мы возвращаемся к предыдущему сценарию. А R3 получает запрос на интерфейс, который не является DF. R3 видит, что тут он не лучший, и игнорирует запрос.

Если мультикастовый трафик пришёл на DF интерфейс, он будет отправлен в интерфейсы из списка OIL и в сторону RP.
Например, Источник1 начал передавать трафик

R4 получает его в свой DF интерфейс и передаёт его и в другой DF-интерфейс — в сторону клиента и в сторону RP, — это важно, потому что трафик должен попасть на RP и распространиться по всем получателям. Также поступает и R3 — одна копия в интерфейсы из списка OIL — то есть на R5, где он будет отброшен из-за проверки RPF, и другая — в сторону RP

Если мультикастовый трафик пришёл на не DF интерфейс, он должен быть отправлен в интерфейсы из списка OIL, но не будет отправлен в сторону RP.
К примеру, Источник2 начал вещать, трафик дошёл до RP и начал распространяться вниз по RPT. R3 получает трафик от R1, и он не передаст его на R2 — только вниз на R4 и на R5.

Broadcast (Широковещание)

Из-за того, что тип передачи broadcast используется для отправки пакетов
ко всем хостам в сети, пакеты использую специальный broadcast IP адрес.
Когда хост получает пакет, в заголовке которого в качестве адреса
получателя указан broadcast адрес, он обрабатывает пакет так, как будто
это unicast пакет.

Когда хосту необходимо передать какую-то информацию всем хостам в сети
используется способ передачи данных broadcast. Еще когда адрес
специальных сервисов (служб) или устройств заранее неизвестен, то для
обнаружения также используется broadcast (широковещание).

Примеры, когда используется broadcast передача данных:

создание карты принадлежности адресов верхнего уровня к нижним
(например, какой IP адрес на конкретном устройстве со своим MAC адресом)
запрос адреса (в качестве примера можно взять протокол ARP)
протоколы маршрутизации обмениваются информацией о маршрутах (RIP, EIGRP, OSPF)

Когда хосту нужна информация, он отправляет запрос на широковещательный
адрес. Все остальные хосты в сети получат и обработают этот запрос. Один
или несколько хостов вложат запрашиваемую информацию и ответят на
запрос. В качестве типа передачи данных, отвечающие на запрос будут
использовать unicast.

Подобным образом, когда хосту необходимо отправить информацию всем
хостам в сети, он создаёт широковещательный пакет с его информацией и
передаёт его в сеть.

В отличие от unicast передачи, где пакеты могут быть маршрутизированы
через всю сеть, broadcast пакеты, как правило, ограничиваются локальной
сетью. Это ограничение зависит от настройки маршрутизатора, который
ограничивает сеть и следит за типом широковещания (broadcast).

Существует два типа broadcast передачи данных: направленное широковещание и ограниченное широковещание.

Направленный broadcast (направленное широковещание)

Направленный broadcast отправляется всем хостам какой-то конкретной
сети. Этот тип широковещания удобно использовать для отправки broadcast
трафика всем хостам за пределами локальной сети.

Например, хост хочет отправить пакет всем хостам в сети 172.16.5.0/24,
но сам хост находится в другой сети. В данном случае хост-отправитель
вложит в заголовок пакета в качестве адреса пункта назначения broadcast
адрес 172.16.5.255. Хотя маршрутизаторы должны ограничивать (не
передавать) направленный широковещательный трафик, их можно настроить на
разрешение передачи broadcast трафика.

Ограниченный broadcast (ограниченное широковещание)

Ограниченный broadcast используется для передачи данных всем хостам в
локальной сети. В такие пакеты в качестве пункта назначения вставляется
IP адрес 255.255.255.255. Маршрутизаторы такой широковещательный трафик
не передают. Пакеты, переданные ограниченным broadcast будут
распространяться только в локальной сети. По этой причине локальные сети
IP также называют широковещательным доменом (broadcast domain).
Маршрутизаторы образуют границу для широковещательного домена. Без
границы пакеты бы распространялись по всей сети, каждому хосту, уменьшая
быстродействие сетевых устройств и забивая пропускную способность
каналов связи.

Приведу пример ограниченного broadcast: хост находится внутри сети
172.16.5.0/24 и хочет передать пакет всем хостам в его сети. Используя в
качестве пункта назначения IP адрес 255.255.255.255, он отправляет
широковещательный пакет. Этот пакет примут и обработают все хосты только
в этой локальной сети (172.16.5.0/24).

IGMP Snooping Proxy

У пытливого читателя может возникнуть вопрос по тому, как IGMP Snooping узнаёт все клиентские порты, учитывая, что на IGMP Query отвечает только один самый быстрый клиент, как мы говорили выше. А очень просто: IGMP Snooping не позволяет сообщениям Report ходить между клиентами. Они отправляются только в восходящие порты к маршрутизаторам. Не видя Report от других получателей этой группы, клиент обязан ответить на Query в течение Max Response Time, указанном в этом Query.

В итоге в сети на 1000 узлов на один IGMP Query в течение секунд 10 (обычное значение Max Response Time) придёт 1000 Report’ов маршрутизатору. Хотя ему достаточно было бы и одного для каждой группы.

И происходит это каждую минуту.

В этом случае можно настроить проксирование IGMP-запросов. Тогда коммутатор не просто «слушает» проходящие пакеты, он их перехватывает.

Правила работы IGMP Snooping могут отличаться для разных производителей. Поэтому рассмотрим их концептуально:

Если на коммутатор приходит самый первый запрос Report на группу, он отправляется вверх к маршрутизатору, а интерфейс вносится в список нисходящих. Если же такая группа уже есть, интерфейс просто добавляется в список нисходящих, а Report уничтожается.
Если на коммутатор приходит самый последний Leave, то есть других клиентов нет, этот Leave будет отправлен на маршрутизатор, а интерфейс удаляется из списка нисходящих. В противном случае просто удаляется интерфейс, Leave уничтожается.
Если IGMP Query приходит от маршрутизатора, коммутатор перехватывает его, отправляет в ответ IGMP Report для всех групп, которые в данный момент имеют получателей.
А дальше, в зависимости от настроек и производителя, либо этот же самый Query рассылается во все клиентские порты, либо коммутатор блокирует запрос от маршрутизатора и сам выступает в роли Querier, периодически опрашивая всех получателей.

Таким образом снижается и доля лишнего служебного трафика в сети и нагрузка на маршрутизатор.

Рис. 1. Настройка сети с многоадресным источником и получателями

Многоадресный источник подключается к коммутатору 1, который является коммутатором Catalyst 6500 с модулем управления Supervisor Engine 720 с ПО Cisco IOS. Так же надо помнить, что Вам, компания Ветрикс http://vetriks.ru , которая оказывает услуги аутсорсинга информационных технологий сама решает такие проблемы. Получатель 1 подключается к коммутатору 1, а получатель 2 подключается к коммутатору 2. Коммутатор 2 – это коммутатор Catalyst 3750. Между коммутатором 1 и коммутатором 2 существует соединение уровня 2, доступ или магистраль.

В данной настройке можно заметить, что получатель 1, который находится на одном коммутаторе с источником, получает многоадресный поток без затруднений. Однако получатель 2 не получает многоадресного трафика. Цель данного документа – устранить данную проблему.

Multicast forwarding

unicast forwarding основан на dest ip.
multicast forwarding основан на source ip.

Предотвращение петель:

RPF-check для источника: сравнивается с какого интерфейса фактически пришел мультикаст пакет с тем, откуда по unicast table пакет должен приходить (источник или RP). Если сходится — RPF done, не сходится — RPF fail. Префиксы, прошедшие RPF-check хранятся в inet.1.
Multicast трафик никогда не форвардится в сторону источника.

show multicast rpf <group ip>

Routing tables

inet.0 — дефолтная таблица для проведения RPF-check . Если unicast и multicast топологии одинаковые, то inet.0 и inet.2 будут одинаковы.

inet.1 — записываются результаты RPF-check, форвардинг производится на основании этой таблицы.

>show route table inet.1  
inet.1: 238 destinations, 238 routes (238 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
224.0.0.0/4        *[Multicast/180] 74w2d 13:10:11
                      MultiResolve
224.0.0.0/24       *[Multicast/180] 74w2d 13:10:11
                     MultiDiscard
232.0.0.0/8        *[Multicast/180] 74w2d 13:10:11
                     MultiResolve
232.192.1.1,10.200.86.1/32*[PIM/105] 6w0d 08:32:53
                     Multicast (IPv4) Composite
232.192.1.1,10.200.86.2/32*[PIM/105] 8w3d 15:25:48
                     Multicast (IPv4) Composite
232.192.1.2,10.200.86.1/32*[PIM/105] 6w0d 08:32:52
                      Multicast (IPv4) Composite
232.192.1.2,10.200.86.2/32*[PIM/105] 8w3d 15:25:52
                     Multicast (IPv4) Composite
232.192.1.4,10.200.86.1/32*[PIM/105] 23:11:56
                     Multicast (IPv4) Composite
...

Detailed

232.192.1.1.10.200.86.1/64 (1 entry, 1 announced)
       *PIM    Preference: 105         
               Next hop type: Multicast (IPv4) Composite, Next hop index: 1048796
               Address: 0xa4edf30
               Next-hop reference count: 28
               State: <Active Int Ext AckRequest>
               Local AS: 100 
               Age: 6w0d 8:35:30 
               Validation State: unverified 
               Task: PIM.master
               Announcement bits (1): 0-KRT 
               AS path: I
               AS path: Recorded

inet.2 — если для multicast на сети должна быть использована другая топология, то используем эту таблицу. inet.2 в таком случае будет использоваться для RPF-check.

MP-BGP и multitopology IS-IS могут напрямую заполнять маршрутной информацией inet.2.

Чтобы ISIS стал заполнять inet.2 — нужно включить

set protocols isis topologies ipv4-multicast

Все остальные протоколы для заполнения таблицы должны заниматься копированием в inet.2 маршрутов с помощью RIB-groups.

IMPORT-RIB: для протокола PIM import-rib копирует маршруты из протокола в указанную таблицу. То есть указываем только одну таблицу. Указанная таблица будет использоваться для RPF.

Для остальных протоколов первая таблица <> — откуда копируются маршруты, вторая <to-inet2> — куда копируются.

set routing-options rib-groups mcast-table import-rib inet.2
set protocols pim rib-group inet mcast-table

set routing-options rib-groups import-rib to-inet2 
set routing-options rib-groups import-policy static *по желанию/необходимости
set protocols ospf rib-groups to-inet.2
set routing-options interface-routes rib-group inet to-inet2

В обычном понимании: если задаём export-ribs, то при этом указывается только одна таблица, куда будут скопированы маршруты. Но для PIM не работает export-ribs.