IGMP snooping

Материал из Википедии — свободной энциклопедии
Перейти к: навигация, поиск

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

После включения IGMP snooping коммутатор начинает анализировать все IGMP-пакеты между подключенными к нему компьютерами-потребителями и маршрутизаторами-поставщиками multicast трафика. Обнаружив IGMP-запрос потребителя на подключение к multicast группе, коммутатор включает порт, к которому тот подключён, в список её членов (для ретрансляции группового трафика). И наоборот: услышав запрос 'IGMP Leave' (покинуть), удаляет соответствующий порт из списка группы.

Назначение[править | править исходный текст]

IGMP snooping разработан для предотвращения широковещательной (broadcast) ретрансляции multicast трафика компьютерам-потребителям, которые явно не заявили о своей заинтересованности в нём. Это позволяет коммутаторам исключать такой трафик из потоков, направляемых через порты, к которым не подключено его потребителей, тем самым существенно снижая нагрузку на сеть. Однако при этом нагрузка на сам коммутатор не снижается, а повышается, поскольку такая фильтрация требует затрат памяти, NPU и CPU, в то время как простая ретрансляция по всем портам — операция дешёвая. По умолчанию, без функции IGMP snooping, коммутатор ретранслирует multicast трафик по всем своим портам, принадлежащим к тому же широковещательному домену или VLAN, что не только бесполезно, но и способно вызвать проблемы на некоторых конечных сетевых устройствах, вынужденных обрабатывать неожиданный для них поток данных. Использование такого поведения, по умолчанию злоумышленником, может привести к успешной DoS-атаке на всю сеть или некоторые устройства в ней. IGMP snooping способен существенно улучшить работу сети, в которой активно используются приложения, основанные на multicast вещании.

По существу IGMP snooping есть оптимизация реалий канального уровня с учётом фактических потребностей сетевого уровня и не является функциональностью самого IGMP.

Реализации[править | править исходный текст]

Существуют две реализации IGMP snooping: активный и пассивный.

  • Пассивный IGMP snooping просто прослушивает IGMP трафик, никак не фильтруя его, не интерферируя с IGMP никоим образом.
  • Активный IGMP snooping: Хотя snooping подразумевает пассивное прослушивание, некоторые реализации активно фильтруют IGMP-пакеты с целью уменьшить загруженность multicast маршрутизатора. Запросы на подключение и отключение, следующие к маршрутизатору, фильтруются с целью минимизации объемов пересылаемой информации. Коммутатор старается добиться того, чтобы маршрутизатор имел только одну запись подписчика на каждую multicast группу независимо от того, сколько их на самом деле.
    Например: есть два активных подписчика, и первый из них покидает группу, коммутатор определяет, что маршрутизатору эта информация не нужна, поскольку не влияет на состояние группы с точки зрения последнего. Однако, когда в следующий раз поступит обычный запрос от маршрутизатора, коммутатор пропустит ответ от оставшегося потребителя, чтобы маршрутизатор не счёл, что подписчиков больше нет.
    Отсюда следует, что при активном IGMP snooping маршрутизатор знает только о самом последнем участнике, присоединившемся к группе.

Смотри также[править | править исходный текст]

Ссылки на RFC[править | править исходный текст]

  • RFC 4541 — Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches. M. Christensen, K. Kimball, F. Solensky. May 2006. (Format: TXT=38555 bytes) (Status: INFORMATIONAL)
  • RFC 3376 — Internet Group Management Protocol, Version 3. B. Cain, S. Deering, I. Kouvelas, B. Fenner, A. Thyagarajan. October 2002.(Format: TXT=119726 bytes) (Obsoletes RFC2236) (Updated by RFC4604)(Status: PROPOSED STANDARD)
  • Текущий статус RFC можно проверить по их списку — [1]