Igmp proxy что в роутере. IGMP snooping: понятие и использование

28.01.2019

Для объединения в группы сетевых устройств IP-узлы и маршрутизаторы используют протокол управления IGMP. Internet Group Management Protocol руководит multicast (групповой) в сетях. Он находится на сетевом уровне и соединяет клиентский компьютер с локальным маршрутизатором с целью передачи данных между ними. Затем групповой трафик направляется к остальным клиентам через протокол PIM. Он связывает локальный маршрутизатор с удаленным. Благодаря применению IGMP сетевые ресурсы ряда приложений (игры онлайн, потоковое видео) могут использоваться более эффективно.

Принять решение о трансляции трафика в те или иные интерфейсы позволяет использование функции IGMP snooping. процесс отслеживания IGMP-запросов от потребителей (хостов) к поставщикам (групповым маршрутизаторам).

Понятие и назначение IGMP snooping

В переводе с английского snooping означает "подслушивание". При его включении промежуточное сетевое устройство (маршрутизатор или коммуникатор) начинает анализировать передачу всех пакетов данных, осуществляемую между клиентскими компьютерами, подключенными к нему, и маршрутизаторами, поставляющими групповой трафик. При обнаружении запроса на подсоединение включается порт, к которому подключен потребитель (клиент), в противоположной ситуации (запрос Leave) соответствующий порт удаляется из списка группы.

В большинстве коммуникаторов функция IGMP snooping доступна, но требует предварительного включения.

Зачем отслеживать сетевой трафик?

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

Если коммуникатор начинает транслировать групповой трафик по всем своим портам, то:

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

Для исключения подобных ситуаций и существует функция IGMP snooping, значительно улучшающая работу всей сети. Она учитывает потребности на сетевом (третьем) уровне и таким образом оптимизирует канальный (второй) уровень передачи данных.

Включение функции прослушки

Для того чтобы отслеживать multicast-трафик, требуется сначала включить IGMP snooping и настроить его самостоятельно. Рассмотрим, как это сделать на коммуникаторах D-Link при реализации схемы многоадресной передачи данных. Команды для активизации сетевой прослушки:

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

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

Виды IGMP-прослушки

Функция IGMP snooping может быть как пассивной, так и активной. В чем это проявляется?

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

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

Функциональность IGMP snooping-коммуникатора помогает снизить нагрузку на сеть благодаря отслеживанию им процессов обмена данными между поставщиками (локальными маршрутизаторами) и потребителями (клиентскими компьютерами) группового трафика.

Music On Hold - замечательная функция, позволяющая проигрывать абоненту музыку, в то время пока тот находится на ожидании или поставлен on hold .

MoH различают по настройке и методу передачи на два типа:

Unicast MOH - Представляет собой однонаправленный поток point-to-point. Это означает, что для любого абонента поставленного on hold генерируется отдельный поток.
По умолчанию CUCM поддерживает 250 одновременных потоков Unicast MOH .
Понятно, что при большом количестве абонентов использование Unicast MOH может сказаться на производительности MOH Server а также сети.
Multicast MOH - Это потоки MOH, которые отсылаются от MOH Server на multicast group address, при этом endpoints могут к нему подключаться при необходимости.
Multicast MOH не загружает ресурсы, но его должна поддерживать сеть.
По умолчанию Multicast MOH поддерживает 30 000 одновременных подключений к потоку MOH.

По умолчанию на CUCM включена только функция Unicast MOH ; она же и самая простая в настройке.
Но при большом количестве абонентов, а также в крупном предприятии для экономии расхода трафика на участках сети WAN рекомендуется настройка Multicast MoH .
Как понятно из названия Multicast MoH базируется на методе передачи данных Multicast.

Multicasting

Для примера рассмотрим поток Music on Hold.
При использовании Unicast для его передачи каждому получателю отсылаются по копии каждого пакета. Т.е. от источника будет одновременно исходить столько же потоков RTP, сколько получателей на данный момент.
При использовании broadcast от источника будет исходить только один поток, но трафик broadcast получают все устройства сети, в том числе и те кому этот поток не нужен.
При использовании технологии Multicast сервер-источник отдаёт только один поток, а получают этот поток только те клиенты кому этот поток нужен.

Получатели подключаются к определенной multicast group (Class D IP address, т.е. находящийся в интервале 224.0.0.0 - 239.255.255.255 ). Сервер-источник шлет трафик на этот Class D IP address; свитчи а также routing protocols передают этот трафик только к подписавшимся машинам.

Internet Group Management Protocol

