Что такое iptv в роутере. Ещё пара слов о других версиях IGMP. Какой вид трафика использовать для IPTVMulticastingInternet Group Management ProtocolMulticast AddressingDistribution TreesPIM-DM MechanicsRendezvous Points

Multicast routing

/etc/shorewall/rules

...
ACCEPT	net	fw:224.0.0.04
ACCEPT	net	loc:224.0.0.04
ACCEPT	fw	loc:224.0.0.04

Далее устанавливаем IGMPproxy:

• распаковываем:

  tar -xzf igmpproxy-src-*.tar.gz

• переходим в распакованный каталог
• компилируем IGMPproxy:

  .configure && make

• устанавливаем checkinstall:

  sudo apt-get install checkinstall

• запускаем checkinstall:

  sudo checkinstall -D -y --pkgname=igmpproxy --pkgversion=0.1

• в результате автоматически будет создан и установлен deb-пакет igmpproxy с необходимым нам демоном, который в будущем можно удалить командой

• перемещаем конфигурационный файл:

  sudo mv usrlocaletcigmpproxy.conf etcigmpproxy.conf

• настраиваем демон:

/etc/igmpproxy.conf

phyint eth1 upstream  ratelimit   threshold 1
	altnet 172.31.242.024
phyint eth0 downstream  ratelimit   threshold 1
phyint wlan0 disabled

• значение altnet можно узнать запустив демон в debug-режиме: и пощёлкав ТВ-каналы в VLC
• когда конфигурационный файл налажен, можно настроить автозапуск демона:

/etc/rc.local

usrlocalsbinigmpproxy etcigmpproxy.conf
exit 

всё, можно смотреть!

UDP proxy

В репозиториях Debian и Ubuntu программы udpxy ещё нет (разработчики занимаются этим вопросом), поэтому её нужно собрать из исходных кодов. Для этого:

• скачиваем архив с исходниками с официального сайта и компилируем

  sudo apt-get install build-essential
  wget "http://www.udpxy.com/download/1_23/udpxy.1.0.23-7-prod.tar.gz"
  tar -xvf udpxy.1.0.23-7-prod.tar.gz
  cd udpxy-1.0.23-7
  make

• копируем программу в системный каталог, например,

• в параметрах запуска указываем локальный интерфейс (в моём случае ), на котором будут приниматься подключения; порт, который будет прослушивать udpxy (у меня ) и имя внешнего интерфейса, откуда будет приниматься IPTV:

  usrlocalbinudpxy -a br0 -p 9999 -m eth1

• можно добавить программу в атозагрузку, например в

• добавим правила в брандмауэр (на примере ), разрешив multicast трафик из внешней сети на наш роутер и с роутера во внешнюю сеть, а также из локальной сети на порт udpxy:

  /etc/shorewall/rules

  ...
  ACCEPT          net             fw:224.0.0.04
  ACCEPT          fw              net:224.0.0.04
  ACCEPT          loc             fw                      tcp     9999

• изменим ссылки на каналы в плейлисте так, чтобы они указывали на udpxy:

  # change "udp://@233.166.172.91:1234" to \
  #  "http://192.168.0.254:9999/udp/233.166.172.91:1234"
  sed -e 's/^udp:\/\/\@/http:\/\/192.168.0.254:9999\/udp\//' -i playlist.m3u

• открываем на своём компьютере VLC и загружаем в него получившийся плейлист
• смотрим IPTV!

Описание протокола IGMP

В настоящий момент существует три версии этого протокола — IGMP v1 , IGMP v2 , IGMP v3 . Наиболее распространена версия 2.

формат IGMPv2 пакета:

Адрес группы представляет собой широковещательный IP-адрес, на который осуществляется рассылка контента. Например, 224.200.200.205.

В IGMPv2 существуют следующие типы сообщений:

• Запрос о составе группы.
• Отчет о составе группы.
• Сообщение о выходе из группы.

