Оптимизация передачи multicast-трафика в локальной сети с помощью IGMP snooping

Настройка прохождения IPTV через шлюз CentOS и утилиты igmpproxy.

Основным механизмом доставки телевизионных программ до абонентов в локальных сетях является вещание в виде широковещательных IP-пакетов (иногда такой поток называют «мультикаст» от английского «multicast»). Особенностью данной технологии является то, что все мультимедийные потоки всегда направляются в сеть, вне зависимости от количества активных подписчиков в настоящий момент времени. Например, для передачи 20 телевизионных каналов со средним битрейтом 4 Мбит/сек на канал потребует порядка 4*20 = 80 Мбит/сек пропускной способности. Эти 80 Мбит/сек будут направляться в сеть, даже если ни один абонент в данный момент не подключен к сети, а также в случае, если количество активных абонентов гораздо более 1000.Вещание мультимедийного контента в локальную сеть в виде широковещательных пакетов сопряжено с необходимостью четко контролировать какие пакеты и к какому получателю должны доставляться. Необходимо избегать ситуации, когда все пакеты доставляются всем абонентам. В этом случае абонентские устройства будут тратить ресурсы на обработку «непрошенных» пакетов и в итоге не смогут выполнять свои функции. Абоненту необходимо доставлять пакеты только того потока, который он запросил. Для этого абонентское оборудование сообщает о желании вступить в определенную группу по протоколу IGMP. Далее этот запрос регистрируется на маршрутизаторе, в терминах IGMP это устройство называется «Querier». После успешной регистрации, Ethernet коммутатор приступает к копированию широковещательных пакетов, предназначенных для данной группы, в порт, к которому подключен абонент.Благодаря протоколу IGMP, Ethernet-коммутаторы могут определить какие широковещательные пакеты копировать в абонентский порт, а какие нет.В настоящей статье описывается настройка протокола IGMP для просмотра пакета IPTV через шлюз под управлением CentOS.

На шлюзе две сетевые карты.

eth0 - провайдер.
eth1 - локальная сеть.
ppp0 - интернет, привязан на eth0.

Для начала прописываем правила в iptables. В файл /etc/sysconfig/iptables, добавляем:

секция *filter:
-A FORWARD -p igmp -i eth0 -o eth2 -j ACCEPT
-A INPUT -d 224.0.0.04 -j ACCEPT
-A FORWARD -d 224.0.0.04 -j ACCEPT
 
секция *mangle:
-A PREROUTING -d 224.0.0.0240.0.0.0 -p udp -j TTL --ttl-inc 1

Выполняем:

modprobe ipt_TTL
service iptables reload
service iptables restart
 
route add -net 224.0.0.04 dev eth0
route add -net 224.0.0.04 dev eth2

Добавляем в файл /etc/rc.d/rc.local:

route add -net 224.0.0.04 dev eth0
route add -net 224.0.0.04 dev eth2

Теперь необходимо установить утилиту igmpproxy, которая и будет транслировать IPTV в локальную сеть.

Её можно собрать из исходников производителя, либо скачать собранный пакет.

wget http://centos.alt.rupubrepositorycentos6x86_64igmpproxy-0.1-1.el6.x86_64.rpm
rpm -i igmpproxy-0.1-1.el6.x86_64.rpm

или же подключить репозитарий CentALT

rpm -ivh http://centos.alt.rurepositorycentos6x86_64centalt-release-6-1.noarch.rpm

и установить

yum install igmpproxy

Запускаем в режиме дебага:

usrsbinigmpproxy -vd etcigmpproxy.conf

Находим примерную строку:

The source address 172.18.3.1 for group 224.0.42.1, is not in any valid net for upstream VIF

По ней определяем, что поток идет с IP 172.18.3.1

Открываем конфиг /etc/igmpproxy.conf:

в секцию phyint eth0 upstream ratelimit 0 threshold 1 добавляем подсеть транслятор:

altnet 172.18.3.1

