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

Материал из Juniper Exam Wiki
Перейти к навигации Перейти к поиску
м
 
(не показано 28 промежуточных версий этого же участника)
Строка 1: Строка 1:
{{#description2: multicast адресация. Routing tables junos. IGMP сообщения. IGMPv2. IGMPv3. Конфигурация IGMP. Траблшутинг IGMP.Информация для подготовки к экзаменам Juniper.}}
== Общее ==
== Общее ==


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


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


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


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


Конвертируем последние 23 бита IP в 10-ую системе счисления. 224.10.8.5: 0001010.00001000.00000101 => 0a.08.05
Конвертируем последние 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
Прибавляем к "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>''
Строка 39: Строка 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.


set routing-options rib-groups import-rib to-inet2 [inet.0 inet.2]
MP-BGP и multitopology IS-IS могут напрямую заполнять маршрутной информацией inet.2.  
set routing-options rib-groups import-policy static
set protocols ospf rib-groups to-inet.2


Если задаём ''export-ribs'', то при этом указывается только одна таблица, куда будут скопированы маршруты.
Чтобы ISIS стал заполнять inet.2 - нужно включить
set protocols isis topologies ipv4-multicast
Все остальные протоколы для заполнения таблицы должны заниматься копированием в inet.2 маршрутов с помощью '''RIB-groups'''.


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


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


Для IPv6 используется точно такой же по принципу работы протокол MLD.
set routing-options rib-groups mcast-table import-rib inet.2
set protocols pim rib-group inet mcast-table


'''Report/Join message''': отправляет хост, когда хочет подписаться на какую-то группу.  DA = group address. После того как хост подписался на группу, он должен отвечать на query message от роутера. TTL = 1, т.к. сообщение должно долететь только до ближайшего маршрутизатора.
set routing-options rib-groups import-rib to-inet2 [inet.0 inet.2]
 
set routing-options rib-groups import-policy static *''по желанию/необходимости''
'''General query''':  роутер шлет general query на 224.0.0.1 всем хотсам (роутер при этом называется query-router (порашивающий)). Хосты в ответ присылают группы, на которые они еще хотят быть подписаны. TTL тоже = 1.
set protocols ospf rib-groups to-inet.2
 
set routing-options interface-routes rib-group inet to-inet2
Чтобы не дублировались ответы с одной группой от разных хостов, хосты шлют ответы с разным временным интервалом. Если хост видит, что о его группе сообщил другой хост, то он не будет отправлять ответ роутеру. Роутер итак сохранит интерфейс как downstream для данной группы.


Если в сети несколько 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.
Строка 108: Строка 163:
===L2 switches===
===L2 switches===


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


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


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


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


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


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


== 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

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