Андрей Смирнов
Время чтения: ~22 мин.
Просмотров: 2

Что такое igmp snooping в роутере

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

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

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

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

Example

Almost minimal setup where multicast routing is necessary:

  • multicast sender (server);
  • multicast receiver (client);
  • two routers running PIM between them.

Multicast traffic in this example will be destined to address 224.0.1.20

Traffic flow:

 Sender -- (subnet I) --> Router A -- (subnet II) --> Router B -- (subnet III) --> Receiver

Router A will be configured as Rendezvous Point.

Enable PIM and IGMP router A:

 > routing pim interface add interface=all
 > routing pim interface print
Flags: X - disabled, I - inactive, D - dynamic, R - designated-router,
v1 - IGMPv1, v2 - IGMPv2, v3 - IGMPv3
 #      INTERFACE    PROTOCOLS
 0   v2 all          pim
                     igmp
 1 DRv2 ether3       pim
                     igmp
 2 DR   register     pim

Configure static Rendezvous Point:

 > routing pim rp add address=<IP of router A>

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 the local router.

 > routing pim interface set <upstream-interface> alternative-subnets=1.2.3.0/24,2.3.4.0/24

Enable PIM and IGMP router B:

 > routing pim interface add interface=ether1
 > routing pim interface print
Flags: X - disabled, I - inactive, D - dynamic, R - designated-router,
v1 - IGMPv1, v2 - IGMPv2, v3 - IGMPv3
 #      INTERFACE    PROTOCOLS
 0  Rv2 ether1       pim
                     igmp
 1 DR   register     pim

Configure static Rendezvous Point:

 > routing pim rp add address=<IP of router A>

Add route on multicast sender:

# ip route add 224.0.1.20/32 via <IP of router A>

Start sender and receiver programs. You can either write simple programs yourself, or use any of these:

And hey, it works! Client should receive data now.

И ещё раз

IGMP
Протокол, с помощью которого маршрутизатор узнаёт о наличии получателей мультикастового трафика и об их отключении.
IGMP Report
Посылается клиентом при подключении и в ответ на IGMP Query. Означает, что клиент хочет получать трафик конкретной группы.
IGMP General Query
Посылается маршрутизатором периодически, чтобы проверить какие группы сейчас нужны. В качестве адреса получателя указывается 224.0.0.1.
IGMP Group Sepcific Query
Посылается маршрутизатором в ответ на сообщение Leave, чтобы узнать есть ли другие получатели в этой группе. В качестве адреса получателя указывается адрес мультикастовой группы.
IGMP Leave
Посылается клиентом, когда тот хочет покинуть группу.
Querier
Если в одном широковещательном сегменте несколько маршрутизаторов, который могут вещать, среди них выбирается один главный — Querier. Он и будет периодически рассылать Query и передавать трафик.

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 with L3 aware ASICs

To fix this issue, we need switches with special ASICs that are able to look into the frame and differentiate between IGMP and non-IGMP multicast traffic. Here’s what that would look like:

Above you can see the changes that were made to the CAM table:

  • The first entry tells the switch to forward all IGMP traffic with destination 0100.5exx.xxx to the internal interface. This allows the CPU to look at the different IGMP messages.
  • The second entry tells the switch to forward all non-IGMP traffic with destination 0100.5e01.0101 (group 239.1.1.1) to interface Gi0/1 and Gi0/4.

The switch will now intercept all IGMP messages, they are only sent to the internal interface which puts our switch in total control of all IGMP traffic.

IGMP Group Leave

Let’s continue the story, let’s say that H1 and H2 are listening to multicast group 239.1.1.1. Suddenly, H1 is no longer interested so it will send a leave group message:

Leave group messages are always sent to multicast group 224.0.0.2 using destination MAC address 0100.5e00.0002. When the switch receives the IGMP leave, it will forward it on the internal interface to the CPU.

In response, the switch will send an IGMP general query on the interface that connects to H1:

The IGMP general query is only sent on the Gi0/1 interface and we do this to check if there are any other hosts that are interested in multicast group 239.1.1.1 on this interface. There are two possible outcomes:

  • If another host was connected to the Gi0/1 interface which was still interested in receiving traffic for 239.1.1.1 then the switch would just get rid of the group leave message, nothing will change.
  • When the switch doesn’t receive a membership report then the CPU will remove the Gi0/1 interface from the CAM table. Since we still have a second listener (H2), the switch will not forward the leave group message to the router.

Here’s what the CAM table looks like now:

Above you can see that interface Gi0/1 has been removed from the CAM table. No messages have been forwarded to the router.

A few minutes later, H2 decides that it also wants to leave multicast group 239.1.1.1 so it will send an IGMP leave group message:

Above you can see the switch receives the IGMP leave group from H2 which is forwarded to the CPU. Here’s what happens next:

Что такое и зачем нужна функция IGMP snooping

