Igmp

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

• Дополнительно: Микровыпуск СДСМ. Подготовка лаборатории для работы с мультикаст в GNS3

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

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

В итоге до полудня мы пытались всё это дело запустить — я пробросил самый обычный VLAN от точки входа до точки выхода. Но сигнал был нестабильным — картинка замерзала, разваливалась, прерывалась. Я в панике пытался разобраться, что вообще можно сделать с IGMP, тыркался, тыркался, включал мультикаст роутинг, IGMP Snooping, проверял по тысяче раз задержки и потери — ничего не помогало. А потом вдруг всё заработало. Само собой, стабильно, безотказно.

Это послужило мне прививкой против мультикаста, и долгое время я не проявлял к нему никакого интереса.

Уже гораздо позже я пришёл в к следующему правилу:

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

Сохраняйте спокойствие и доверьтесь мне. После этой статьи такие вещи вас пугать не будут.

Example

To forward all multicast data coming from ether1 interface to all other interfaces, where subscribers are connected:

 /routing igmp-proxy> interface add interface=ether1 upstream=yes
 /routing igmp-proxy> interface add interface=all
 /routing igmp-proxy> interface print
Flags: X - disabled, I - inactive, D - dynamic, U - upstream
 #    INTERFACE                                                             THRESHOLD
 0  U ether1                                                                1
 1    all                                                                   1
 2 D  ether2                                                                1
 3 D  ether3                                                                1

You may also need to configure alternative-subnets on upstream interface — in case if the multicast sender address is in an IP subnet that is not directly reachable from from the local router.

 /routing igmp-proxy> interface set  \
 alternative-subnets=1.2.3.0/24,2.3.4.0/24

/routing igmp-proxy interface

Used to configure what interfaces will participate as IGMP proxy interfaces on router. If an interface is not configured as IGMP proxy interface, then all IGMP traffic received on it will be ignored.

• alternative-subnets (list of IP prefixes) : by default, only packets from directly attached subnets are accepted. This parameter can be used to specify a list of alternative valid packet source subnets, both for data or IGMP packets. Has effect only on upstream interface. Should be used when the source of multicast data often is in a different IP network.
• interface (interface name) : RouterOS interface
• threshold (integer) : minimal TTL; packets received with a lower TTL value are ignored
• upstream (yes|no) : interface is called «upstream» if it’s in the direction of the root of the multicast tree. An IGMP forwarding router must have exactly one upstream interface configured. The upstream interface is used to sent out IGMP membership requests.

Examples

IGMP-proxy

Will forward stream unconditionally if it comes in from ether1 with set source and will be sent out to ether2, clients that will try to get stream on interface ether3 will not receive that stream.

/routing igmp-proxy interface add comment="" disabled=no interface=ether1 threshold=1 upstream=yes
/routing igmp-proxy interface add comment="" disabled=no interface=ether2 threshold=1
/routing igmp-proxy interface add comment="" disabled=no interface=ether3 threshold=1
/routing igmp-proxy mfc add source=192.168.0.1 upstream-interface=ether1 \
downstream-interface=ether2 group=224.10.10.11 disabled=no

MFC static entry

224.10.10.10 group will not be sent at all

/routing igmp-proxy mfc add source=192.168.0.1 upstream-interface=ether1 \
group=224.10.10.11 disabled=no

Реализация

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

Операционные системы семейств BSD, Linux и Windows поддерживают клиентскую часть протокола. В системе Linux IGMPv3 был добавлен в версии ядра 2.5. Для FreeBSD IGMPv3 был добавлен в версии 8.0.

Для реализации серверной части IGMP в Linux используются демоны, например, mrouted может действовать как IGMP маршрутизатор. Существуют также целые программные комплексы (такие, как XORP), позволяющие превратить обычный компьютер в полнофункциональный маршрутизатор групповой передачи.

