мультикаст на роутере что это

IGMP Proxy и Мультикаст: что это в роутере и как включить?

И так, чтобы раскрыть тему IGMP Proxy, PIM и мультикаста полностью – давайте начнём с самого начала. Вы, наверное, уже знаете, как передаётся эфирное телевидение. То есть у нас есть телевизионная вышка, которая путём радиоволн передаёт закодированный сигнал. А клиент в свою очередь принимает этот сигнал с антенны и видит картинку на телевизоре. Аналогично все происходит и путём кабельного ТВ. Только разница в том, что в кабельном идёт сигнал непосредственно по проложенному проводу к каждому приёмнику.

Но общее все же есть – сигнал одновременно поступает к всем клиентам. Когда вы включите телевизор, то вы увидите сигнал, который отправляется всем. Но если вы включите, например тот же самый YouTube, то там все по-другому. Каждому пользователю предоставляется свой пакет трафика.

И вот мы подошли к вопросу – что же такое мультикаст? Это технология, которая объединяет два этих подхода передачи трафикав. На первом уровне, пакет отправляется только в одном экземпляре, но только тому клиенту, который сделал на него запрос. Приёмников на самом деле может быть несколько.

Самый яркий пример мультикаста — это использования IPTV. Не все провайдеры предоставляют данную возможность, но щас она набирает обороты и возможно, кто-то уже пользуется этой услугой. Представим, что у нас есть два пользователя: Вася и Петя, который подключены к одному провайдеру. Так вот сервер IPTV, отправляет сигналы не всем пользователям, а только тем, кто в данный момент подключен.

Но самое главное, что Вася и Петя будут получать сигнал и пакеты только того канала, который в данный момент включен. Например, Вася смотрит «Первый канал», а Петя «СТС». Сервер четко отправляет пакеты информации только по тому каналу, который активен. Ещё один пример — это онлайн конференция, которой часто пользуются крупные компании. Ведь нет смысла раскидываться трафиком и отправлять всем, можно просто от одного разливать информацию к каждому клиенту.

Реализация

А теперь встаём следующая проблема – как это организовать. Представьте себе, что в сети у провайдера очень много узлов, коммутаторов, маршутизаторов, серверов и есть центральный сервер того же IPTV. Задача сервера отправить трафик таким образом, чтобы он максимально быстро через минимальное количество узлов дошёл до пользователя.

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

А теперь мы подобрались к протоколу IGMP (Internet Group Management Protocol) — это такой протокол, который позволяет быстро подключаться клиенту к ближайшему маршрутизатору. Он сообщает ему, что нужен трафик по тому или иному каналу. Если же запроса к маршрутизатору нет, то он просто простаивает и тем самым высвобождает ресурсы сети.

Также используется PIM (Protocol Independent Multicast) протокол – эта такая система, которая выстраивает адрес от сервера к конечному получателю через одну ветвь дерева. При этом система постоянно мониторит путь, чтобы менять его, если какой-то сегмент выключен или был перемещён.

Проще говоря, сервер транслирует только один сигнал каждого телевизионного канала. И пользователи получают только сигнал того канала, который запросили. Одновременно один сигнал могут получать и несколько приёмников. Именно для этого и нужен протокол IGMP.

Куда идёт пакет

Рассмотрим на примере. Вообще данная технология использует IP адреса 224.0.0.0-239.255.255.255 диапазона. Например, сервер отправляет один канал с адресом 224.2.2.4. Это канал «СТС». IGMP протокол, использующийся только в отрезке между клиентом и ближайшим маршрутизатором, который к нему подключен.

Как включить на роутере

В роутере данная функция чаще всего нужна для нормального просмотра IPTV. По умолчанию эта функция уже включена, но можно проверить. Теперь я покажу как включить эту функцию на примере модели TP-Link.

Заходим в «Сеть» – «IPTV» и включаем «IGMP Прокси». Также не забываем поставить галочку «IGMP Snooping» – функция, исключающая получение трафика от группы, к которой не принадлежит клиент. На новых прошивках данный пункт находится там же, только изначально надо нажать на вкладку «Дополнительные настройки». Обязательно нажмите на кнопку «Сохранить» в само конце.

