multicast по wifi что это
Приручаем multicast
Остановимся на анализе мультикаст-трафика через IGMP-протокол. Рассмотрим реализацию работы протокола IGMP, работы протокола PIM, отправки JOIN-запросов. После анализа проблемы была разработана оптимальная конфигурация сетевого оборудования, эффективная настройка QOS. Данная задача появилась после обнаружения проблемы в сети, такой как прерывание сигнала у клиентов, наличие фризов и прерывание звука.
IGMP — Internet Group Management Protocol — это сетевой протокол взаимодействия абонентов мультикаст-трафика и ближайшего к ним сетевого оборудования.
Пользователь имеет подписку на следующую группу IP-адресов: 224.0.0.0 до 239.255.255.255. PIM Protocol реализован в режиме Sparse mode. Это означает, что трафик льется только на ту ветку, в которой есть клиенты, желающие войти в мультикаст-группу. Они отправляют сообщения PIM Join. Если клиенты не отправляют Join, то трафик им отправляться не будет. PIM Sparse Mode включен на двух интерфейсах. В сторону источника мультикаст-трафика и в сторону клиента. На стороне клиента имеет цифровой ресивер или абонентское устройство —IPTV-приставка.
Для справки: dense mode предполагает, что мультикаст-трафик идет до абонента, и неважно, подписывается ли он на определенный канал. Мультикаст идет во все порты, потом, если он не нужен по месту назначения, то отправляется служебный пакет PIM Prune, и трафик перестает идти по этой ветке.
IGMP-протокол реализуется в сторону клиента. PIM-протокол устанавливает соседство с другими маршрутизаторами. Для этого применяются служебные сообщения PIM Hello.
В нашей сети применялась вторая версия протокола IGMP.
Абонентское устройство, которое решает получить multicast-трафик, отправляет запрос в сообщении IGMP Membership Report (так называемый репорт).
Если абонентское устройство больше не желает получать мультикаст-трафик, то оно отправляет сообщение IGMP Leave. Эта функция реализована коммутаторах уровня доступа. IGMP Membership Group-Specific Query — повторное сообщение коммутатором в сеть о том, есть ли клиентские устройства, которые будут запрашивать мультикаст-трафик. Если их нет, то передача трафика прекращается.
IGMP snooping реализуется на сетевом оборудовании, отдельного включения функции недостаточно, необходима дополнительная настройка. После включения данной функции управляемые коммутаторы могут анализировать трафик — мультикаст-поток.
Если коммутатор обнаруживает IGMP-пакет, то он вносит порт в список мультикаст-групп. Если от абонента идет сообщение IGMP Leave, то коммутатор удаляет порт из подписчиков групп.
IGMP snooping позволяет предотвращать мультикаст шторм. Если функция IGMP snooping не включена, то оборудование ретранслирует multicast-трафик во все порты, которые находятся в одном VLAN. Это не эффективно, а также способно вызвать проблемы на сетевых устройствах, вынужденных обрабатывать высокий поток данных. Это может загружать CPU-оборудования. IGMP snooping улучшает работу сети.
Однако для того, чтобы получить мультикаст-трафик, нужно реализовать эту функции на стороне клиента. К примеру, если клиент подключен через роутер, то необходимо позаботиться о включении этой функции на роутере.
Проверить корректность работы мультикаст-вещания можно путем анализа трафика через Wireshark, после включения телевидения через VLC-медиаплеер. В настройках VLC указываем, к примеру, udp:@239.255.0.A:5500. Для передачи потока используется UDP протокол, далее идет мультикаст адрес, далее порт.
При разработке QOS учитывалось, что «красить» трафик желательно ближе к ядру сети. Его необходимо красить ближе к Randezvous Point. (Ну это для нашего случая)
На коммутаторах уровня доступа у нас применялись следующие настройки:
Глубокий анализ проблемы, применение средств диагностики и понимание работы протокола IGMP позволяет выработать эффективную и оптимальную конфигурацию мультикаст-трафика в вашей сети.
Multicast по wifi что это
Многие интернет-провайдеры предоставляют услугу IPTV. А наши пользователи часто задают нам вопрос – как настроить IPTV телевидение для роутеров D-Link DIR или как включить в Wi-Fi маршрутизаторе D-Link DIR функцию мультикаст, благодаря которой вы сможете смотреть IPTV на своем домашнем компьютере.
Настроить IPTV для роутеров D-Link DIR с Windows 8, Windows 7, Windows XP и других операционных систем, очень просто. Достаточно выполнить несколько простых шагов, которые позволят вам настроить интернет телевидение.
Настройки, которые указаны в этой статье, подойдут для следующих интернет провайдеров:
Итак, в этой статье мы расскажем, как настроить IPTV телевидение для роутеров D-Link DIR.
Чтобы включить функцию multicast (ФйПиТиВи) в вашем роутере, необходимо через web-интерфейс роутера (ввести в окне браузера 192.168.0.1), зайти в меню: Home (Главная)> Wan и выбрать «IGMP Enabled». После чего следует нажать на кнопку/ссылку «Apply».
Затем, следует зайти в Advanced(Расширенные)> AdvancedNetwork (Дополнительные настройки) и нажать«EnableMulticastStream».
Затем нажмите на кнопку «Save Settings» (Сохранить настройки).
Вот и все, теперь вы знаете, как включить в Wi-Fi маршрутизаторе D-Link DIR функцию мультикаст и сможете наслаждаться просмотром телевизионных программ используя функцию IPTV. Приятного просмотра.
Мультикаст-рассылка — технология, позволяющая передавать одинаковый трафик группе хостов, тем самымм экономя пропускную способность канала. Например, в IPTv есть 3 потока для 100 хостов — канал СТС, ТНТ и МузТВ. Без мультикаст пришлось бы передавать каждому получателю отдельный поток трафика, что загрузило бы канал. С мультикаст мы передаем по одному уникальному потоку, в данном случае 3 потока.
Делиться на L3 Routing и L2 Multicast. На L3 работают PIM и ряд других (MOSPF, DVMRP…). На L2 работает IGMP.
PIM работает между маршрутизаторами.
Каждому каналу присваивается свой IP из диапазона Multicast-адресов 224.0.0.0/4. Когда один их хостов запускает ПО для просмотра каналов, то это ПО начинает прослушивать какой-то из этих IP-адресов, например 239.1.1.10. Другие хосты, которые хотят смотреть тот же канал, например, СТС, также начинают прослушивать этот IP. Также данное ПО назначает виртуальный Multicast MAC-адрес на всех этих хостах, который генерируется из данного multicast-адреса. Они всегда начинаются на 01-00-5E-xx-xx-xx.
Когда хост запускает приложение (например, плеер), IGMP формирует сообщение маршрутизатору.
— Membership Query
— Membership Report
— Leave / Join
IGMP Join. Пример: Хост 1 запускает VLC Player и говорит, что он хочет прослушивать мультикаст-трафик, который вещается на 239.1.1.10. Далее на сетевую карточку вешается multicast-макадрес как secondary и высылается сообщение IGMP Join. Высылается оно на адрес группы.
На данный момент маршрутизатор знает, что за интерфейсом е0/0 находится клиенты, которые слушают мультикаст-трафик 239.1.1.10.
Membership Query Маршрутизатор высылает IGMP Query для 239.1.1.10 на 224.0.0.1. «Есть ли кто живой в сети, кто прослушивает этот адрес 239.1.1.10?» Если никто не отвечает, то маршрутизатор прекращает передавать трафик на интерфейс, за которым были клиенты 239.1.1.10.
Если же клиенты ответили есть, то они отвечают на query сообщением IGMP Report. Хосты не отвечают на Query одновременно, а делают это по истечении таймера, который разный на всех хостах. Если маршрутизатор получил хоть один Report, то он продолжает отсылать трафик. Остальные хосты не отсылают Report в таком случае, потому как незачем это делать. Они просто сбрасывают свои таймеры.
Настройка IPTV через роутер | IPTV по Wi-Fi и проводное подключение
Выход хоста из группы Предположим, что на одном их хостов закрывают VLC Player, данный хост генерирует IGMP Leave и отсылает его на 224.0.0.1.
Получая такое сообщение, маршрутизатор высылает внутрь сети Query 239.1.1.10 чтобы узнать, есть ли активные клиенты. На хостах, которые получили этот Query, и какой-то хостс наименьшим таймером вышлет Report.
Есть аналоги IGMP — CGMP (Cisco Group Management Protocol) и RGMP (Router-port Group Management Protocol)
Если маршрутизатор не один, а несколько, то обработкой IGMP будет заниматься тот, у кого наименьший IP.
R7# ip multicast-routing //включаем глобальную поддержку Multicast R7# int e0/1.79 R7# ip pim dense-mode //включаем PIM на интерфейсе в сторону хостов
Просмотр таблицы Multicast — show ip mroute
ip igmp access-group позволяет ограничивать с помощью access-list группы, к которым возможно подключаться.
Format ЗаметкаAuthor rootCategories IGMP, Multicast, PIM
Проблема
Многоадресный трафик не проходит через коммутаторы Catalyst, даже внутри одной VLAN. На Рис.1 изображен типичный сценарий:
Рис. 1. Настройка сети с многоадресным источником и получателями
В данной настройке можно заметить, что получатель 1, который находится на одном коммутаторе с источником, получает многоадресный поток без затруднений. Однако получатель 2 не получает многоадресного трафика. Цель данного документа – устранить данную проблему.
Повторный обзор некоторый ключевых принципов многоадресной рассылки
До получения различных вариантов решения данной проблемы, вы должны четко представлять себе определенные принципы многоадресной рассылки уровня 2.
Настройка IP-TV на роутерах
В данном разделе описаны эти принципы.
Примечание. Если вы не хотите заниматься этим самостоятельно, передайте компьютерную сеть на ИТ аутсорсинг В данном разделе приведено простое и четкое объяснение, касающееся данной конкретной проблемы. Подробное объяснение этих терминов см. в разделе Дополнительные сведения данного документа.
Протокол IGMP
IGMP – это протокол, который обязывает конечные хосты (получатели) сообщить многоадресному маршрутизатору (опросчику IGMP) о намерении конечного хоста получать определенный многоадресный трафик. То есть, это протокол, использующийся между маршрутизатором и конечными хостами и позволяющий:
Маршрутизаторам запрашивать конечные хосты о потребности в определенном многоадресном потоке (запрос IGMP)
Конечным хостам сообщать и отвечать маршрутизатору о потребности в определенном многоадресном потоке (отчеты IGMP)
Функция отслеживания IGMP
Функция отслеживания IGMP – это механизм посылки многоадресного трафика только на те порты, к которым подключены получатели. Данный механизм увеличивает эффективность, так как он позволяет коммутатору уровня 2 избирательно рассылать многоадресные пакеты только на те порты, которые в них нуждаются. Без функции отслеживания IGMP маршрутизатор отправляет пакеты на каждый порт. Коммутатор следит за обменом сообщениями IGMP между маршрутизатором и конечными хостами. В данном случае коммутатор создает таблицу отслеживания IGMP, в которой присутствует список всех портов, которые запросили определенную группу многоадресной передачи.
Порт Mrouter
Порт mrouter – это порт с точки зрения коммутатора, который подключается к многоадресному маршрутизатору. Необходимо присутствие, по крайней мере, одного порта mrouter для работы коммутаторов по отслеживанию IGMP. Это требование подробно описано в разделе Общие сведения о проблеме и ее решения данного документа.
Многоадресная рассылка на L2
Любой IP-трафик версии 4 (IPv4) с IP-адресом назначения в диапазоне от 224.0.0.0 до 239.255.255.255 является многоадресным потоком. Все многоадресные пакеты IPv4 соответствуют предварительно определенному MAC-адресу IEEE с форматом 01.00.5e.xx.xx.xx.
Примечание. Функция отслеживания IGMP действует в случае, если MAC-адреса многоадресной рассылки соответствуют IEEE-совместимому MAC-диапазону. Согласно разработке данной функции, отслеживание некоторых зарезервированных диапазонов многоадресной рассылки не предполагается. Если не соответствующий критериям многоадресный пакет исходит из коммутируемой сети, он отправляется через эту VLAN, где расценивается как широковещательный трафик.
Wireless Multicast Forwarding — настройка WMF на ASUS
В тех случаях, когда необходимо подключить ТВ-приставку IPTV через беспроводную сеть WiFi и нет возможности настроить функцию udpxy — на помощью пользователям приходит функция Wireless Multicast Forwarding или сокращенно WMF.
Как включить функцию мультикаст в маршрутизаторах tp link
Смысл работы этой функции в том, что настройка multicast делается таким образом, что ТВ-поток транслируется по Wi-Fi с подменой аппаратного MAC-адреса на канальном уровне сети.
В беспроводных роутерах ASUS так же есть возможность настроить Wireless Multicast Forwarding на маршрутизаторе.
Для этого надо зайти в веб-интерфейс маршрутизатора. Затем, в главном меню выбираем раздел Беспроводная сеть, закладка Профессионально:
Прокручиваем страничку практически в самый конец и находим искомую строчку «Wireless Multicast Forwarding» — в выпадающем списке значений параметра выбираем вариант Включить. Сохраняем настройки роутера ASUS и проверяем работу IPTV по беспроводной сети Вай-Фай.
Замечание: Если у Вас для работы цифрового интерактивного телевидения надо выделять отдельный LAN-порт или поток мультикаст подаётся на роутер в тегированном виде и надо дополнительно указывать VLAN ID — этот способ не подойдёт и для работы ТВ по Wi-Fi придётся покупать отдельное устройство — беспроводной мост.
Инструкции и советы:
Полезная информация:
Other versions:
Настройка IPTV на ASUS RT-N12, RT-N11P и RT-N10
  Asus | Билайн | Ростелеком