Для начала дадим определение IGMP, чтобы понять принцип работы технологии. Internet Group Management Protocol – протокол управления сетью мультивещания, который организует несколько устройств в группы. Он основан на протоколе IP и применяется в интернете повсеместно, эффективно используя ресурсы сети.

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

Таким образом snooping исключает передачу пользователю ненужных данных через multicast каналы

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

Без отслеживания и анализа данных, конечные потребители в виде конкретных IP-адресов, будут вынуждены «переваривать» дополнительную бесполезную для них информацию. IGMP snooping не только избавит пользователей от лишнего трафика, но и сделает обмен информацией более безопасным. Включенный режим отслеживания вовремя пресечёт попытки DDoS-атаки на сеть или конкретные адреса, к которым уязвим протокол Internet Group Management.

Реализация

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

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

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

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

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

bcastdvr.exe — это вирус?

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

Откройте Диспетчер задач, затем перейдите на вкладку Подробности. Найдите в списке процессов bcastdvr.exe и нажмите по нему правой кнопкой мыши. Выберите Открыть расположение файла.

Файл bcastdvr.exe должен быть расположен в папке C:\Windows\System32. Если открылось другое место, значит есть смысл предполагать, что что-то пошло не так и bcastdvr.exe является не тем, за кого он себя выдает. В таком случае проверьте свой компьютер на вирусы при помощи доступных вам средств.

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

Если местоположение bcastdvr.exe правильно и его подпись не вызывает подозрений, тогда можно смело заявить, что этот файл не является вирусом.

Реализация

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

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

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

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

Multicast Routing Overview

IP Multicast is a technology that allows one-to-many and many-to-many distribution of data on the Internet. Senders send their data to a multicast IP destination address, and receives express an interest in receiving traffic destined for such an address. The network then figures out how to get the data from senders to receivers.

If both the sender and receiver for a multicast group are on the same local broadcast subnet, then the routers do not need to be involved in the process, and communication can take place directly. If, however, the sender and receiver are on different subnets, then a multicast routing protocol needs to be involved in setting up multicast forwarding state on the tree between the sender and the receivers.

MikroTik supports PIM-SM multicast routing protocol. PIM means «platform independent multicast» — i.e. this protocol is not tied to any particular unicast routing IGP. SM means «sparse-mode»; as opposed to dense-mode, in sparse-mode protocols explicit control messages are used to ensure that traffic is only delivered to the subnets where there are receivers that requested to receive it.

In addition to the routing protocols used to set up forwarding state between subnets, a way is needed for the routers to discover that there are local receivers on a directly attached subnet. For IPv4 this role is served by the Internet Group Management Protocol (IGMP).

Service Models: ASM vs SSM

There are two different models for IP multicast:

  • Any Source Multicast (ASM), in which a receiver joins a multicast group, and receives traffic from any senders that send to that group.
  • Source-Specific Multicast (SSM), in which a receiver explicitly joins to a (source, group) pairing.

Multicast Addressing

For IPv4, multicast addresses are in the range 224.0.0.0 to 239.255.255.255 inclusive.
Addresses within 232.0.0.0/8 are reserved for SSM usage.
Addresses in 239.0.0.0/8 are ASM addresses defined for varying sizes of limited scope.
Addresses within 224.0.0.0/24 are considered link-local and are not forwarded between subnets. Mostly these addresses are used by applications that do not require communication to other networks. Here are some assigned hostgroup addresses by the internet assigned numbers authority (IANA):

  • 224.0.0.1 — All systems on the subnet
  • 224.0.0.2 — All routers on the subnet
  • 224.0.0.9 — For RIPv2
  • 224.0.0.14 — For VRRP
  • 224.0.1.1 — Network time protocol (NTP)

The internet assigned numbers authority (IANA) allocates ethernet addresses from 01:00:5E:00:00:00 through 01:00:5E:7F:FF:FF for multicasting, therefore leaving only 23 bits available for the multicast group ID.

IGMP snooping without L3 aware ASICs

We will start with a simple example. I’ll use the following diagram for this:

Above we have a multicast enabled router, a switch and three host devices. Our switch has a CPU and a CAM table (mac address table) which is connected to an internal interface that I will call “INT”. We are using a cheap budget switch that is only able to look at layer two Ethernet frames. It does have support for IGMP snooping though. Let’s see what happens when we enable IGMP snooping on this switch:

Above you can see that one of our hosts (H1) sends a membership report for multicast group 239.1.1.1 that it wants to join. Our switch has no idea where to forward this to so the first time it will flood it on all interfaces, including the internal interface to the CPU. The CPU will take a closer look at the membership report and will create an entry in the CAM table:

In the CAM table above you can see an entry for MAC address 0100.5e01.0101 which corresponds with multicast group 239.1.1.1. The interfaces that were added are for H1, R1 and the internal interface. Why did the switch add the interface of the router in the CAM table?