Источник

Мультикаст

Что такое мультикаст? Наверняка хоть один из читателей данной статьи задастся таким вопросом, поэтому необходимо пояснить смысл данного термина. Multicast – с английского групповая передача. Легче не стало? J Разберемся чуть подробнее. По-русски – multicast – мультивещание. Это форма широковещания, при которой используется принцип от одного к многим. Мультикаст различают по уровням передачи:

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

Но более ясный пример служит телевидение. Один сервер и тысячи клиентов. Он вещает определенной группе, в отличии от Broadcast, что делает процесс передачи картинки и звука зрителю удобным. Эта технология называется IPTV. С помощью нее можно обойтись без необходимости использовать спутниковую тарелку или антенну, чтобы посмотреть любимый канал, все приходит в ваш дом посредством интернет-канала.

Что такое мультикаст в роутере?

Как всем современным пользователям известно, роутер это такая коробочка, которая раздает Интернет на наши девайсы. Любимый Wi-Fi. Но не все знают, что через роутер можно передавать телевизионный сигнал, так называемое телевидение IPTV. Производители беспроводных маршрутизаторов сейчас все чаще включают поддержку IPTV на уровне аппаратных компонентов и низкоуровневого ПО в свои агрегаты. Давайте попробуем разобраться как же все-таки настроить эту функцию у себя дома, если ваш роутер поддерживает данный формат телепередачи.

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

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

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

Выбираем правильный роутер для IPTV

Напомним, что роутер работает с IPTV только через мультикаст, а значит, нам нужен такой роутер, который бы поддерживал данную функцию. Она называется IGMP. Если возникло желании подключить ресивер для цифрового ТВ, эта функция называется STB, необходимо это учесть заранее, так как к маршрутизаторам, которые работают с IPTV через UDP-to-HTTP, подключить ресивер нет возможности. Думаю, не будет лишнем предоставить топ-десятку лучших маршрутизаторов с поддержкой IPTV:

Отличия мультикаст и юникаст

Юникаст (Unicast) – технологический термин, который обозначает похожие с мультикастом функции. Правда, Юникаст – это односторонняя передачи информации единственному адресату. Как вы могли заметить, это полна противоположность широковещательной схеме маршрутизации, то есть мультивещание. У Юникаста есть определенный IP адрес, для которого он предназначен. У мультикаста же есть свои зарезервированные «айпишники», которые они используют для дальнейшего пункта назначения.

Передающий хост в заголовке Юникаста оставляет свой IP адрес, как источник, а IP принимающего, как адрес получателя. Пакеты Юникаст могут использовать всю сеть и подсети, чтобы выполнить эту задачу.

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

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

Источник

Технология Multicast: рациональная передача мегапиксельного видеотрафика

Для более рационального использования пропускной способности и снижения требований к выделяемым каналам связи необходимо использовать технологии экономичного расходования ресурсов вычислительной сети. Рассмотрим всем известные технологии передачи потоков данных от источника к заинтересованным получателям – Multicast и Unicast.

Multicast и Unicast: ключевые различия

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

На рисунке приведено сравнение Unicast-технологии (сверху) копирования потоков данных в соответствии с числом получателей и Multicast-технологии (снизу) с возможностью передавать одну копию большому числу получателей.

Unicast – классическая технология, позволяющая передавать поток данных строго заинтересованному получателю. Используемые протоколы и методы обработки хорошо известны, поэтому не будем на этом подробно останавливаться.

Технология Multicast позволяет передавать потоки данных по IP-сетям, без излишнего дублирования, широкому кругу заинтересованных получателей (рабочие места видеонаблюдения, мобильные устройства, абоненты IPTV, терминалы видеоконференцсвязи), экономя пропускную способность канала. Unicast для вышеописанных целей крайне неэффективен, так как единый источник данных вынужден отправлять столько копий одних и тех же данных, сколько было запрошено. Это приводит к чрезмерной нагрузке на источник данных и локальную сеть (при большом количестве приемников).