IGMP - это протокол, который используется между клиентами и маршрутизаторами. Его работа происходит следующим образом:

Клиент отсылает IGMP Join message на multicast-enabled router .
Маршрутизатор получает IGMP Join message на свой интерфейс. И теперь маршрутизатор знает, что на этот интерфейс следует отсылать трафик multicast на определённую multicast group

Существует три версии IGMP , но широко используются только две:

IGMP Version 1 - Когда клиенту нужно присоединиться к группе multicast, клиент отсылает роутеру сообщение IGMP Re-
port . Далее по умолчанию каждые 60сек маршрутизатор шлёт клиенту запросы IGMP Query message на адрес 224.0.0.1 (all IP multicast hosts), чтобы убедиться что клиенту всё еще нужно членство в этой multicast group . По истечении таймаута 3мин считается что клиент покинул группу и передача мультикастного трафика к нему прекращается.
IGMP Version 2 - очень похожа на первую версию, добавлена возможность отсылать em>IGMP Query message на определённую группу, также добавлена поддержка Leave message .

Хосты и роутеры разных версий IGMP способны работать совместно.

Как уже упоминалось, multicast router периодически отсылает запросы IGMP Query message со стороны интерфейса, где находятся клиенты. Если окажется что в сети находятся два и более multicast router , только один из них выбирается как querier для данного сегмента.
IGMP designated querier - это маршрутизатор с наименьшим IP адресом.

Для определения какой маршрутизатор является querier :
show ip igmp interface

Отображение мультикастных групп, доступных через данный маршрутизатор:
show ip igmp group

Если Layer 2 switch получает на интерфейсе multicast frame , то по умолчанию он флудит копии этого кадра на все интерфейсы. Для предотвращения такого поведения необходимо настроить IGMP snooping .
IGMP snooping - фича, позволяющая коммутатору автоматически определять интерфейсы, подключенные к клиентам для определённых multicast groups . Это достигается тем, что коммутатор анализирует IGMP traffic между клиентами и маршрутизатором.

Глобально включаем IGMP snooping:
Switch(config)# ip igmp snooping

Включение IGMP snooping на определённых VLANs:
Switch(config)# ip igmp snooping vlan vlan_id

Multicast Addressing

В мультикастной сети сервер-источник отсылает пакеты на Class D IP Address .
Адреса класса D это IP адреса, которые начинаются с 1110 и находятся в интервале 224.0.0.0 - 239.255.255.255 .

Class D IP Address в свою очередь делится на следующие подинтервалы:

224.0.0.0–224.0.0.255	Reserved Link Local Addresses - Специализированные адреса, используемые для служебных целей, например: 224.0.0.5, 224.0.0.6 - OSPF 224.0.0.9 - RIPv2 224.0.0.10 - EIGRP 224.0.0.1 - all multicast hosts 224.0.0.2 - all multicast routers
224.0.1.0–238.255.255.255	Globally Scoped Addresses - Используются для приложений multicast. Поскольку эти адреса уникальны глобально, они могут быть использованы и за пределами local autonomous system .
232.0.0.0–232.255.255.255	Source-Specific Multicast (SSM) Addresses - Эти адреса используются совместно с IGMPv3, который позволяет клиентам принимать трафик не только на основе мультикастной группы, но и на основе конкретных источников этого трафика. Таким образом в среде SSM разные сервера могут слать различный контент, при этом находясь в одной и той же группе.
233.0.0.0–233.255.255.255	GLOP Addresses - These addresses provide a globally unique multicast address range, based on autonomous system numbers.
239.0.0.0–239.255.255.255	Limited Scope Addresses - эти адреса используются для внутренних мультикастных приложений. Это очень похоже на private addresses типа 10.0.0.0/8. Адреса из этого интервала будут использоваться к примеру для организации

Также в дополнение к адресу 3-го уровня, multicast applications также должны иметь адреса 2-го уровня (MAC Addresses).
Адрес 2-го уровня автоматом составляется исходя из адреса 3-го уровня:
- Multicast MAC address это адрес длиной 48-bit, и первая его половина (24бита) всегда будет (hex) 01-00-5e
- 25-ый бит всегда "0"
- Последние 23 бита для Multicast MAC address напрямую забираются из Multicast IP address

Для примера рассмотрим Multicast IP address 224.1.10.10 :

В двоичном коде он будет выглядеть:
11100000.00000001.00001010.00001010
Здесь нас интересуют последние 24 бита, т.е.:
00000001.00001010.00001010
Если самый левый бит не "0", его нужно сделать нулём. Поскольку 25-ый бит у Multicast MAC address всегда "0"
Переводим каждый октет в 16-ную систему:
01-0a-0a
Слева приставляем первую половину 01-00-5e и получаем:
01-00-5e-01-0a-0a

