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

Сети для самых маленьких. Часть 9.1. Мультикаст. Общее понимание Multicast

Наш умозрительный провайдер linkmeup взрослеет и обрастает по-тихоньку всеми услугами обычных операторов связи. Теперь мы доросли до IPTV.

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

Это первое отклонение от привычных нам принципов работы IP-сетей. Всё-таки парадигма многоадресной рассылки в корне отличается от тёплого лампового юникаста.

Можно даже сказать, это в некоторой степени бросает вызов гибкости вашего разума в понимании новых подходов.

В этой серии статей сосредоточимся на следующем:

Содержание серии статей про мультикаст

• Общее понимание Multicast
• Протокол IGMP
• Протокол PIM
  • PIM Dense Mode
  • PIM Sparse Mode
  • SPT Switchover — переключение RPT-SPT
  • DR, Assert, Forwarder
  • Автоматический выбор RP
  • SSM
  • BIDIR PIM
• Мультикаст на канальном уровне
  • IGMP Snooping
  • MVR
• Дополнительно: Микровыпуск СДСМ. Подготовка лаборатории для работы с мультикаст в GNS3

На заре моего становления, как инженера, тема мультикаста меня неимоверно пугала, и я связываю это с психотравмой моего первого опыта с ним.

«Так, Марат, срочно, до полудня нужно пробросить видеопоток до нашего нового здания в центре города — провайдер отдаст его нам тут на втором этаже» — услышал я одним чудесным утром. Всё, что я тогда знал о мультикасте, так это то, что отправитель один, получателей много, ну и, кажется, протокол 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.

Сформулируем два основных принципа мультикастовой рассылки:

1. отправитель посылает только одну копию трафика, независимо от количества получателей;
2. трафик получают только те, кто действительно заинтересован в нём.

В данной статье для практики мы возьмём IPTV, как наиболее наглядный пример.

Пример 1

Начнём с самого простого случая:

Пример 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

Добавим в схему коммутатор и ещё несколько клиентов:

Пример 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) всё-таки зарезервированы под известные протоколы.

Список зарезервированных IP-адресов

Адрес	Значение
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 на участках сети

Мультикаст

Что такое мультикаст? Наверняка хоть один из читателей данной статьи задастся таким вопросом, поэтому необходимо пояснить смысл данного термина. 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:

• TP-LINK TL-WR841N – средняя цена по стране всего 1300 рублей, бюджетный вариант.
• MikroTik hAP lite – средняя цена чуть выше, 1600, но он очень качественный и многофункциональный.
• Xiaomi Mi WiFi Router 3 – известнейшая китайская компания с большим выбором цифровой электроники, средняя цена 2400.
• ASUS RT-AC51U – средняя цена по России 2400.

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

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

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

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

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

Как организовать домашний кинотеатр с помощью роутера

Содержание

Содержание

Домашние кинотеатры давно уже перестали быть предметом роскоши. Качество, которое лет пять назад могли себе позволить только владельцы дорогих медиацентров, сегодня доступно многим. Сегодня вопрос «быть или не быть домашнему кинотеатру» звучит скорее как «Как и из чего собрать домашний кинотеатр». И если с воспроизведением звука и изображения все более-менее понятно, то с выбором основы домашнего кинотеатра не так просто – вариантов много: медиаплеер, смарт-телевизор, DVD-плеер, AV-ресивер. А мы сделаем домашний кинотеатр с помощью роутера. Для этого может даже не потребоваться никаких вложений – достаточно использовать возможности, уже заложенные в технику.

Роутер для домашнего кинотеатра: плюсы и минусы

Всевозможные носители музыки и видео потихоньку уходят в прошлое, источником медиаконтента все чаще является Интернет — IPTV, Youtube, социальные сети и т. д. Здесь роутеру «все карты в руки». Если у устройства есть USB-порт, то подключенный жесткий диск вполне может превратить роутер в полноценную медиатеку. С помощью DLNA медиаконтент с диска будет доступен на всех устройствах, поддерживающих эту технологию. И для всего этого не требуется приобретение каких-то устройств — роутер сегодня есть практически в каждой квартире.