Тонкости IP Multicast IP

Multicast использует UDP-пакеты (User Datagram Protocol), что позволяет передавать данные с меньшими задержками, но не отслеживает потери пакетов. Есть возможность компенсировать этот недостаток классификацией трафика (технология QoS).

IP Multicast оперирует группами подписчиков – для получения данных от каждого источника. Каждый подписчик определяет свою принадлежность к той или иной группе, отправляя IGMP-ответ (Internet Group Management Protocol) устройству (часто маршрутизатору), которое опрашивает сеть о существующих группах рассылки с использованием IGMP-сообщений. В результате формируются группы получателей. Для каждой группы источник генерирует один поток данных, а сетевые устройства (маршрутизаторы и коммутаторы) обеспечивают получение этого потока каждым подписчиком конкретной группы.

Прогрессивное применение Multicast

Технологию Multicast крайне целесообразно применять в случаях, когда источники видеосигнала (будь то видеокамера или видеосервер) находятся на значительном удалении от приемников данного сигнала. Это могут быть разные терминалы аэропорта, разные здания промышленного назначения с единым постом видеонаблюдения. Или обратная ситуация, когда приемники видеосигнала (например, АРМ видеонаблюдения) размещаются на значительном удалении от источников и не имеют широкополосного канала связи.

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

Технология Multicast часто находит применение для рассылки видеосерверами потоков видеоданных рабочим местам и иным приемникам. Однако более прогрессивное применение технологии – использование Multicast-потоков видеокамеры (многие камеры имеют поддержку этой функциональности) для получения видеосигнала приемниками. Это позволяет экономить вычислительные мощности серверов, так как видеопотоки транслируются на приемники непосредственно в обход сервера, а сервер осуществляет запись (со всеми смежными функциями).

Памятка инсталляторам

Ретрансляция потоков данных
Технология Multicast относится к функциональности 3-го уровня и потому полноценно поддерживается маршрутизаторами. При этом возможно обойтись без маршрутизаторов, применяя коммутаторы 2-го уровня, но с функцией IGMP snooping.

Многие коммутаторы 2-го уровня могут прослушивать IGMP-сообщения, относящиеся к 3-му уровню, и добавлять соответствующих получателей в таблицу входящих в группу Multicast-хостов – этот механизм и называется IGMP snooping.

С использованием IGMP snooping коммутатор 2-го уровня ретранслирует потоки данных только тем адресатам, которые подписывались на получение Multicast-трафика в конкретную Multicast-группу. В некоторых коммутаторах прослушиванием и анализом IGMP-сообщений занимается отдельная интегральная плата. Она освобождает центральный процессор коммутатора от трудоемкой задачи анализа каждого Multicast-пакета и поиска в нем сообщений о присоединении или оставлении группы.

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

Тонкость в том, что в большинстве случаев инсталляций коммутаторы, несмотря на их широкие возможности по настройке и управлению, не конфигурируют, а ставят «как есть». Почему это происходит, мы обсуждать не будем. Важно следствие – любой ненастроенный коммутатор по умолчанию ведет себя с Multicast-трафиком одинаково – ретранслирует этот трафик на все свои порты, а не на порты, к которым подключены подписчики. Последствие этого явления довольно неприятное – сеть, рассчитанная на определенное значение пропускной способности, перестает справляться с ней, поскольку не предполагалось такого развития событий. В результате активное оборудование сети работает в перегруженном режиме.

Еще один неприятный момент заключается в том, что устройства с сетевыми интерфейсами небольшой пропускной способности (в том числе и Fast Ethernet) при интенсивном Multicast-трафике перестают успевать отбрасывать ненужные им пакеты и принимать нужные пакеты в связи с переполнением буфера интерфейса. В итоге часть пакетов, предназначенных такому устройству, теряется. Для пользователей это будет выглядеть как рассыпание изображений (для видеоданных), прерывание и неразборчивость речи (для аудио). Чтобы локальная сеть выполняла предполагаемые задачи, крайне важно сконфигурировать механизм IGMP snooping на всех коммутаторах 2-го уровня. Эта настройка является важной частью инсталляции и должна быть выполнена грамотным специалистом.