Distribution Trees

Маршрутизаторы, находящиеся в сети, должны определить для мультикаста forwarding path , т.е. путь для пакетов от источника до клиента. Структуру этого пути принято изображать в виде дерева, корнем которого является источник. Источнику абсолютно всё равно кто является клиентом, следовательно структуру дерева определяют маршрутзаторы, через которые идёт трафик.
На рисунке изображен пример пример возникновения проблемы duplicate packets , которая заключается в том, что роутеру необходимо решить какой из потоков следует форвардить далее, а какой нет.

В этом случае маршрутизатор применяет метод Reverse Path Forwarding (RPF) .
RPF - это процедура при которой у входящего пакета multicast берется source address , и затем по таблице маршрутизации проверяется egress interface для данного маршрута. Если входящий пакет использует этот интерфес, RPF check passes и данный пакет пропускается дальше, если нет, то RPF check fails .

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

Мультикастный трафик идёт от источника к назначению по пути, который называют distribution tree . Различают два типа distribution tree :

PIM-DM Mechanics

Для создания IP multicast distribution trees маршрутизаторы cisco используют протокол Protocol Independent Multicast (PIM) . PIM способен работать в любой IP сети, т.е. к примеру OSPF, EIGRP или статика, - отсюда и название: Independent .
Существуют два вида протокола PIM:

PIM Dense Mode (PIM-DM) - использует source distribution tree . Изначально каждый PIM DM router или multilayer switch полагают, что все нижестоящие девайсы нуждаются в мультикастном трафике для данной группы. В результате мультикастный трафик изначально флудит (flood) по всем устройствам, независимо от того кому он нужен, а кому не нужен; и только потом обрубается (prune). Мультикастное дерево в режиме работы PIM Dense Mode (PIM-DM) растет начиная от источника т.е. от корня к листьям. Получившееся дерево называют source tree или source distribution tree , т.к. корень его есть источник мультикаста.
Алгоритм работы:
1. Источник трафика multicast начинает отдавать трафик в сеть
2. Если в broadcast medium более одного роутера форвардят мультикастный трафик, только один из них выбирается как PIM forwarder . Выборы производятся через использование Assert messages , побеждает роутер с лучшей метрикой (по умолчанию это highest IP address)
3. Некоторые маршрутизаторы могут не иметь за собой подписавшихся клиентов на данный мультикастный трафик. Такие роутеры отсылают вышестоящим соседям сообщения Prune message - в результате ведвь дерева в этом направлении "обрубается". При этом, если роутер ничего не отсылает, и мультикаст продолжает на него валиться.
4. Если за роутером появляется клиент на данную группу, данный роутер может присоединиться к дереву, отсылая сообщение Graft message
PIM Sparse Mode (PIM-SM) - использует shared distribution tree .
В этом режиме работы мультикастное дерево растёт и расширяется только тогда, когда какой-нибудь клиент подключится к мультикастной группе.
В режиме PIM Sparse Mode (PIM-SM) мультикастное дерево растет в обратном направлении: от листьев к корню. При этом корень дерева не обязательно будет источником трафика. Корнем дерева может быть некий маршрутизатор, находящийся в центре сети. Такой маршрутизатор называется Rendezvous Point (RP) .
Как только клиент присоединяется к мультикастной группе, last hop router отсылает на RP membership report . По этому пути каждый роутер добавляется к дереву подобно веткам. Поскольку к дереву подсоединяются только маршрутизаторы, за которыми есть клиент в группе, при данном алгоритме нет необходимости впоследствии обрубать ненужные маршруты.
Подробный алгоритм работы:
1. Получатель шлёт на свой маршрутизатор IGMP Report message , чтобы подсоединиться к определённой группе. Этот маршрутиатор (т.е. last hop router ) высылает Join message на RP, таким образом по пути от RP до last hop router , у маршрутизаторов будет состояние (*, G)
2. Источник включается и создаёт source tree между first-hop router и RP: вдоль этого пути будет состояние (S, G) . Источник шлёт в сторону RP мультикастные сообщения Register messages , после этого tree is completely established .
3. После того, как RP получает от источника Register message , для их остановки он отсылает обратно Register Stop message . В итоге образуется два дерева:
  - Source tree from the first-hop router to the RP.
  - Shared tree from the RP to the last-hop router.
  Но путь может оказаться не оптимальным.