На сегодняшний день многие пользователи используют не только домашний Интернет от своего провайдера, но и телевидение IPTV.
Как настроить мультикаст
Эта инструкция предназначена для тех, кто разобрался с настройкой Wi-Fi роутера ASUS RT-N12, RT-N11P или RT-N10, но пока не настроил работу ТВ (впрочем, для других моделей маршрутизаторов ASUS путь будет тем же).
Перед настройкой подключите ТВ приставку к одному из разъемов LAN на тыльной стороне вашего роутера, после чего выполните следующие простые шаги.
Примечание: для некоторых популярных провайдеров, в частности для Ростелеком и Билайн для работы телевидения IPTV также может потребоваться включить опции:
Сделать это можно на той же странице настроек Wi-Fi роутера ASUS.
Возможно, вам также пригодятся полные инструкции:
Возможные проблемы при настройке Wi-Fi роутера
Udpxy — серверное приложение для передачи данных из сетевого потока мультикаст канала (вещаемого по UDP) в HTTP-соединение запрашивающего клиента.
Основная задача udpxy заключается в передаче данных, считанных из мультикаст-канала (рассылающего данные подписчикам по протоколу UDP), в клиентское соединение, работающее в протоколе TCP. Таким образом, клиент, не имея возможности работать с протоколом UDP, может послать запрос udpxy, установить TCP соединение и работать с данными, полученными из указанного (в изначальном запросе) мультикаст-канала. Такая возможность востребована при просмотре IPTV на мобильных устройствах, телевизорах с функциональностью SmartTV и игровых консолях.
Функция Udp Proxy на роутерах Keenetic II реализована в качестве отдельного компонента микропрограммы. Для установки данного компонента необходимо:
Обратите внимание!
Это конец? WiFi и IP-телевидение в multicast-потоке не совместимы?
Для корректной работы UDP Proxy необходимо отключить IGMP Proxy. Одновременная работа двух этих функций невозможна!Для этого проделываем следующее:
В случае использования настроек по умолчанию, udpxy-сервер будет работать в локальной сети по порту 4022, т.е. все клиенты должны обращаться по этому номеру TCP-порта.
Сети для самых маленьких. Часть 9.1. Мультикаст. Общее понимание Multicast
Наш умозрительный провайдер linkmeup взрослеет и обрастает по-тихоньку всеми услугами обычных операторов связи. Теперь мы доросли до IPTV.
Отсюда вытекает необходимость настройки мультикастовой маршрутизации и в первую очередь понимание того, что вообще такое мультикаст.
Это первое отклонение от привычных нам принципов работы IP-сетей. Всё-таки парадигма многоадресной рассылки в корне отличается от тёплого лампового юникаста.
Можно даже сказать, это в некоторой степени бросает вызов гибкости вашего разума в понимании новых подходов.
В этой серии статей сосредоточимся на следующем:
Содержание серии статей про мультикаст
На заре моего становления, как инженера, тема мультикаста меня неимоверно пугала, и я связываю это с психотравмой моего первого опыта с ним.
«Так, Марат, срочно, до полудня нужно пробросить видеопоток до нашего нового здания в центре города — провайдер отдаст его нам тут на втором этаже» — услышал я одним чудесным утром. Всё, что я тогда знал о мультикасте, так это то, что отправитель один, получателей много, ну и, кажется, протокол IGMP там как-то задействован.
В итоге до полудня мы пытались всё это дело запустить — я пробросил самый обычный VLAN от точки входа до точки выхода. Но сигнал был нестабильным — картинка замерзала, разваливалась, прерывалась. Я в панике пытался разобраться, что вообще можно сделать с IGMP, тыркался, тыркался, включал мультикаст роутинг, IGMP Snooping, проверял по тысяче раз задержки и потери — ничего не помогало. А потом вдруг всё заработало. Само собой, стабильно, безотказно.
Это послужило мне прививкой против мультикаста, и долгое время я не проявлял к нему никакого интереса.
Уже гораздо позже я пришёл в к следующему правилу:
И теперь с высоты оттраблшученных кейсов я понимаю, что там не могло быть никаких проблем с настройкой сетевой части — глючило конечное оборудование.
Сохраняйте спокойствие и доверьтесь мне. После этой статьи такие вещи вас пугать не будут.
Общее понимание Multicast
Как известно, существуют следующие типы трафика:
Unicast Одноадресная рассылка — один отправитель, один получатель. (пример: запрос HTTP-странички у WEB-сервера). Broadcast Широковещательная рассылка — один отправитель, получатели — все устройства в широковещательном сегменте. (пример: ARP-запрос). Multicast Многоадресная рассылка — один отправитель, много получателей. (пример: IPTV). Anycast Одноадресная рассылка ближайшему узлу — один отправитель, вообще получателей много, но фактически данные отправляются только одному. (пример: Anycast DNS).
Раз уж мы решили поговорить о мультикасте, то, пожалуй, начнём этот параграф с вопроса, где и как он используется.
Первое, что приходит на ум, — это телевидение (IPTV) — один сервер-источник отправляет трафик, который хочет получать сразу много клиентов. Это и определяет сам термин — multicast — многоадресное вещание. То есть, если уже известный вам Broadcast означает вещание всем, мультикаст означает вещание определённой группе.
Второе применение — это, например, репликация операционной системы на множество компьютеров разом. Это подразумевает загрузку больших объёмов данных с одного сервера.
Возможные сценарии: аудио и видеоконференции (один говорит — все слушают), электронная коммерция, аукционы, биржи. Но это в теории, а на практике редко тут всё-таки используется мультикаст.
Ещё одно применение — это служебные сообщения протоколов. Например, OSPF в своём широковещательном домене рассылает свои сообщения на адреса 224.0.0.5 и 224.0.0.6. И обрабатывать их будут только те узлы, на которых запущен OSPF.
Сформулируем два основных принципа мультикастовой рассылки:
В данной статье для практики мы возьмём IPTV, как наиболее наглядный пример.
Пример 1
Начнём с самого простого случая:
На сервере-источнике настроено вещание в группу 224.2.2.4 — это означает, что сервер отправляет трафик на IP-адрес 224.2.2.4. На клиенте видеоплеер настроен принимать поток группы 224.2.2.4.
При этом, заметьте, клиент и сервер не обязательно должны иметь адреса из одной подсети и пинговать друг друга — достаточно, чтобы они были в одном широковещательном домене. Мультикастовый поток просто льётся с сервера, а клиент его просто принимает. Вы можете попробовать это прямо у себя на рабочем месте, соединив патчкордом два компьютера и запустив, например, VLC.
Надо заметить, что в мультикасте нет никакой сигнализации от источника, мол, «Здрасьте, я Источник, не надо немного мультикаста?». Сервер-источник просто начинает вещать в свой интерфейс мультикастовые пакеты. В нашем примере они напрямую попадают клиенту и тот, собственно, сразу же их и принимает.
Если на этом линке отловить пакеты, то вы увидите, что мультикастовый трафик — это ни что иное, как море UDP-пакетов.
Содержимое мультикастового трафика
Мультикаст не привязан к какому-то конкретному протоколу. По сути, всё, что его определяет — адреса. Однако, если говорить о его применении, то в абсолютном большинстве случаев используется именно UDP. Это легко объясняется тем, что обычно с помощью многоадресной рассылки передаются данные, которые нужны здесь и сейчас. Например, видео. Если кусочек кадра потеряется, и отправитель будет пытаться его послать повторно, как это происходит в TCP, то, скорее всего, этот кусочек опоздает, и где его тогда показывать? Поезд ушёл. Ровно то же самое со звуком.
Соответственно не нужно и устанавливать соединение, поэтому TCP здесь ни к чему.
Чем же так разительно отличается мультикаст от юникаста? Думаю, у вас есть уже предположение. И вы, наверняка, правы.
В обычной ситуации у нас 1 получатель и 1 отправитель — у каждого из них один уникальный IP-адрес. Отправитель точно знает, куда надо слать пакет и ставит этот адрес в заголовок IP. Каждый промежуточный узел благодаря своей таблице маршрутизации точно знает, куда переслать пакет. Юникастовый трафик между двумя узлами беспрепятственно проходит сквозь сеть. Но проблема в том, что в обычном пакете указывается только один IP-адрес получателя.
Что делать, если у одного и того же трафика несколько получателей? В принципе можно расширить одноадресный подход и на такую ситуацию — отправлять каждому клиенту свой экземпляр пакета. Клиенты не заметят разницы — хоть он один, хоть их тысяча, но разница будет отчётливо различима на ваших каналах передачи данных.
Зависимость нагрузки на сеть от количества пользователей при передаче юникаст и мультикаст трафика
Предположим у нас идёт передача одного SD-канала с мультикаст-сервера. Пусть, он использует 2 Мб/с. Всего таких каналов 30, а смотрит каждый канал по 20 человек одновременно. Итого получается 2 Мб/с * 30 каналов * 20 человек = 1200 Мб/с или 1,2 Гб/с только на телевидение в случае одноадресной рассылки. А есть ведь ещё HD каналы, где можно смело умножать эту цифру на 2. И где тут место для торрентов?
Вот почему в IPv4 был заложен блок адресов класса D: 224.0.0.0/4 (224.0.0.0-239.255.255.255). Адреса этого диапазона определяют мультикастовую группу. Один адрес — это одна группа, обычно она обозначается буквой «G».
То есть, говоря, что клиент подключен к группе 224.2.2.4, мы имеем ввиду, что он получает мультикастовый трафик с адресом назначения 224.2.2.4.
Пример 2
Добавим в схему коммутатор и ещё несколько клиентов:
Мультикастовый сервер по-прежнему вещает для группы 224.2.2.4. На коммутаторе все 4 порта должны быть в одном VLAN. Трафик приходит на коммутатор и по умолчанию рассылается во все порты одного VLAN’а. Значит все клиенты получают этот трафик. На них на всех в видеопроигрывателе так же указан групповой адрес 224.2.2.4.
Собственно, все эти устройства становятся членами данной мультикастовой группы. Членство в ней динамическое: кто угодно, в любой момент может войти и выйти из неё.
В данной ситуаци трафик будут получать даже те, кто этого в общем-то и не хотел, то есть на нём не запущен ни плеер, ни что бы то ни было другое. Но только, если он в том же VLAN’е. Позже мы разберёмся, как с этим бороться.
Обратите внимание, что в данном случае от сервера-источника приходит только одна копия трафика на коммутатор, а не по отдельной копии на каждого клиента. И в нашем примере с SD каналами загрузка порта между источником и коммутатором будет не 1,2 Гб/с, а всего 60 Мб/с (2Мб/с * 30 каналов).
Собственно говоря, весь этот огромный диапазон (224.0.0.0-239.255.255.255) можно использовать. Ну, почти весь — первые адреса (диапазон 224.0.0.0/23) всё-таки зарезервированы под известные протоколы.
| Адрес | Значение |
|---|---|
| 224.0.0.0 | Не используется |
| 224.0.0.1 | Все узлы данного сегмента |
| 224.0.0.2 | Все мультикастовые узлы данного сегмента |
| 224.0.0.4 | Данный адрес выделялся для покойного протокола DVMRP |
| 224.0.0.5 | Все OSPF-маршрутизаторы сегмента |
| 224.0.0.6 | Все DR маршрутизаторы сегмента |
| 224.0.0.9 | Все RIPv2-маршрутизаторы сегмента |
| 224.0.0.10 | Все EIGRP-маршрутизаторы сегмента |
| 224.0.0.13 | Все PIM-маршрутизаторы сегмента |
| 224.0.0.18 | Все VRRP-маршрутизаторы сегмента |
| 224.0.0.19-21 | Все IS-IS-маршрутизаторы сегмента |
| 224.0.0.22 | Все IGMP-маршрутизаторы сегмента (v2 и v3) |
| 224.0.0.102 | Все HSRPv2/GLBP-маршрутизаторы сегмента |
| 224.0.0.107 | PTPv2 — Precision Time Protocol |
| 224.0.0.251 | mDNS |
| 224.0.0.252 | LLMNR |
| 224.0.0.253 | Teredo |
| 224.0.1.1 | NTP |
| 224.0.1.39 | Cisco Auto-RP-Announce |
| 224.0.1.40 | Cisco Auto-RP-Discovery |
| 224.0.1.41 | H.323 Gatekeeper |
| 224.0.1.129-132 | PTPv1/PTPv2 |
| 239.255.255.250 | SSDP |
Диапазон 224.0.0.0/24 зарезервирован под link-local коммуникации. Мультикастовые пакеты с такими адресами назначения не могут выходить за пределы одного широковещательного сегмента.
Диапазон 224.0.1.0/24 зарезервирован под протоколы, которым необходимо передавать мультикаст по всей сети, то есть проходить через маршрутизаторы.
Вот, собственно, самые базисные вещи касательно мультикаста.
Мы рассмотрели простую ситуацию, когда источник и получатель находятся в одном сегменте сети. Трафик, полученный коммутатором, просто рассылается им во все порты — никакой магии.
Но пока совсем непонятно, как трафик от сервера достигает клиентов, когда между ними огромная провайдерская сеть линкмиап? Да и откуда, собственно, будет известно, кто клиент? Мы же не можем вручную прописать маршруты, просто потому что не знаем, где могут оказаться клиенты. Не ответят на этот вопрос и обычные протоколы маршрутизации. Так мы приходим к пониманию, что доставка мультикаст — это нечто совершенно новое для нас.
Вообще, чтобы доставить мультикаст от источника до получателя на данный момент существует много протоколов — IGMP/MLD, PIM, MSDP, MBGP, MOSPF, DVMRP.
Мы остановимся на двух из них, которые используются в настоящее время: PIM и IGMP.
С помощью IGMP конечные получатели-клиенты сообщают ближайшим маршрутизаторам о том, что хотят получать трафик. А PIM строит путь движения мультикастового трафика от источника до получателей через маршрутизаторы.
Использование протоколов PIM и IGMP на участках сети