Однако, минусы у такого решения тоже есть:

1. Роутер предоставляет лишь сетевой доступ, он не раздает данные по общепринятым аудио- и видео- стандартам. Поэтому все устройства, желающие получить данные от такого головного устройства, должны быть «умными» — подключаться к сети (Wi-Fi или Ethernet) и иметь какую-нибудь операционную систему с браузером, плеером, набором кодеков, файл-менеджером и т. д. И крайне желательно, чтобы была возможность обновить все это «добро», а производитель оперативно реагировал на изменения кодеков и стандартов, выкладывая соответствующие обновления. Для телевизоров этот момент не столь принципиален — «умных» из них сегодня три из четырех. А вот у проекторов могут возникнуть проблемы с доступом к медиатеке, и тогда потребуется приобретение смарт-приставки.
2. Возможна потеря качества сигнала при передаче. Во-первых, сигнал может просто «потеряться» из-за загруженности Wi-Fi или недостаточной пропускной способности сети. Иногда это можно решить приоритезацией трафика или переходом на диапазон 5 ГГц вместо 2,4. В крайнем случае можно подключить устройство кабелем RJ-45 (если у него есть соответствующий разъем). А вот вторая причина может оказаться более проблемной: если ваша аудиосистема не «умная» и звук на нее идет, допустим, через «умный» телевизор, то на качество звука может влиять аудиовыход. Большинство телевизоров способно «отдавать» звук только через стандарт S/PDIF (в лучшем случае), который не поддерживает передачу несжатого многоканального звука. Проще говоря, аудиофилам такой домашний кинотеатр наверняка не понравится.
3. Настройки роутера недостаточно для просмотра IPTV на телевизоре — потребуется еще приобретение IPTV-приставки.

Пример организации домашнего кинотеатра на роутере

Роутер должен иметь порты USB и поддерживать подключение внешних жестких дисков. Некоторые старые роутеры не поддерживают жесткие диски объемом более 1 ТБ — если это ваш случай, обновите прошивку.

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

Смарт-приставку (медиаплеер) для проектора следует подбирать по параметрам — она должна уметь подключаться к локальной сети через Wi-Fi или Ethernet, иметь раздельный выход аудио- и видеосигнала и пульт ДУ. Желательны также поддержка DLNA и полноценный выход в Интернет, что есть далеко не во всех приставках.

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

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

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

Еще имеет смысл поискать в настройках «IGMP-proxy» (есть не во всех роутерах и не во всех прошивках) и включить его, если нашелся.

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

Чуточку сложнее, если провайдер выдает для IP-телевидения тегированную виртуальную сеть (VLAN). В этом случае, кроме указания порта, к которому подключен IPTV-приемник, надо будет еще задать параметры VLAN ID, полученные от провайдера. Для некоторых роутеров (например, D-link) потребуется создать VLAN c заданным ID и проассоциировать его с нужным портом:

Как видите, ничего сложного. Еще потребуется настроить приставку IPTV, но это в большинстве случаев также не вызывает затруднений. Обычно достаточно указать способ подключения (Ethernet/Wi-Fi) и задать автоматическое получение IP-адреса (Автоматический с DHCP). А чаще всего эти параметры уже стоят по умолчанию, и для работы IPTV-приставки ее достаточно просто подключить к роутеру и включить в сеть.

Приоритезация трафика на роутере — настройка QoS

К Wi-Fi сегодня что только не подключено: компьютеры, бытовая техника, смартфоны и планшеты. Неудивительно, что скорость подключения порой начинает «проседать», даже если ваш роутер — единственный на ближайшие 100 метров. Но одно дело падение скорости при фоновом скачивании большого файла, и совсем другое – оно же, но при просмотре фильма. Вполне логично возникает желание распределить нагрузку на сеть между разными потребителями, и это вполне можно сделать с помощью технологии QoS (Quality of Service — Качество обслуживания).

Настроить QoS на роутере несложно. Для этого службу надо включить, а потом настроить правила для каждого из видов интернет-активности:

Не следует путать QoS с контролем пропускной способности. В последнем случае роутер ограничивает пропускную способность для некоторых клиентов четко заданным числом. И даже если канал совершенно свободен, клиент не сможет скачивать на скорости, большей, чем заданная. А QoS оперирует приоритетами: если клиент имеет низкий приоритет, но канал при этом пуст, он будет подключен на максимальной скорости, которая упадет, как только подключится клиент с большим приоритетом.

Увы, поддержка QoS есть не во всех роутерах. Кроме того, QoS не поможет, если причина падения скорости — не одновременное подключение к роутеру множества устройств, а загруженность диапазона другими Wi-Fi сетями. В этом случае скорее поможет смена диапазона (если роутер двухдиапазонный, и у клиента есть поддержка 5 ГГц) либо подключение клиента кабелем RJ-45.

Настройка DLNA на роутере

DLNA (Digital Living Network Alliance — Сетевой Альянс Цифровой жизни) — технология, упрощающая доступ к медиафайлам для всех устройств в сети, поддерживающих DLNA. Она сходна с представлением общего доступа к определенным папкам, однако намного проще в настройке, поэтому с ней не возникает проблем, связанных с правами пользователей.

Настройка DLNA также весьма проста: достаточно подключить жесткий диск к порту USB и включить в настройках «DLNA-сервер» или «Медиа-сервер» и задать имя сервера, под которым он будет виден на других устройствах. Также можно выбрать доступ ко всему устройству или только к отдельным папкам.

Теперь на смарт-телевизоре среди прочих источников должен появиться DLNA-сервер с заданным именем.

Возможно, то, что получилось в результате описанных настроек, и не дотягивает до полноценных домашних кинотеатров, собранных на основе дорогих AV-ресиверов и Hi-Fi аудиосистем. Но для того, чтобы ознакомиться с популярными видеороликами, посмотреть свежевышедшую серию популярного Интернет-сериала или поностальгировать на любимый фильм из своей медиатеки – этого вполне достаточно. А главное – для этого, вполне возможно, даже не придется ничего покупать – достаточно правильно соединить и настроить уже имеющуюся технику.

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

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

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

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

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

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

1. Реализация
2. Куда идёт пакет
3. Как включить на роутере

Реализация

А теперь встаём следующая проблема – как это организовать. Представьте себе, что в сети у провайдера очень много узлов, коммутаторов, маршутизаторов, серверов и есть центральный сервер того же 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 протокол, использующийся только в отрезке между клиентом и ближайшим маршрутизатором, который к нему подключен.

1. Так вот, пользовательская программа отправляет запрос на просмотр канала 224.2.2.4 ближайшему маршрутизатору.
2. Если в маршрутизаторе уже есть поток и через него идёт дерево канала, который запросил клиент – то пакеты сразу же отправляются пользователю, и он видит изображение.
3. Как только клиент выключит программу на маршрутизатор отправляется сигнал, о выходе из группы и сигнал более туда не идёт.
4. Но также маршрутизатор постоянно отправляет сигнал на ближайших включенных клиентов, чтобы удостовериться, что они ещё принимают трафик. Происходит это каждые 60 секунд. Клиент, который получил такой запрос, обязан отправить ответ или его отключат. Все это происходит в автономном режиме.

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

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

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

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

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

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

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

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

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

224.12.0.1	канал 1	News
224.12.0.2	канал 2	History
224.12.0.3	канал 3	Animals

Клиент включает канал 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.

Network A	10.1.0.0/24
Network B	10.2.0.0/24
Network C	10.3.0.0/24

Остановимся чуть поподробнее на команде «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«.

(config-if)# ip pim?

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):

ip pim rp-address 10.0.0.1 IPTV override	указываем адрес RP и access-list IPTV access-list определяет какие группы
ip access-list standard IPTV	регистрироваться на данной точке рандеву
permit 224.11.0.0 0.0.0.3

Все остальные роутеры должны знать маршрут до 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

Neighbor Address	Interface	Uptime/Expires	Ver	DR Prio/Mode
10.10.10.2	Ethernet3	00:03:05/00:01:37	v2	1 / DR S

Не забываем про 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 ?
Hostname or A.B.C.D IP name or address of multicast source

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