4. last-hop router определяет откуда идёт мультикастный трафик, и отсылает Join message напрямую к first-hop router , таким образом формируется оптимальный путь.
5. Теперь last-hop router получает мультикастный трафик напрямую от first-hop router , и поэтому более не нуждается в мультикастном трафике от RP. last-hop router отсылает на RP (S, G) RP-bit Prune message , тем самым запрашивая RP остановить мультикастный трафик.
6. Поскольку Shared tree от RP до last-hop router теперь находится в состоянии pruned , то теперь и RP более не нуждается в получении мультикаста от first-hop router . Поэтому RP отсылает (S, G) Prune message на first-hop router . Теперь трафик идет по оптимальному пути от first-hop router до last-hop router .
  Процесс перехода от пути_через_RP на прямой путь называется Shortest-Path Tree (SPT) Switchover .

Сравнивая PIM-DM и PIM-SM, можно сказать, что PIM-SM даёт тот же результат, что и PIM-DM, но без необходимости флудить и затем прунить (flood-and-prune behavior).

Глобально включаем multicast routing :
Router(config)# ip multicast-routing

Для проверки топологии дерева мы можем посмотреть multicast routing table :
show ip mroute
Здесь мы можем посмотреть (*, G) и (S, G) .
А также incoming interface (IIF) и outgoing interface list (OIL) .

Rendezvous Points

В сети PIM-SM один или более маршрутизатор должен быть выделенным rendezvous point (RP) .
RP задаётся либо статически через команду ip pim rp-address ip-address , либо динамически.
Cisco поддерживает два метода автоопределения RP:

Auto-RP - проприетарный цисковский метод
Bootstrap Router (BSR) - Стандартизированный метод

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

unicast — одноадресный, один источник потока один получатель
broadcast — широковещательный, один источник, получатели все клиенты в сети
multicast — многоадресный, один отправитель, получатели некоторая группа клиентов

Какой вид трафика использовать для 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.

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

MR1

MR2

MR1#sh run

Ip multicast-routing
!
interface Ethernet 0
description Multicast Source
ip address 10.0.0.1 255.255.255.0
ip pim sparse-mode
!
interface Ethernet 1
description Network A
ip address 10.1.0.1 255.255.255.0
ip pim sparse-mode
!
interface Ethernet 2
description Network B
ip address 10.2.0.1 255.255.255.0
ip pim sparse-mode
!
interface Ethernet 3
description Link to MR2
ip address 10.10.10.1 255.255.255.0
ip pim sparse-mode
!

!
ip access-list standard IPTV
permit 224.11.0.0 0.0.0.3

MR2#sh run

Ip multicast-routing
!
interface Ethernet 0
description Link to MR1
ip address 10.10.10.2 255.255.255.0
ip pim sparse-mode
!
interface Ethernet 1
description Network C
ip address 10.3.0.1 255.255.255.0
ip pim sparse-mode
!
ip pim rp-address 10.0.0.2 IPTV override
!
ip access-list standard IPTV
permit 224.11.0.0 0.0.0.3
!

Команда "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 ".

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

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

(10.0.0.2, 224.12.0.1), 00:03:52/00:02:50, flags: PT

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:

(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

В сетях IP существует 3 основных способа передачи данных : Unicast, Broadcast, Multicast.

Unicast (юникаст) – процесс отправки пакета от одного хоста к другому хосту.

Multicast (мультикаст) – процесс отправки пакета от одного хоста к некоторой ограниченной группе хостов.

Broadcast (бродкаст) – процесс отправки пакета от одного хоста ко всем хостам в сети.

Эти 3 типа передачи данных используются для различных целей, давайте рассмотрим более подробно.

Unicast

Тип передачи данных Unicast (индивидуальный) используется для обычной передачи данных от хоста к хосту. Способ Unicast работает в клиент-серверных и пиринговых (peer-to-peer, от равного к равному) сетях.

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

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

В IP сетях unicast адрес является адресом, то есть адресом конечного устройства (например, компьютера). Для типа передачи данных unicast, адреса хостов назначаются двум конечным устройствам и используются (эти адреса) как IP адрес источника и IP адрес получателя.

В течение процесса инкапсуляции передающий хост размещает свой IP адрес в заголовок unicast пакета в виде адреса источника, а ИП адрес принимающего хоста размещается в заголовке в виде адреса получателя. Используя эти два IP адреса, пакеты unicast могут передаваться через всю сеть (т.е. через все подсети).

Multicast

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

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

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

Multicast клиенты

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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