в секцию phyint eth2 downstream ratelimit 0 threshold 1 можно ничего не добавлять, это локальная сеть.

Конфиг будет иметь вид:

##------------------------------------------------------
## Enable Quickleave mode (Sends Leave instantly)
##------------------------------------------------------
quickleave
 
##------------------------------------------------------
## Configuration for eth0 (Upstream Interface)
##------------------------------------------------------
phyint eth0 upstream ratelimit  threshold 1
altnet 172.18.3.1
 
##------------------------------------------------------
## Configuration for eth1 (Downstream Interface)
##------------------------------------------------------
phyint eth1 downstream ratelimit  threshold 1
 
##------------------------------------------------------
## Configuration for eth2 (Disabled Interface)
##------------------------------------------------------
phyint ppp0 disabled

Теперь можно смотреть IPTV, запускаем:

usrsbinigmpproxy etcigmpproxy.conf&

Для автозапуска добавляем строку в файл /etc/rc.d/rc.local:

usrsbinigmpproxy etcigmpproxy.conf&

Проверено и работает: IpTvPlayer, провайдер ISTV.

Understanding IGMP Proxy

The purpose of IGMP proxy is to enable a multicast router to learn multicast group membership information and be able to forward multicast packets based upon the group membership information. The IGMP Proxy is capable of functioning only in certain topologies that does not require Multicast Routing Protocols (i.e. DVMRP, PIM-DM, and PIM-SM) and have a tree-like topology, as there is no support for features like spanning tree to correct packet route loops.

The proxy contains many downstream interfaces and a unique upstream interface explicitly configured. It performs the host side of the IGMP protocol on its upstream interface and the router side of the IGMP protocol on its downstream interfaces.

The IGMP proxy offers a mechanism for multicast forwarding based only upon IGMP membership information. The router has to decide about forwarding packets on each of its interfaces based on the IGMP membership information. The proxy creates the forwarding entries based on the membership information and adds it to the multicast forwarding cache (MFC) in order not to make the forwarding decision for subsequent multicast packets with same combination of source and group.

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

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

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

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

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

Purpose

A switch will, by default, multicast traffic to all the ports in a (or the equivalent). Multicast can cause unnecessary load on host devices by requiring them to process packets they have not solicited. When purposefully exploited, this can form the basis of a . IGMP snooping is designed to prevent hosts on a local network from receiving traffic for a multicast group they have not explicitly joined. It provides switches with a mechanism to prune multicast traffic from links that do not contain a multicast listener (an IGMP client).

Essentially, IGMP snooping is a layer 2 optimization for the layer 3 IGMP. IGMP snooping takes place internally on switches and is not a protocol feature.

IGMP snooping allows a switch to only forward multicast traffic to the links that have solicited them. Snooping is therefore especially useful for bandwidth-intensive IP multicast applications such as .

Implementations options

IGMP querier

In order for IGMP, and thus IGMP snooping, to function, a multicast router must exist on the network and generate IGMP queries. Without a querier IGMP membership reporting may be incomplete and the tables associating member ports and multicast groups are potentially incomplete and snooping will not work reliably. Some IGMP snooping implementations include full querier capability.

IGMPv2 and IGMPv3 contain provision for selecting a querier when multiple are available. The querier with the lowest IP address is given the role.

IGMP general queries from the querier must be unconditionally forwarded by all switches involved in IGMP snooping.

Proxy reporting

IGMP snooping with proxy reporting or report suppression actively filters IGMP packets in order to reduce load on the multicast router. Joins and leaves heading upstream to the router are filtered so that only the minimal quantity of information is sent. The switch is trying to ensure the router only has a single report for the group, regardless of how many active listeners there are. If there are two active listeners in a group and the first one leaves, then the switch determines that the router does not need this information since it does not affect the status of the group from the router’s point of view. The next time there is a routine query from the router the switch will forward the reply from the remaining host. In the presence of proxy reporting, the router will generally only know about the most recently joined member of the group.