Зачем IGMP и MLD требовать пересылки незарегистрированных пакетов на все порты?
Во-первых, немного предыстории: я понимаю, что цель 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 не знают, присоединяться ли к каким-либо группам, на которые они хотят получать трафик?) И в альтернативном сценарии не будет ли потеря трафика из-за затопления такой же серьезной проблемой, как потеря трафика из-за не затопления?
3 ответа
Проблема описана в отчете о собрании, который упоминается как [IETF56] в RFC4541:
Проблема - маршрутизатор <-> IGMPv2 snooping switch <-> IGMPv3-совместимый хост
Маршрутизатор отправляет запрос IGMPv3, который указывает хосту использовать IGMPv3. Хосты отправляют отчеты IGMPv3
Что тогда происходит?
Switch делает одно из этих 3:
- Не пересылать отчеты
- Пересылает отчеты, но не пересылает данные
- Переадресация отчетов и данных, но без запросов, данные затем истекают
Результат - Многоадресная передача прерывается при обновлении маршрутизатора или хоста (в зависимости от того, что будет последним) до IGMPv3.
Затопление незарегистрированных потоков позволяет решить проблему в случае 1 (когда старый коммутатор не пересылает отчеты IGMPv3) и не должно иметь значения в случаях 2 и 3 (когда отчеты IGMPv3 будут передаваться через старый коммутатор).
Что касается того, какая проблема (падение трафика или чрезмерное наводнение) хуже, это сильно зависит от конкретной ситуации. В некоторых случаях затопление может быть хуже, потому что, в отличие от пропущенного трафика, оно может не быть замечено сразу во время тестирования, а когда в более позднее время объем трафика увеличивается настолько, что становится причиной затопления, сломанная конфигурация может быть широко развернута, что требует много работы, чтобы исправить это.
Во-первых, немного предыстории: я понимаю, что цель IGMP (и его двоюродного брата IPv6, MLD) состоит в том, чтобы избежать неиспользуемой пропускной способности, обеспечивая передачу многоадресных пакетов только тем адресатам, которые действительно заинтересованы в этих пакетах. Эта логика является уточнением более старого / более простого поведения коммутатора, которое должно было широковещательно передавать входящие многоадресные пакеты на все другие порты и предоставлять подключенным устройствам возможность отбрасывать многоадресные пакеты, в которых они не заинтересованы.
Нет. Цель IGMP/MLD состоит в том, чтобы маршрутизаторы знали, к какой группе многоадресной рассылки присоединился какой-либо локально подключенный хост (им даже не важно, какой из них, потому что в то время ожидалась общая среда). Затем маршрутизатор передает эту информацию в алгоритм многоадресной маршрутизации, который будет обмениваться этой информацией между маршрутизаторами для создания таблиц многоадресной маршрутизации. Таким образом, машина X, подключенная к маршрутизатору A, может отправлять многоадресный трафик группе G, а машина Y, подключенная к другому маршрутизатору B, получит его, если она присоединилась к G.
IGMP был изобретен до появления коммутаторов и предполагал, что носители между хостами и маршрутизаторами будут общими. IGMP даже был оптимизирован для общего мультимедиа, поскольку он обеспечивал оптимизацию на случай, если многие хосты интересовались одной и той же группой, позволяя только одному хосту отправлять отчет о членстве только один раз (поскольку все хосты в любом случае получали бы трафик от этой многоадресной группы).
Мне кажется, что это очень нелогично - почему алгоритм, цель которого состоит в том, чтобы избежать многоадресного наводнения, намеренно затопляет все порты в сценарии, где никто не заинтересован в получении многоадресных данных?
Маршрутизаторы IGMP/MLD всегда интересуются любыми многоадресными данными. В конце концов, их роль состоит в том, чтобы направить их. Если хост отправляет данные многоадресной рассылки группе X, маршрутизатор должен переслать пакет всем другим маршрутизаторам, где хотя бы один хост присоединился к группе X. Коммутатор не знает об этой ситуации, поэтому если он не пересылает неизвестный трафик с хоста к маршрутизатору, это просто сломало бы многоадресную маршрутизацию.
Что касается того, почему должна быть включена пересылка незарегистрированных пакетов на все порты, для этого могут быть технические причины, но лично я считаю коммутаторы оптимизацией по сравнению с концентраторами. Я хочу, чтобы они в своей конфигурации по умолчанию оптимизировали вещи, не нарушая их. Если коммутатор получает незаконные или неожиданные пакеты, я бы в любом случае хотел, чтобы он переадресовал его, потому что этот пакет, вероятно, был отправлен по причине. Последнее, что я хочу, это мой коммутатор, отбрасывающий пакеты.
Router <-> IGMPv2 snooping switch <-> IGMPv3 capable host
Здесь я думаю, что стандарт объясняет,
Незарегистрированный пакет Igmpv3 отправляется коммутатору отслеживания (IGMPv2). Он не должен распознать пакет Igmp, затем переключить обрезку пакета Igmp, тогда пакет многоадресной рассылки Igmpv3 не передается на хост Igmpv3.