Технология Multicast дает неоспоримые преимущества, но – как и любая задача – ее применение требует комплексного подхода для получения высокоэффективного решения

Практические рекомендации

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

Источник

Приручаем 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 routing для IPTV

Один очень близкий мне человек, поклонник Хабра, захотел внести вклад в развитие блога Cisco. Являясь яростным поклонником того, что создает эта корпорация, он захотел поделиться опытом. =) Надеемся росчерк пера удался.

Относительно недавно мне посчастливилось познакомить и даже поконфигурять multicast routing для IPTV. Изначально, я с этой темой была совершенно не знакома, и это заставило меня вылакать горлышко от цистерны водки перекопать огромное количество документации, чтобы войти в курс дела.

И вот незадача. Обычно в документации выкладывают все и сразу и для человека, впервые столкнувшегося с этой темой, не понятно с чего начать. Во время чтения pdf’ок я ловила себя на мысли, что было бы неплохо наткнуться где-нибудь на статью, которая могла бы коротким путем провести от теории к практике, чтобы понять с чего стоит начать и где заострить внимание.

Мне не удалось обнаружить такую статью. Это побудило меня написать эту статейку для тех, кто также как и я столкнется с вопросом, что это за зверь IPTV и как с ним бороться.

Введение

Это моя самая первая статья (но не последняя! есть еще много зверей), постараюсь изложить все как можно доступнее.

Какой вид трафика использовать для IPTV?

Очевидно, что для вещания каналов наибольшее предпочтение отдается multicast.
Любой TV-канал, который мы хотим вещать в сеть, характеризуется адресом группы, который выбирается из диапазона, зарезервированного для этих целей: 224.0.0.0 – 239.255.255.255.

Для работы IPTV необходим роутер, поддерживающий multicast (далее MR). Он будет отслеживать членство того или иного клиента в определенной группе, т.е. постоянно следить какому клиенту какой отправлять TV-канал.

Для того чтобы клиент смог зарегистрироваться в одной из этих групп и смотреть TV-канал используется протокол IGMP (Internet Group Management Protocol).

Немного о том, как работает IGMP.

Есть сервер, который включен в роутер MR. Этот сервер вещает несколько TV-мультиков, например:

Клиент включает канал News, тем самым, сам не подозревая, он отправляет запрос на MR для подключения к группе 224.12.0.1. С точки зрения протокола IGMP это запрос “JOIN 224.12.0.1”.

Если пользователь переключается на другой канал, то он сначала отправляет уведомление MR, что он отключает канал News или покидает эту группу. Для IGMP это “LEAVE 224.12.0.1”. А затем повторяет аналогичный запрос JOIN для нужного канала.

MR иногда спрашивает всех: “а какой группе кто подключен?”, чтобы отключать тех клиентов, с которыми оборвалась связь и они не успели отправить уведомление LEAVE. Для этого MR использует запрос QUERY.

Ответ абонента на этот запрос это MEMBERSHIP REPORT, который содержит список всех групп, в которых состоит клиент.

Настройка multicast routing.

Предположим, что клиенты одной группы смотрят один и тот же мультик, но находятся они в разных сегментах сети (network A и network B). Для того, чтобы они получили свой мультик и придуман multicast routing.

Пример настройки роутеров MR1 и MR2.

Команда «ip multicast-routing» включает соответствующий routing, если же он выключен, то роутер не пересылает multicast пакеты, т.е. они не дойдут до недоумевающего зрителя мультиков.

Остановимся чуть поподробнее на команде «ip pim sparse-mode«.

Про режимы протокола PIM и сам протокол.

PIM (Protocol Independent Multicast) — протокол маршрутизации multicast рассылки. Он заполняет свою таблицу multicast маршрутизации на основе обычной таблицы маршрутизации. Эти таблицы можно просмотреть с помощью команд “sh ip mroute” и “sh ip route” соответственно. Целью протокола PIM является построение дерева маршрутов для рассылки multicast сообщений.