Рассмотрим назначение этих сообщений более детально.
При подключении к IGMP-группе абонентское устройство посылает в сеть IGMP пакет с типом «Отчет о составе группы», тем самым давая понять, что желает получать пакеты для данной группы.
При выходе из группы абонентское устройство посылает в сеть IGMP пакет с типом «Сообщение о выходе из группы».
Маршрутизатор (querier) периодически посылает в сеть IGMP запрос с типом «Запрос о составе группы» для выяснения состава группы на текущий момент времени. Если ответа от абонентских устройств не последовало, то маршрутизатор отключает эту группу и более не пересылает пакеты для данной группы.

Мультикаст на канальном уровне

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

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

Но ваш послеобеденный сон вдруг потревожил звонок техподдержки, потом ещё один и ещё — ничего не работает, всё сломалось. Проверяете — идут потери, разрывы. Всё сходится на одном сегменте из нескольких коммутаторов.

Расчехлили SSH, проверили CPU, проверили утилизацию интерфейсов и волосы дыбом — загрузка почти под 100% на всех интерфейсах одного VLAN’а. Петля! Но откуда ей взяться, если никаких работ не проводилось? Минут 10 проверки и вы заметили, что на восходящем интерфейсе к ядру у вас много входящего трафика, а на всех нисходящих к клиентам — исходящего. Для петли это тоже характерно, но как-то подозрительно: внедрили мультикаст, никаких работ по переключению не делали и скачок только в одном направлении.

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

Дотошное расследование показало, что компьютер клиента заражён и рассылает IGMP Query на все мультикастовые адреса подряд.

Потери пакетов начались, потому что коммутаторам пришлось пропускать через себя огромный объём трафика. Это вызвало переполнение буферов интерфейсов.

Главный вопрос — почему трафик одного клиента начал копироваться во все порты?

Причина этого кроется в природе мультикастовых MAC-адресов. Дело в том, пространство мультикастовых IP-адресов специальным образом отображается в пространство мультикастовых MAC-адресов. И загвоздка в том, что они никогда не будут использоваться в качестве MAC-адреса источника, а следовательно, не будут изучены коммутатором и занесены в таблицу MAC-адресов. А как поступает коммутатор с кадрами, адрес назначения которых не изучен? Он их рассылает во все порты. Что и произошло.

Это действие по умолчанию.

Multicast Flooding

Решение

Благодаря «IGMP snooping», утилита igmpproxy больше не должна создавать проблемы в беспроводных сетях. Теперь вы можете одновременно запускать обе утилиты igmpproxy и udpxy.

Проверьте, что поддержка «IGMP snooping» присутствует в вашей прошивке OpenWrt и включена!

Выполните команду:

# cat /sys/devices/virtual/net/br-lan/bridge/multicast_snooping

Если команда выдаст сообщение содержащие «», то прошивка скомпилирована без поддержки «IGMP snooping» и просмотр IPTV затормозит вашу беспроводную сеть.

Если файл существует, то вывод команды выдаст либо «», либо «». Если выдается «», то ничего делать не надо, а если «», то для включения «IGMP snooping» в файл , в конфигурации интерфейса «lan», необходимо добавить строку:

option igmp_snooping 1

IGMP proxy

Установка igmpproxy

Выполните команды устанавливающие igmpproxy:

# opkg update
# opkg install igmpproxy

После установки пакета, необходимо отредактировать файл конфигурации :

config igmpproxy
	option quickleave 1

config phyint
	option network wan
	option direction upstream
	list altnet 192.168.0.0/16
	list altnet 172.16.0.0/12
	list altnet 10.0.0.0/8
	
config phyint
	option network lan
	option direction downstream

config phyint
	option network loopback
	option direction disabled

Настройки Firewall

Вы так же должны разрешить IGMP для WAN интерфейса и перенаправить широковещательный трафик следующими правилами в файле :

config rule
	option name 'Allow-IGMP'
	option src 'wan'
	option proto 'igmp'
	option target 'ACCEPT'

config rule
	option name 'Allow-IPTV-IGMPPROXY'
	option src 'wan'
	option proto 'udp'
	option dest 'lan'
	option dest_ip '224.0.0.0/4'
	option target 'ACCEPT'

Запуск igmpproxy

После добавления правил, необходимо перезапустить фаервол, добавить igmpproxy в автостарт и естественно запустить сам igmpproxy. Выполните следующие команды:

# /etc/init.d/firewall restart
# /etc/init.d/igmpproxy enable
# /etc/init.d/igmpproxy start

В дальнейшем igmpproxy будет сразу стартовать автоматически в процессе загрузки роутера.

Проверка сервиса igmpproxy

# ps | grep igmp
 1900 root       952 S    /usr/sbin/igmpproxy /var/etc/igmpproxy.conf
 1941 root      1336 S    grep igmp
#

При отсутствии строки “/usr/sbin/igmpproxy /var/etc/igmpproxy.conf”, отладка сервиса из командной строки

# igmpproxy -d -vv /var/etc/igmpproxy.conf

В случае падений сервиса, можно добавить в cron команду

 */30 * * * * /usr/bin/pgrep igmpproxy || /etc/init.d/igmpproxy start 

Подсети провайдера из которых идет вещание

Для универсальности можно разрешить igmpproxy слушать все возможные адреса, прописав

config phyint
	option network wan
	option direction upstream
	list altnet 0.0.0.0/0

Однако в этом случае возможна нестабильность.

udpxy

Установка udpxy

Выполните команды устанавливающие udpxy:

# opkg update
# opkg install udpxy

Пример изменения стартового скрипта /etc/init.d/udpxy

#!/bin/sh /etc/rc.common

# To open multicast traffic, add the following rule at the end of
# /etc/config/firewall file:
#
# config 'rule'
#     option 'target' 'ACCEPT'
#     option '_name' 'multicast'
#     option 'src' 'wan'
#     option 'proto' 'all'
#     option 'dest_ip' '224.0.0.0/4'

START=99
STOP=10

SERVICE_DAEMONIZE=1
SERVICE_WRITE_PID=1

#OPTIONS="-T -S -p 4022"
OPTIONS="-T -S -m eth0.2 -p 4022 -B 2Mb -M 600"

start() {
	service_start /usr/bin/udpxy $OPTIONS
}

stop() {
	service_stop /usr/bin/udpxy
}

Настройки Firewall

Для того, чтобы udpxy мог работать с IGMP, вы должные добавить соответствующие правила в файл :

config rule
	option name 'Allow-IGMP'
	option src 'wan'
	option proto 'igmp'
	option target 'ACCEPT'

config rule
	option name 'Allow-IPTV-UDPXY'
	option src 'wan'
	option proto 'all'
	option dest_ip '224.0.0.0/4'
	option target 'ACCEPT'

Запуск udpxy

После добавления правил, необходимо перезапустить фаервол, добавить udpxy в автостарт и естественно запустить сам udpxy. Выполните следующие команды:

# /etc/init.d/firewall restart
# /etc/init.d/udpxy enable
# /etc/init.d/udpxy start

В дальнейшем udpxy будет сразу стартовать автоматически в процессе загрузки роутера.

Теперь когда вы захотите получить доступ, скажем, к , то вы должны указать своему проигрывателю соединиться с адресом . В данном примере, IP-адрес 192.168.1.1 является адресом вашего роутера в локальной сети.

Примечание по совместному использованию igmpproxy и udpxy

Если вы планируете использовать одновременно igmpproxy и udpxy, то в файле конфигурации фаервола – у вас в итоге должно быть два правила:

config rule
	option name 'Allow-IGMP'
	option src 'wan'
	option proto 'igmp'
	option target 'ACCEPT'

config rule
	option name 'Allow-IPTV-ALL'
	option src 'wan'
	option proto 'all'
	option dest_ip '224.0.0.0/4'
	option target 'ACCEPT'

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

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

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

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

Verification

Let’s verify our work. Let’s take a look at our UDL interface on R1 and R2:

Above, we see that the GigabitEthernet 0/2 interface is a UDL link and that we use unidirectional link multicast routing. It also tells us that the IGMP querier address is 192.168.1.254 (R1).

Both routers have to show the upstream router as the IGMP querier. This is where the downstream router proxies its IGMP membership reports to. Since I am using GigabitEthernet interfaces, I had to use an access-list on R1 to ensure that R1 became the IGMP querier. By default, the lowest IP address on a router defines which router becomes the IGMP querier.

To see the proxying in action, I’ll enable IGMP debugging on R1 and R2:

