Глава 2. Multicast, IGMP: различия между версиями

Материал из Juniper Exam Wiki
Перейти к навигации Перейти к поиску
(Новая страница: «== Общее == Мультикаст = поток UDP на определенные адреса. == Адресация == - 224/8 - local network control blo…»)
 
м
 
(не показаны 33 промежуточные версии этого же участника)
Строка 1: Строка 1:
{{#description2: multicast адресация. Routing tables junos. IGMP сообщения. IGMPv2. IGMPv3. Конфигурация IGMP. Траблшутинг IGMP.Информация для подготовки к экзаменам Juniper.}}
== Общее ==
== Общее ==


Строка 5: Строка 7:
== Адресация ==
== Адресация ==


- 224/8 - local network control block
- 224/24 - local network control block [разничные протоколы маршрутизации, использующие мультикаст: OSPF, rip, igmp, ldp ...]
 
- 224.2.0.0/16 - SDP/SAP, адреса, использующиеся для передачи multicast session.


- 232/8 - под SSM
- 232/8 - под SSM
Строка 13: Строка 17:
- 234/8 - unicast-prefix-based IPv4
- 234/8 - unicast-prefix-based IPv4


- 239/8 - administratively scoped block || это адреса, которые могут быть использованы в разных частях сети. Они уникальные только в определенных областях сети.
- 239/8 - administratively scoped block || это адреса, которые могут быть использованы в разных частях сети. Тоже самое, что и private IP.


== Multicast IP => multicast mac ==
== Multicast IP => multicast mac ==
Если не заморачиваться почему так, то правило перевода простое:


Если не заморачиваться почему так, то правило перевода такое простое:
Конвертируем последние 23 бита IP в десятичную систему счисления.  
 
*224.10.8.5: 0001010.00001000.00000101 => 0a.08.05
Конвертируем последние 23 бита IP в 10-ую системе счисления. 224.10.8.5: 0001010.00001000.00000101 => 0a.08.05


Прибавляем к 01-00-5e переведенное значение: 01-00-5e + 0a-08-05 = 01-00-5e-0a-08-05
Прибавляем к "01-00-5e" переведенное значение.
*01-00-5e + 0a-08-05 = 01-00-5e-0a-08-05


Проблема в том, что для разных мультикаст-групп (адресов) - мак-адреса будут пересекаться, т.к. не учитываются первые биты ip-адреса.
Проблема в том, что для разных мультикаст-групп (адресов) - мак-адреса будут пересекаться, т.к. не учитываются первые биты ip-адреса.


== Multicast forwarding ==
== Multicast forwarding ==
*'''unicast forwarding''' основан на '''dest ip'''.
*'''multicast forwarding''' основан на '''source ip'''.


unicast forwarding основан на dest ip.
Предотвращение петель:
 
*RPF-check для источника: сравнивается с какого интерфейса фактически пришел мультикаст пакет с тем, откуда по unicast table пакет должен приходить (источник или RP). Если сходится - RPF done, не сходится - RPF fail. Префиксы, прошедшие RPF-check хранятся в inet.1.
multicast forwarding основан на source ip.
*Multicast трафик никогда не форвардится в сторону источника.
 
RPF-check для источника: сравнивается с какого интерфейса фактически пришел мультикаст пакет с тем, откуда по unicast table пакет должен приходить (от источника). Если одинаков - rpf done, разные - fail. То, что прошло RPF-check хранится в inet.1.


  show multicast rpf ''<group ip>''
  show multicast rpf ''<group ip>''
Строка 37: Строка 42:
=== Routing tables ===
=== Routing tables ===


'''inet.0''' - для проведения RPF-check. Если unicast и multicast топологии одинаковые, то inet.0 и inet.2 будут одинаковы.
'''inet.0''' - дефолтная таблица для проведения RPF-check [можно использовать inet.2, которая для этого и предназначена]. Если unicast и multicast топологии одинаковые, то inet.0 и inet.2 будут одинаковы.


'''inet.1''' - для сохранения результатов RPF-check для передачи трафика.
'''inet.1''' - записываются результаты RPF-check, форвардинг производится на основании этой таблицы.
>show route table inet.1 
inet.1: 238 destinations, 238 routes (238 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
224.0.0.0/4        *[Multicast/180] 74w2d 13:10:11
                      MultiResolve
224.0.0.0/24      *[Multicast/180] 74w2d 13:10:11
                      MultiDiscard
232.0.0.0/8        *[Multicast/180] 74w2d 13:10:11
                      MultiResolve
232.192.1.1,10.200.86.1/32*[PIM/105] 6w0d 08:32:53
                      Multicast (IPv4) Composite
232.192.1.1,10.200.86.2/32*[PIM/105] 8w3d 15:25:48
                      Multicast (IPv4) Composite
232.192.1.2,10.200.86.1/32*[PIM/105] 6w0d 08:32:52
                      Multicast (IPv4) Composite
232.192.1.2,10.200.86.2/32*[PIM/105] 8w3d 15:25:52
                      Multicast (IPv4) Composite
232.192.1.4,10.200.86.1/32*[PIM/105] 23:11:56
                      Multicast (IPv4) Composite
...


'''inet.2''' - если для multicast на сети должна быть использована другая топология, то используем эту таблицу. inet.2 в таком случае будет использоваться для RPF-check. MP-BGP и multitopology IS-IS могут напрямую заполнять маршрутной информацией inet.2. Все остальные протоколы должны использовать RIB-groups (копирование маршрутов из одной таблицы в другую).
'''Detailed'''
232.192.1.1.10.200.86.1/64 (1 entry, 1 announced)
        *PIM    Preference: 105       
                Next hop type: Multicast (IPv4) Composite, Next hop index: 1048796
                Address: 0xa4edf30
                Next-hop reference count: 28
                State: <Active Int Ext AckRequest>
                Local AS: 100
                Age: 6w0d 8:35:30
                Validation State: unverified
                Task: PIM.master
                Announcement bits (1): 0-KRT
                AS path: I
                AS path: Recorded
'''inet.2''' - если для multicast на сети должна быть использована другая топология, то используем эту таблицу. inet.2 в таком случае будет использоваться для RPF-check.


== IGMP ==
MP-BGP и multitopology IS-IS могут напрямую заполнять маршрутной информацией inet.2.
''Internet group management protocol''


IGMP не протокол маршрутизации. Работает между получателями и роутером, с которого отдается мультикаст в сегменте. Он просто передает информацию роутеру о заинтересованных получателях и получателях, которые хотят покинуть группу.
Чтобы ISIS стал заполнять inet.2 - нужно включить
set protocols isis topologies ipv4-multicast
Все остальные протоколы для заполнения таблицы должны заниматься копированием в inet.2 маршрутов с помощью '''RIB-groups'''.


Для IPv6 используется точно такой же по принципу работы протокол MLD.
'''IMPORT-RIB''': для протокола PIM import-rib копирует маршруты из протокола в указанную таблицу. То есть указываем только одну таблицу. Указанная таблица будет использоваться для RPF.


'''Report/Join message''': отправляет хост, когда хочет подписаться на какую-то группу.  DA = group address. После того как хост подписался на группу, он должен отвечать на query message от роутера. TTL = 1, т.к. сообщение должно долететь только до ближайшего маршрутизатора.
Для остальных протоколов первая таблица <> - откуда копируются маршруты, вторая <to-inet2> - куда копируются.


'''General query''':  роутер шлет general query на 224.0.0.1 всем хотсам (роутер при этом называется query-router (порашивающий)). Хосты в ответ присылают группы, на которые они еще хотят быть подписаны. TTL тоже = 1.
set routing-options rib-groups mcast-table import-rib inet.2
set protocols pim rib-group inet mcast-table


Чтобы не дублировались ответы с одной группой от разных хостов, хосты шлют ответы с разным временным интервалом. Если хост видит, что о его группе сообщил другой хост, то он не будет отправлять ответ роутеру. Роутер итак сохранит интерфейс как downstream для данной группы.
set routing-options rib-groups import-rib to-inet2 [inet.0 inet.2]
set routing-options rib-groups import-policy static *''по желанию/необходимости''
set protocols ospf rib-groups to-inet.2
set routing-options interface-routes rib-group inet to-inet2


Если в сети несколько query-роутеров, то в качестве активного будет выбран с наименьшим ip.  
В обычном понимании: если задаём ''export-ribs'', то при этом указывается только одна таблица, куда будут скопированы маршруты. Но для PIM не работает export-ribs.


'''Leave message''': ''IGMP2'': Хост отправляет leave message для конкретной группы на общий адрес 224.0.0.2.
== Automatic Multicast Tunnel Gateway [AMT protocol]==
Возможность соединять multicast-enabled сеть и ipv4-only сеть (без мультикаст). Позволяет получать мультикаст трафик, там, где не включен мультикаст.


''IGMP1'': Хост просто перестает отвечать на query от роутра. Если больше нет подписчиков на группу, роутер по истечению какого-то интервала перестает слать трафик в интерфейс.
AMT протокол дает возможность искать и устанавливать соседство между relay-роутерами и gateway-роутерами.
'''Group-specific query''': Когда роутер получил leave от хоста, он отправляет general-specific query на адрес этой группы, чтобы понять есть ли еще заинтересованные получатели.


=== Разные версии протокола ===
Relay-роутеры - обычные мультикаст роутеры (с native-multicast), на которых аггрегируется большое кол-во AMT-туннелей.


'''IGMP v 1'''
Трафик до пользователей в multicast сети идет как multicast. Запросы трафика - multicast join.


- Чтобы получить трафик от конкретной группы, хост отправляет роутеру report message.
Трафик до пользователей в ipv4-only сети получают в виде UDP unicast stream. Запросы делаю в виде UDP IGMP request.


- Для отключения от группы хост просто перестает отвечать роутеру на query.
Работает только с PIM-SSM.


- Таймаут, после которого роутер перестает вещать группу в downstream interface = 260.
Работает только с IPv4.


(robustness count * igmp_query interval) + (1*IGMP response interval) = (2*125)+(1*10) = 260
== IGMP ==
''Internet group management protocol''


- Для выбора query-router нет отдельного механизма. Выбирать должен routing protocol.
IGMP не протокол маршрутизации. Работает между получателями и роутером, с которого отдается мультикаст в сегменте. Он просто передает информацию роутеру о заинтересованных получателях и получателях, которые хотят покинуть группу.


'''IGMP v 2'''
Для IPv6 используется точно такой же по принципу работы протокол MLD.
===Сообщения===
'''Report/Join message''': отправляет хост, когда хочет подписаться на какую-то группу.  DA = group address. После того как хост подписался на группу, он должен отвечать на query message от роутера. TTL = 1, т.к. сообщение должно долететь только до ближайшего маршрутизатора.


- Чтобы подписаться, хосты шлют report-message.
'''General query''':  роутер шлет general query на 224.0.0.1 всем хотсам (роутер при этом называется query-router (опрашивающий)). Хосты в ответ присылают группы, на которые они еще хотят быть подписаны. TTL тоже = 1.


- Чтобы отписаться, хосты шлют leave-group message.
Чтобы не дублировались ответы с одной группой от разных хостов, хосты шлют ответы с разным временным интервалом. Если хост видит, что о его группе сообщил другой хост, то он не будет отправлять ответ роутеру. Роутер итак сохранит интерфейс как downstream для данной группы.


- Чтобы проверить наличие подписчиков, роутер шлет group-specific message.
Если в домене несколько query-роутеров, то в качестве активного будет выбран с наименьшим ip.  


- Таймаут, после которого роутер перестает вещать: нет ответа от хостов в течение 2 сек (дефолт).
'''Leave message''':
*''IGMP2'': Хост отправляет leave message для конкретной группы на общий адрес 224.0.0.2.
*''IGMP1'': Хост просто перестает отвечать на query от роутра. Если больше нет подписчиков на группу, роутер по истечению какого-то интервала перестает слать трафик в интерфейс.
'''Group-specific query''':  
*''IGMP2'': Когда роутер получил leave от хоста, он отправляет general-specific query на адрес этой группы, чтобы понять есть ли еще заинтересованные получатели.


Robusness count * IGMP last member query interval = 2*1 = 2
=== Разные версии протокола ===


- Query-router - с наименьшим ip. Если падает query-router, его роль выполняет non-query router.
*'''IGMP v 1'''
:*Чтобы получить трафик от конкретной группы, хост отправляет роутеру report message.
:*Для отключения от группы хост просто перестает отвечать роутеру на query.
:*Таймаут, после которого роутер перестает вещать группу в downstream interface = 260.
(robustness count * igmp_query interval) + (1*IGMP response interval) = (2*125)+(1*10) = 260
:*Для выбора query-router нет отдельного механизма. Выбирать должен routing protocol.


'''IGMP v 3'''
*'''IGMP v 2'''
:*Чтобы подписаться, хосты шлют report-message.
:*Чтобы отписаться, хосты шлют leave-group message.
:*Чтобы проверить наличие подписчиков, роутер шлет group-specific message.
:*Таймаут, после которого роутер перестает вещать: нет ответа от хостов в течение 2 сек (дефолт).
robusness count * IGMP last member query interval = 2*1 = 2
:*Query-router - с наименьшим ip. Если падает query-router, его роль выполняет non-query router.


Все улучшения для v 2.
*'''IGMP v 3'''
Все улучшения для v 2. [активная подписка и отписка на группы].


Используется для SSM, поэтому report message (на адрес 224.0.0.22 - all IGMPv3) может содержать source information.
Используется для SSM, поэтому report message (на адрес 224.0.0.22 - all IGMPv3) может содержать source information.
Строка 100: Строка 163:
===L2 switches===
===L2 switches===


Свитчи обрабатывают мультикаст трафик как бродкаст, по умолчанию. Шлет трафик во все порты.
Свитчи обрабатывают мультикаст трафик как бродкаст, по умолчанию, т.е. шлет трафик во все порты.


IGMP-snooping позволяет выделить мультикаст трафик. С помощью IGMP сообщений, свитч может понять где получатели и слать трафик только к ним.
IGMP-snooping позволяет выделить мультикаст трафик. С помощью IGMP сообщений, свитч может понять где получатели и слать трафик только к ним.
Строка 107: Строка 170:
Передача трафика:
Передача трафика:


1. Весь трафик направлен в multicast-router интерфейс.
#Весь трафик направлен в multicast-router интерфейс.
 
#Если через IGMP-snooping свитч узнает о портах, за которыми сидят получатели, то шлет трафик туда.
2. Если через IGMP-snooping свитч узнает о портах, за которыми сидят получатели, то шлет трафик туда.
#224/8 сеть бродкастом идет во все порты, кроме входящего.
 
3. 224/8 сеть бродкастом идет во все порты, кроме входящего.


Стандартное расширение IGMP позволяет только обрабатывать query от роутера и сообщения от получателей. Не генерирует IGMP сообщения.
Стандартное расширение IGMP позволяет только обрабатывать query от роутера и сообщения от получателей. Не генерирует IGMP сообщения.
Строка 125: Строка 186:
Можно менять дефолтные значения всяких таймеров.
Можно менять дефолтные значения всяких таймеров.


Можно статически подписываться на какую-то группу (полезно для тестов). При этом интерфейс прсто добавляется в outgoing list.
Можно статически подписываться на какую-то группу (полезно для тестов). При этом интерфейс просто добавляется в outgoing list.
 
По умолчанию на Juniper используется IGMPv2, но при необходимости можно задать на интерфейсах нужную версию.
set protocols pim interface ge-0/0/0.910
set protocols igmp interface ge-0/0/0.910 version 1
set protocols igmp interface ge-0/0/0.910 static group 239.100.1.1


== Troubleshoting ==
== Troubleshoting ==
show igmp interfaces
show igmp groups
show igmp statistics
включение traceoptions


sh igmp interfaces
==Дополнительная информация==
sh igmp groups
*[[Глава 3. Routing protocols (DVMRP, PIM-DM, PIM-SM)]]
sh igmp statistics
*[[Глава 5. PIM-SSM]]
traceoptions
*[[MSDP | Глава 4. MSDP]]

Текущая версия на 18:37, 15 июля 2021


Общее

Мультикаст = поток UDP на определенные адреса.

Адресация

- 224/24 - local network control block [разничные протоколы маршрутизации, использующие мультикаст: OSPF, rip, igmp, ldp ...]

- 224.2.0.0/16 - SDP/SAP, адреса, использующиеся для передачи multicast session.

- 232/8 - под SSM

- 233/8 - используется под глобальную мультикаст-адресацию (GLOP) || 233.[first byte of AS].[second byte of AS].1-255 || только для 16-ти битных AS

- 234/8 - unicast-prefix-based IPv4

- 239/8 - administratively scoped block || это адреса, которые могут быть использованы в разных частях сети. Тоже самое, что и private IP.

Multicast IP => multicast mac

Если не заморачиваться почему так, то правило перевода простое:

Конвертируем последние 23 бита IP в десятичную систему счисления.

  • 224.10.8.5: 0001010.00001000.00000101 => 0a.08.05

Прибавляем к "01-00-5e" переведенное значение.

  • 01-00-5e + 0a-08-05 = 01-00-5e-0a-08-05

Проблема в том, что для разных мультикаст-групп (адресов) - мак-адреса будут пересекаться, т.к. не учитываются первые биты ip-адреса.

Multicast forwarding

  • unicast forwarding основан на dest ip.
  • multicast forwarding основан на source ip.

Предотвращение петель:

  • RPF-check для источника: сравнивается с какого интерфейса фактически пришел мультикаст пакет с тем, откуда по unicast table пакет должен приходить (источник или RP). Если сходится - RPF done, не сходится - RPF fail. Префиксы, прошедшие RPF-check хранятся в inet.1.
  • Multicast трафик никогда не форвардится в сторону источника.
show multicast rpf <group ip>

Routing tables

inet.0 - дефолтная таблица для проведения RPF-check [можно использовать inet.2, которая для этого и предназначена]. Если unicast и multicast топологии одинаковые, то inet.0 и inet.2 будут одинаковы.

inet.1 - записываются результаты RPF-check, форвардинг производится на основании этой таблицы.

>show route table inet.1  
inet.1: 238 destinations, 238 routes (238 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
224.0.0.0/4        *[Multicast/180] 74w2d 13:10:11
                      MultiResolve
224.0.0.0/24       *[Multicast/180] 74w2d 13:10:11
                     MultiDiscard
232.0.0.0/8        *[Multicast/180] 74w2d 13:10:11
                     MultiResolve
232.192.1.1,10.200.86.1/32*[PIM/105] 6w0d 08:32:53
                     Multicast (IPv4) Composite
232.192.1.1,10.200.86.2/32*[PIM/105] 8w3d 15:25:48
                     Multicast (IPv4) Composite
232.192.1.2,10.200.86.1/32*[PIM/105] 6w0d 08:32:52
                      Multicast (IPv4) Composite
232.192.1.2,10.200.86.2/32*[PIM/105] 8w3d 15:25:52
                     Multicast (IPv4) Composite
232.192.1.4,10.200.86.1/32*[PIM/105] 23:11:56
                     Multicast (IPv4) Composite
...

Detailed

232.192.1.1.10.200.86.1/64 (1 entry, 1 announced)
       *PIM    Preference: 105         
               Next hop type: Multicast (IPv4) Composite, Next hop index: 1048796
               Address: 0xa4edf30
               Next-hop reference count: 28
               State: <Active Int Ext AckRequest>
               Local AS: 100 
               Age: 6w0d 8:35:30 
               Validation State: unverified 
               Task: PIM.master
               Announcement bits (1): 0-KRT 
               AS path: I
               AS path: Recorded

inet.2 - если для multicast на сети должна быть использована другая топология, то используем эту таблицу. inet.2 в таком случае будет использоваться для RPF-check.

MP-BGP и multitopology IS-IS могут напрямую заполнять маршрутной информацией inet.2.

Чтобы ISIS стал заполнять inet.2 - нужно включить

set protocols isis topologies ipv4-multicast 

Все остальные протоколы для заполнения таблицы должны заниматься копированием в inet.2 маршрутов с помощью RIB-groups.

IMPORT-RIB: для протокола PIM import-rib копирует маршруты из протокола в указанную таблицу. То есть указываем только одну таблицу. Указанная таблица будет использоваться для RPF.

Для остальных протоколов первая таблица <> - откуда копируются маршруты, вторая <to-inet2> - куда копируются.

set routing-options rib-groups mcast-table import-rib inet.2
set protocols pim rib-group inet mcast-table
set routing-options rib-groups import-rib to-inet2 [inet.0 inet.2]
set routing-options rib-groups import-policy static *по желанию/необходимости
set protocols ospf rib-groups to-inet.2
set routing-options interface-routes rib-group inet to-inet2

В обычном понимании: если задаём export-ribs, то при этом указывается только одна таблица, куда будут скопированы маршруты. Но для PIM не работает export-ribs.

Automatic Multicast Tunnel Gateway [AMT protocol]

Возможность соединять multicast-enabled сеть и ipv4-only сеть (без мультикаст). Позволяет получать мультикаст трафик, там, где не включен мультикаст.

AMT протокол дает возможность искать и устанавливать соседство между relay-роутерами и gateway-роутерами.

Relay-роутеры - обычные мультикаст роутеры (с native-multicast), на которых аггрегируется большое кол-во AMT-туннелей.

Трафик до пользователей в multicast сети идет как multicast. Запросы трафика - multicast join.

Трафик до пользователей в ipv4-only сети получают в виде UDP unicast stream. Запросы делаю в виде UDP IGMP request.

Работает только с PIM-SSM.

Работает только с IPv4.

IGMP

Internet group management protocol

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

Для IPv6 используется точно такой же по принципу работы протокол MLD.

Сообщения

Report/Join message: отправляет хост, когда хочет подписаться на какую-то группу.  DA = group address. После того как хост подписался на группу, он должен отвечать на query message от роутера. TTL = 1, т.к. сообщение должно долететь только до ближайшего маршрутизатора.

General query:  роутер шлет general query на 224.0.0.1 всем хотсам (роутер при этом называется query-router (опрашивающий)). Хосты в ответ присылают группы, на которые они еще хотят быть подписаны. TTL тоже = 1.

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

Если в домене несколько query-роутеров, то в качестве активного будет выбран с наименьшим ip.

Leave message:

  • IGMP2: Хост отправляет leave message для конкретной группы на общий адрес 224.0.0.2.
  • IGMP1: Хост просто перестает отвечать на query от роутра. Если больше нет подписчиков на группу, роутер по истечению какого-то интервала перестает слать трафик в интерфейс.

Group-specific query:

  • IGMP2: Когда роутер получил leave от хоста, он отправляет general-specific query на адрес этой группы, чтобы понять есть ли еще заинтересованные получатели.

Разные версии протокола

  • IGMP v 1
  • Чтобы получить трафик от конкретной группы, хост отправляет роутеру report message.
  • Для отключения от группы хост просто перестает отвечать роутеру на query.
  • Таймаут, после которого роутер перестает вещать группу в downstream interface = 260.

(robustness count * igmp_query interval) + (1*IGMP response interval) = (2*125)+(1*10) = 260

  • Для выбора query-router нет отдельного механизма. Выбирать должен routing protocol.
  • IGMP v 2
  • Чтобы подписаться, хосты шлют report-message.
  • Чтобы отписаться, хосты шлют leave-group message.
  • Чтобы проверить наличие подписчиков, роутер шлет group-specific message.
  • Таймаут, после которого роутер перестает вещать: нет ответа от хостов в течение 2 сек (дефолт).

robusness count * IGMP last member query interval = 2*1 = 2

  • Query-router - с наименьшим ip. Если падает query-router, его роль выполняет non-query router.
  • IGMP v 3

Все улучшения для v 2. [активная подписка и отписка на группы].

Используется для SSM, поэтому report message (на адрес 224.0.0.22 - all IGMPv3) может содержать source information.

L2 switches

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

IGMP-snooping позволяет выделить мультикаст трафик. С помощью IGMP сообщений, свитч может понять где получатели и слать трафик только к ним. Делит порты на multicast-router interface (откуда приходят query, либо заданы статически), host-side interface (все остальные).

Передача трафика:

  1. Весь трафик направлен в multicast-router интерфейс.
  2. Если через IGMP-snooping свитч узнает о портах, за которыми сидят получатели, то шлет трафик туда.
  3. 224/8 сеть бродкастом идет во все порты, кроме входящего.

Стандартное расширение IGMP позволяет только обрабатывать query от роутера и сообщения от получателей. Не генерирует IGMP сообщения.

IGMP snooping proxy ведет себя как роутер для получателей (генерирует query), работает как получатели для роутера (генерирует leave и join сообщения).

Тем самым уменьшается кол-во report-сообщений для роутера.

Configuration

На интерфейсах с активным pim, автоматически включается IGMPv2.

Можно менять дефолтные значения всяких таймеров.

Можно статически подписываться на какую-то группу (полезно для тестов). При этом интерфейс просто добавляется в outgoing list.

По умолчанию на Juniper используется IGMPv2, но при необходимости можно задать на интерфейсах нужную версию.

set protocols pim interface ge-0/0/0.910
set protocols igmp interface ge-0/0/0.910 version 1
set protocols igmp interface ge-0/0/0.910 static group 239.100.1.1

Troubleshoting

show igmp interfaces
show igmp groups
show igmp statistics
включение traceoptions

Дополнительная информация