У протокола PIM существует два основных режима: разряженный (sparse mode) и плотный (dense mode). Таблица multicast маршрутизации для них выглядит немного по-разному. Иногда эти режимы рассматривают как отдельные протоколы — PIM-SM и PIM-DM.

В нашей конфигурации на интерфейсах мы указали режим «ip pim sparse-mode«.

dense-mode Enable PIM dense-mode operation
sparse-dense-mode Enable PIM sparse-dense-mode operation
sparse-mode Enable PIM sparse-mode operation
………

В чем же разница?

PIM-DM использует механизм лавинной рассылки и отсечения (flood and prune). Другими словами. Роутер MR отправляет всем все multicast потоки, которые на нем зарегистрированы. Если клиенту не нужен какой-то из этих каналов, то он от него отказывается. Если все клиенты, висящие на роутере, отказались от канала, то роутер пересылает “спасибо, не надо” вышестоящему роутеру.

PIM-SM изначально не рассылает зарегистрированные на нем TV-каналы. Рассылка начнется только тогда, когда от клиента придет на нее запрос.

Т.е. в PIM-DM MR отправляет всем, а потом убирает ненужное, а в PIM-SM MR начинает вещание только по запросу.

Если члены группы разбросаны по множеству сегментов сети, что характерно для IPTV, PIM-DM будет использовать большую часть полосы пропускания. А это может привести к снижению производительности. В этом случае лучше использовать PIM-SM.

Между PIM-DM и PIM-SM существуют еще отличия.
PIM-DM строит дерево отдельно для каждого источника определенной multicast группы, т.е. multicast маршрут будет характеризоваться адресом источника и адресом группы. В multicast таблице маршрутизации будут записи вида (S,G), где S — source, G — group.

У PIM-SM есть некоторая особенность. Этому режиму необходима точка рандеву (RP — rendezvous point) на которой будут регистрироваться источники multicast потоков и создавать маршрут от источника S (себя) до группы G: (S,G).

Таким образом, трафик идет с источника до RP по маршруту (S,G), а далее до клиентов уже по общему для источников определенной группы дереву, которое характеризуется маршрутом (*,G) — «*» символизирует «любой источник». Т.е. источники зарегистрировались на RP, и далее клиенты уже получают поток с RP и для них не имеет значения, кто был первоначальным источником. Корнем этого общего дерева будет RP.

Точкой рандеву является один из multicast роутеров, но все остальные роутеры должны знать “кто здесь точка RP”, и иметь возможность до нее достучаться.

Пример статического определения RP (MR1). Объявим всем multicast роутерам, что точкой рандеву является 10.0.0.1 (MR1):

Все остальные роутеры должны знать маршрут до RP:
ip route 10.0.0.0 255.255.255.0 10.10.10.1

Существуют так же и другие способы определения RP, это auto-RP и bootstarp router, но это уже тема для отдельной статьи (если кому-нибудь будет интересно – пожалуйста)?

Посмотрим, что будет происходить после настройки роутеров.

Мы по-прежнему рассматриваем схему с роутерами MR1 (RP) и MR2. Как только включаем линк между роутерами MR1 и MR2, то должны увидеть в логах сообщения

Для MR1:
%PIM-5-NBRCHG: neighbor 10.10.10.2 UP on interface Ethernet3

Для MR2:
%PIM-5-NBRCHG: neighbor 10.10.10.1 UP on interface Ethernet0

Это говорит о том, что роутеры установили отношение соседства по протоколу PIM друг с другом. Проверить это также можно с помощью команды:

MR1#sh ip pim neighbor

PIM Neighbor Table
Mode: B — Bidir Capable, DR — Designated Router, N — Default DR Priority, S — State Refresh Capable

Не забываем про TTL.

В качестве тестового сервера мне было удобно использовать плеер VLC. Однако, как позже обнаружилось, даже если выставить через GUI достаточный TTL, он все равно (надеюсь только в использованной мной версией) упорно отправлял multicast пакеты с TTL=1. Запускать упрямого пришлось с опцией «vlc.exe –ttl 3» т.к. у нас на пути будет два роутера, каждый из которых уменьшает TTL пакета на единицу.