В OpenBSD поддержка IGMP в ядре изначально включает в себя базовую поддержку маршрутизации, а имеющиеся в составе ОС демоны mrouted и dvmrpd позволяют решать более сложные задачи (например, туннелирование multicast-трафика).

IGMPv1 –

It was the first IGMP version that allowed to explicitly announce its willingness to receive particular multicast traffic. This version had two messages only:

The Membership Query was always sent to 224.0.0.1 by multicast routers, and the Membership Report was always sent by stations to the group that a station wanted to join.

Advertisements

There was no message to announce that a station is leaving (unsubscribing) a multicast group, resulting in situations that multicast stream was fed to a segment even after all stations have left the particular group.

Only after a timeout period the router discovered that there are no more subscribers to the group, and stopped the multicast feed.

Каковы функции и приложения IGMP Snooping?

Как упоминалось ранее, два основных преимущества коммутатора IGMP Snooping — это предотвращение потери пропускной способности и утечки сетевой информации.

Multicast Snooping помогает сетевым коммутаторам поддерживающим IGMP Snooping, и маршрутизаторам эффективно передавать многоадресные пакеты данных назначенным получателям. Его важные значения становятся более понятными, когда отсутствует метод фильтрации многоточечной передачи: входящие многоадресные пакеты транслируются всем хостам в широковещательном домене. Особенно в больших сетях коммутатор IGMP Snooping уменьшает чрезмерно высокий трафик, который может даже привести к перегрузке сети. Преступники могут воспользоваться этой безопасной утечкой и залить отдельные хосты или всю сеть многоадресными пакетами, чтобы сломать их, как при обычной DoS / DDoS-атаке.

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

IGMPv2 –

The next version of IGMP among other IGMP versions had some enhancement –

1. Membership Query was of both types i.e. general (sent to 224.0.0.1) and group-specific (sent to a particular multicast group). The general Membership Query is used to find out all multicast groups that the stations are subscribed to. The group-specific Membership Query is used to find out if there is a subscriber for a particular group.
2. Leave a message (A new message )to advertise that a station is unsubscribing from a multicast group, allowing the router to stop an unnecessary multicast stream feed much more promptly.
3. IGMPv2 cleared the way how a multicast querier (a router that sends Queries) is elected if there are multiple multicast routers connected to a common network. In IGMPv1, all multicast routers were expected to send Queries. The IGMPv2 stipulates that only the multicast router with the lowest IP address on the segment shall become the Querier and send Queries. Other routers are free to listen to the Replies (they have to do it anyway) but they do not send Queries themselves.

Static multicast forwarding cache (MFC) entries

Since RouterOS 4.5 MFC is enabled to add static multicast forwarding rules. If a static rule is added, all dynamic rules for that group will be ignored.

Configuration

These rules will take effect only if IGMP-proxy interfaces are configured (upstream and downstram interfaces should be set) or these rules wont be active.

• downstream-interfaces (list of interfaces) : received stream will be sent out to listed interfaces only.
• group (multicast group address) : multicast stream group address this rule applies should be set
• source (IP address) : IP address we are receiving stream from should be set
• upstream-interface (interface) : interface that is receiving stream data should be set

IGMP Snooping Proxy

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

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

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

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

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

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

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

Как работает IGMP Snooping?

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

IGMP Snooping

IGMP Snooping решает эту проблему. Как показано на рисунке выше, когда IGMP Snooping не выполняется на коммутаторе, многоадресные пакеты передаются на Хост A, B, C. Но когда IGMP Snooping включено, коммутатор Snooping IGMP может прослушивать и анализировать сообщение IGMP и устанавливать Записи многоадресной пересылки уровня 2 для управления пересылкой многоадресных данных. Таким образом, пакеты многоадресной рассылки являются только членами групп многоадресной рассылки для получателей A и C, а не шировещательными всем узлам.

IGMP Snooping

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

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

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

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

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

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

IGMP Snooping

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

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

Задача № 3

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

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

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

R1

R2

R3

R4

R5

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.