Once IGMP snooping is enabled, the switch will detect multicast enabled routers and it does so by listening to the following messages:

  • IGMP General Query (0100.5e00.0001)
  • OSPF (0100.5e00.0005 and 0100.5e00.0006)
  • PIM version 1 and HSRP (0100.5e00.0006)
  • PIM version 2 (0100.5e00.000d)
  • DVMRP (0100.5e00.0004)

When the switch detects a multicast enabled router then it will add the corresponding entry in the CAM table.

From now on, all multicast traffic that has destination MAC address 0100.5e01.0101 will only be forwarded on interface Gi0/1, Gi0/4 and the internal interface to the CPU.

It sounds like we did a good job constraining our multicast traffic but we still have one problem. Here’s what happens when one of our devices starts streaming multicast traffic:

In the example above we see that R1 is sending 10 Mbps of multicast traffic which is forwarded to H1 and the CPU. Our CPU is unable to process 10 Mbps of traffic so it will choke on it…when this occurs, there’s a couple of things that could occur:

  • The switch will start dropping unicast and multicast traffic.
  • The CPU might be able to drop exceeding multicast traffic but that could also include IGMP membership reports and IGMP group leave messages.

The issue above is common with cheap switches that support IGMP snooping. It might work with low bandwidth multicast traffic but that’s about it.

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

Multicast and Wireless

Multicast (and broadcast) over wireless works over wireless depending on who is transmitting multicast packet:

If AP transmits multicast packet, packet is transmitted over air with multicast receiver address (and yes — only single copy of packet is transmitted no matter how many clients are registered). As there is no single recipient of packet, it does not get acked — therefore delivery is not reliable (no retransmissions in case somebody does not receive packet). Due to this unreliable delivery, lowest basic rate is used to ensure as reliable delivery as possible. So even if you can send unicast stream between AP and Station using 54Mpbs air rate, multicasts are sent only using 6Mbps air rate (assuming that 6Mbps is lowest basic rate).

If Station transmits multicast packet, it is transmitted over air with unicast AP receiver address (as Stations always transmit all packets to AP, and always using unicast receiver address). Due to this, delivery of multicast packets from Station to AP is reliable and subject to normal rate selection process — max throughput can be used. What complicates the matter — when AP receives multicast packet from Station, it processes it locally, but it also must send it back over the air so that the rest of stations in wireless network see it (think of AP as switch in ethernet, except that is does not have to send multiple copies of packet for all clients to receive). This causes AP to execute multicast transmission procedure as described above, therefore every multicast packet gets transmitted over air twice — first time by Station (using its transmit rate) and second time — by AP using lowest basic rate. This behaviour can be altered by disabling «forwarding» option for particular Station on AP (or for all clients using «default-forwarding» option) — disabling forwarding causes AP not to forward traffic between clients and also disables «sending back» multicasts and broadcasts received from client, because that can be considered special case of forwarding traffic between clients.

If multicast traffic is forwarded across WDS link, it is transmitted over air with unicast receiver address (remote end of WDS link) and therefore is reliable and subject to normal rate selection.

From above we can draw some conclusions, how to increase wireless network throughput:

  • Ensure that unicast receiver address is used when transmitting multicast
  • Increase lowest basic rate if feasible.

Some ideas on how to apply above conclusions:

  • In case multicast traffic is to be delivered over point-to-point link (e.g. some backbone link), you should ensure by some means that multicasts are delivered over wireless using unicast receiver address. This can be achieved by using tunnels (as previously discussed) or by using WDS links (either AP-to-AP WDS or AP-to-StationWDS WDS link). If WDS links are used, care must be taken not to inject multicasts in regular wireless interface (to avoid regular AP multicast transmission procedure).
  • In case WDS can not be used, network should be planned so that Station is transmitting multicasts and AP should have forwarding disabled.
  • In case multicasts are to be delivered to multiple destinations in wireless network, it is best to organize network such that AP is transmitting multicasts (because AP will transmit just one copy) and increase lowest basic rate, if throughput is not enough.

Note: Starting from v5.15 it is possible to enable multicast-mode on the access point. This mode uses unicast receiver MAC address to forward multicast traffic, similar as in case of WDS. On the AP set multicast-helper=enabled and on the station set mode=station-bridge

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

Использование виртуальных машин

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

В своей статье про мультикаст я использовал третий способ, но на деле, если хочется отработать детали, то вполне можно обойтись и маршрутизаторами, учитывая, что правильно выбрано значение IDLE PC.

Теперь вы укомплектованы необходимым инструментарием, чтобы приступить к лабам по мультикасту.

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

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

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

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

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

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

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

Рейтинг автора
5
Материал подготовил
Максим Иванов
Наш эксперт
Написано статей
129
Ссылка на основную публикацию
Похожие публикации