Как же все таки обнаружить проблему с TTL? Один из способов. Пусть сервер вещает канал 224.12.0.3 с TTL=2, тогда на роутере MR1 пакеты проходят нормально, а за роутером MR2 клиенты уже не смогут смотреть свой мультик.

Обнаруживается это с помощью команды «sh ip traffic» на MR2. Смотрим на поле “bad hop count” – это число пакетов, которые “умерли”, как им и отмеряно, по TTL=0.

MR2#sh ip traffic

IP statistics:
Rcvd: 36788 total, 433 local destination
0 format errors, 0 checksum errors, 2363 bad hop count
……………………………………

Если этот счетчик быстро увеличивается, значит — проблема в TTL.

Show ip mroute

После включения вещания трех каналов на сервере в таблице multicast маршрутизации наблюдаем следующее:

MR1# sh ip mroute

(*, 224.12.0.1), 00:03:51/stopped, RP 10.0.0.1, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null

(10.0.0.2, 224.12.0.1), 00:03:52/00:02:50, flags: PT
Incoming interface: Ethernet0, RPF nbr 0.0.0.0
Outgoing interface list: Null

(*, 224.12.0.2), 00:00:45/stopped, RP 10.0.0.1, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null

(10.0.0.2, 224.12.0.2), 00:00:45/00:02:50, flags: PT
Incoming interface: Ethernet0, RPF nbr 0.0.0.0
Outgoing interface list: Null

(*, 224.12.0.3), 00:00:09/stopped, RP 10.0.0.1, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null

(10.0.0.2, 224.12.0.3), 00:00:09/00:02:59, flags: PT
Incoming interface: Ethernet0, RPF nbr 0.0.0.0
Outgoing interface list: Null

Видим, что появились маршруты вида (S,G), например (10.0.0.2, 224.12.0.3), т.е. зарегистрировался источник 10.0.0.2, который вещает для группы 224.12.0.3. А так же маршруты с RP до клиента: (*,G), например (*, 224.12.0.3) – которые они будут использовать, так называемое общее для всех дерево.

Как только на интерфейс MR1 (RP) приходит запрос на получение канала 1, в multicast таблице маршрутизации происходят следующие изменения:

MR1#sh ip mroute

…………………
(*, 224.12.0.1), 00:33:16/00:02:54, RP 10.0.0.1, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet3, Forward/Sparse, 00:02:37/00:02:53

(10.0.0.2, 224.12.0.1), 00:33:17/00:03:25, flags: T
Incoming interface: Ethernet0, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet3, Forward/Sparse, 00:02:37/00:02:53

Стало видно, что приходят запросы на эту группу с порта Ethernet3.

RPF проверка

Возможна ситуация, когда роутер получает multicast поток на двух интерфейсах. Кого из этих двух интерфейсов роутер будет считать источником?

Для этого он выполняет проверку RPF (Reverse Path Forwarding) — проверяет по обычной unicast таблице маршрутизации маршрут до источника и выбирает тот интерфейс, через который идет маршрут до этого источника. Эта проверка необходима для того чтобы избежать образования петель.

Отследить, как источник проходит проверку RPF можно с помощью команды:

MR2#sh ip rpf 10.0.0.2

RPF information for? (10.0.0.2)
RPF interface: Ethernet0
RPF neighbor:? (10.10.10.1)
RPF route/mask: 10.0.0.0/24
RPF type: unicast (static)
RPF recursion count: 0
Doing distance-preferred lookups across tables

Ну, вот и появилась та статейка, которую я бы с удовольствием нашла, на начальном этапе изучения multicast routing’а для IPTV. Я не волшебник, я только учусь… Потому, с радостью выслушаю все пожелания, замечания и советы. А так же, очень надеюсь, что для кого-то она окажется полезной. =)

UPD: Разрешите представить ее. Елена Сахно — lena_sakhno

Источник