Now let’s join a multicast group on our receiver:

Here’s what we get on R2:

The debug on R2 is nice and clean. It shows us that it forwards the proxy report to our loopback interface and then sends a “helper report” for its UDL interface.

This proxied membership report is sent with unicast:

IGMP Proxy Membership Report

Let’s take a look at R1:

R1 has received the IGMP membership report from R2 and you can see that it adds an entry for (*,239.1.1.1) on its GigabitEthernet 0/2 interface. It also forwards the report down the UDL link, it does this so that all downstream routers (in case you have more than one) see the membership report, which suppresses unnecessary membership reports that are generated by downstream routers.

The debug output above is confusing. It looks like R1 receives the membership report from R2 on its GigabitEthernet 0/2 interface but this is not the case. When you do a Wireshark capture, you will see that R1 receives the membership report from R2 on its GigabitEthernet 0/3 interface, then forwards the membership report to its GigabitEthernet 0/2 interface. The GigabitEthernet 0/3 interface is never mentioned in the debug output.

You can use the show ip igmp groups command to see if R1 received the membership report:

R1 shows an entry for the 239.1.1.1 multicast group with its UDL link. R2 is our reporter. You can also use the show ip igmp udlr command:

The output of this command is similar. It shows up our UDL interface, the multicast group, and the reporter. You can see similar information from R2:

Let’s generate some traffic, and see what we get:

Приручаем multicast 7

• 07.11.18 01:53

•
catersplay
•
#429062
•
Хабрахабр

•

•

2600

Системное администрирование, Сетевые технологии, Блог компании ICL Services

Остановимся на анализе мультикаст-трафика через 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 позволяет выработать эффективную и оптимальную конфигурацию мультикаст-трафика в вашей сети.

Вы можете помочь и перевести немного средств на развитие сайта

Configuration

Let’s take a look at this in action. I’ll use the topology above but added some interface numbers:

R1 is our upstream router, R2 our downstream router. R1 uses PIM dense mode while R2 / R3 use PIM sparse mode. R2 has a loopback interface with IP address 2.2.2.2 that is used as the RP.

The GigabitEthernet 0/2 interface on R1 and R2 is our “unidirectional satellite link”.  The GigabitEthernet 0/3 interface is an Internet connection. I’ll use an inbound access-list on R1 which blocks all inbound traffic to simulate the satellite link.

First, we need to enable multicast routing on all routers:

R1 – Upstream Router

Let’s configure our upstream router. We need to enable PIM dense mode on all interfaces:

Let’s create the access-list on R1 so that all inbound traffic is denied:

We also need to enable PIM and configure the interface as unidirectional:

Last but not least, I’ll create a default route so that all traffic is forwarded through the unidirectional link:

That completes our configuration on the upstream router.

R2 – Downstream Router

Let’s work on the downstream router. I’ll enable PIM and we tell the router that this is the UDL link:

On the interface that connects to R3, we enable PIM and add the ip igmp mroute-proxy command:

This command enables forwarding of IGMP membership reports to a “proxy interface” (loopback 0) for all (*,G) forwarding entries that we have on our GigabitEthernet 0/1 interface.

Let’s configure that loopback interface:

Besides adding PIM, we use two important commands:

• ip pim proxy-service: this command enables the actual proxying of IGMP membership reports.
• ip igmp helper-address udl: this command tells the router to send IGMP membership reports to an upstream router that is connected on our UDL interface.

R2 is the RP in our network. Let’s configure it statically:

We also have to configure some routing. R2 needs to know how to reach the 192.168.1.0/24 for two reasons:

• I’d like my receiver to be able to reply to the ICMP requests that I’ll send from my source.
• R2 will forward IGMP membership reports to the IGMP querier, and as you’ll see in a bit, the IP address of the IGMP querier will be 192.168.1.254.

I’ll use a static route:

Between R2 and R3, let’s use OSPF so that R3 can reach the RP address (2.2.2.2) and the subnet of our source:

R3

We don’t require anything special on R3. Let’s enable PIM sparse mode on its interfaces:

And configure 2.2.2.2 as the RP address:

OSPF is used so that we can get to the RP address and the remote subnet of the source:

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