Во-первых, небольшая предыстория: я понимаю, что цель IGMP (и его двоюродного брата IPv6, MLD) состоит в том, чтобы избежать потери полосы пропускания, гарантируя, что многоадресные пакеты будут передаваться только тем адресам, которые действительно заинтересованы в этих пакетах. Эта логика является уточнением более старого / более простого поведения коммутатора, которое заключалось в широковещательной рассылке входящих многоадресных пакетов на все другие порты, несмотря ни на что, и оставление возможности подключенным устройствам отбрасывать многоадресные пакеты, которые им не интересны.
IGMP и MLD делают это, заставляя коммутатор вести таблицу, которая отслеживает, какие подключенные устройства в настоящее время присоединены к каким группам многоадресной рассылки, и когда приходит многоадресный пакет, коммутатор пересылает его только на порты, которые присоединены к группе, обозначенной адрес назначения пакета. Все идет нормально.
Но, по словам моего коллеги, есть странный частный случай: если нет устройства присоединились к определенной группе многоадресной рассылки, тогда коммутатор должен пересылать все входящие многоадресные пакеты в все порты (ну, технически ко всем портам с подключенным маршрутизатором IGMP, но он говорит, что это одно и то же, поскольку большинство коммутаторов не знают, к каким портам подключен маршрутизатор IGMP, и поэтому вернутся к лавинной рассылке на все порты).
Мне это кажется очень нелогичным - зачем алгоритму, вся цель состоит в том, чтобы избежать преднамеренного лавинного потока многоадресной рассылки на все порты в сценарии, где никто заинтересован в получении данных многоадресной рассылки? Сделано ли это для обеспечения обратной совместимости с неработающими реализациями многоадресной рассылки, которые ожидают получения пакетов многоадресной рассылки, которые они никогда не запрашивали? Если нет, то что для этого мотивация? Похоже, это значительно снижает полезность алгоритма.
Для справки: рекомендации, на которые указывает мой коллега, приведены в разделе 2.1.2. RFC 4541:
3) An unregistered packet is defined as an IPv4 multicast packet with
a destination address which does not match any of the groups
announced in earlier IGMP Membership Reports.
If a switch receives an unregistered packet, it must forward that
packet on all ports to which an IGMP router is attached. A switch
may default to forwarding unregistered packets on all ports.
Switches that do not forward unregistered packets to all ports
must include a configuration option to force the flooding of
unregistered packets on specified ports.
Я думаю, что следующий абзац может объяснить мотивацию, но я этого не понимаю:
In an environment where IGMPv3 hosts are mixed with snooping
switches that do not yet support IGMPv3, the switch's failure to
flood unregistered streams could prevent v3 hosts from receiving
their traffic. Alternatively, in environments where the snooping
switch supports all of the IGMP versions that are present,
flooding unregistered streams may cause IGMP hosts to be
overwhelmed by multicast traffic, even to the point of not
receiving Queries and failing to issue new membership reports for
their own groups.
то есть почему отказ от лавинной рассылки незарегистрированных потоков не позволяет хостам v3 получать свой трафик? (разве хосты v3 не знают, что нужно присоединяться к каким-либо группам, к которым они хотят получать трафик?) И в альтернативном сценарии не будет ли потеря трафика из-за наводнения такой же серьезной проблемой, как потеря трафика из-за отсутствия наводнения?
Во-первых, небольшая предыстория: я понимаю, что цель IGMP (и его двоюродного брата IPv6, MLD) состоит в том, чтобы избежать потери полосы пропускания, гарантируя, что многоадресные пакеты будут передаваться только тем адресам, которые действительно заинтересованы в этих пакетах. Эта логика является уточнением более старого / более простого поведения коммутатора, которое заключалось в широковещательной рассылке входящих многоадресных пакетов на все другие порты, несмотря ни на что, и оставление возможности подключенным устройствам отбрасывать многоадресные пакеты, которые им не интересны.
Нет. Цель IGMP / MLD состоит в том, чтобы маршрутизаторы знали, к какой группе многоадресной рассылки присоединился какой-либо локально подключенный хост (им даже все равно, какой из них, потому что в то время ожидались общие носители). Затем маршрутизатор передает эту информацию алгоритму многоадресной маршрутизации, который будет обмениваться этой информацией между маршрутизаторами для построения таблиц многоадресной маршрутизации. Таким образом, машина X, подключенная к маршрутизатору A, может отправлять многоадресный трафик в группу G, а машина Y, подключенная к другому маршрутизатору B, получит его, если она присоединилась к G.
IGMP был изобретен до того, как появились коммутаторы, и предполагал, что среда передачи между хостами и маршрутизаторами будет совместно использоваться. IGMP был даже оптимизирован для общих носителей, поскольку он обеспечивал оптимизацию в случае, если многие хосты были заинтересованы в одной и той же группе, позволяя только одному хосту отправлять отчет о членстве только один раз (потому что все хосты в любом случае будут получать трафик из этой многоадресной группы).
Мне это кажется очень нелогичным - зачем алгоритму, вся цель которого состоит в том, чтобы избежать многоадресного лавинного рассылки, намеренно лавинной рассылки на все порты в сценарии, где никто не заинтересован в получении многоадресных данных?
Маршрутизаторы IGMP / MLD всегда интересуются любыми многоадресными данными. В конце концов, их роль - направлять их. Если хост отправляет многоадресные данные группе X, маршрутизатор должен переслать пакет всем другим маршрутизаторам, где хотя бы один хост присоединился к группе X. Коммутатор совершенно не знает об этой ситуации, поэтому, если он не пересылает неизвестный трафик с хоста к маршрутизатору, это просто нарушит многоадресную маршрутизацию.
Что касается того, почему пересылка незарегистрированных пакетов на все порты должна быть включена, для этого могут быть технические причины, но лично я считаю коммутаторы оптимизацией по сравнению с концентраторами. Я хочу, чтобы они в своей конфигурации по умолчанию оптимизировали вещи, не нарушая их. Если коммутатор получает незаконные или неожиданные пакеты, я бы хотел, чтобы он все равно пересылал их, потому что этот пакет, вероятно, был отправлен по какой-то причине. Меньше всего я хочу, чтобы мой коммутатор отбрасывал пакеты.
Проблема описана в отчет о встрече который упоминается как [IETF56] в RFC4541:
Проблема - Маршрутизатор <-> Переключатель отслеживания IGMPv2 <-> Хост с поддержкой IGMPv3
Маршрутизатор отправляет запрос IGMPv3, который сообщает узлу использовать IGMPv3. Узлы отправляют отчеты IGMPv3.
Что тогда происходит?
Switch выполняет одно из трех следующих действий:
- Не пересылает отчеты
- Перенаправляет отчеты, но не передает данные
- Перенаправляет отчеты и данные, но не запросы, данные затем истекают
Результат - многоадресная рассылка прерывается при обновлении маршрутизатора или хоста (в зависимости от того, что последний) до IGMPv3.
Заливка незарегистрированных потоков позволяет решить проблему в случае 1 (когда старый коммутатор не пересылает отчеты IGMPv3) и не должно влиять на случаи 2 и 3 (когда отчеты IGMPv3 будут передаваться через старый коммутатор).
Что касается того, какая проблема (упавший трафик или чрезмерное наводнение) хуже, это сильно зависит от конкретной ситуации. В некоторых случаях лавинная рассылка может быть хуже, потому что, в отличие от пропущенного трафика, она может быть не сразу замечена во время тестирования, а когда в более позднее время объем трафика возрастет настолько, что переполнение станет проблемой, поврежденная конфигурация может быть широко развернута, что потребует много работы, чтобы исправить это.
Router <-> IGMPv2 snooping switch <-> IGMPv3 capable host
Здесь, я думаю, стандарт объясняет,
Незарегистрированный пакет Igmpv3 отправляется на коммутатор отслеживания (IGMPv2). Он не должен распознавать пакет Igmp, затем коммутатор удаляет пакет Igmp, тогда многоадресный пакет Igmpv3 не проходит на хост Igmpv3.