Por que IGMP e MLD seriam obrigados a encaminhar pacotes não registrados para todas as portas?

Question

Primeiro, um pouco de fundo: Meu entendimento é que o propósito do IGMP (e seu primo IPv6, MLD) é evitar o desperdício de banda, garantindo que os pacotes multicast só sejam transmitidos para destinos realmente interessados nesses pacotes. Essa lógica é um refinamento de um comportamento de switch mais antigo / simples, que era transmitir pacotes multicast de entrada para todas as outras portas, e deixar que os dispositivos conectados descartassem pacotes multicast que não estavam interessados.

O IGMP e o MLD fazem isso porque o switch mantém uma tabela que rastreia quais dispositivos conectados estão atualmente associados a quais grupos multicast, e quando um pacote multicast entra, o switch o encaminha apenas para as portas que estão associadas ao grupo indicado pelo endereço de destino do pacote. Até agora tudo bem.

Mas, de acordo com meu colega de trabalho, há um caso especial ímpar: se dispositivos no se uniram a um grupo de multidifusão específico, o switch deve encaminhar todos os pacotes multicast recebidos para todas as portas (bem, tecnicamente para todas as portas com um roteador IGMP anexado, mas ele diz que equivale à mesma coisa, já que a maioria dos switches não sabe quais portas têm um roteador IGMP conectado e assim voltará a inundar todos portas).

Isso parece muito contra-intuitivo para mim - por que um algoritmo cujo propósito inteiro é evitar que uma inundação de multidifusão inundasse deliberadamente todas as portas no cenário a onde ninguém está interessado em receber os dados multicast? Isso é feito para garantir a compatibilidade retroativa com implementações de multicast quebradas que esperam receber pacotes de multicast que eles nunca solicitaram? Se não, qual é a motivação para isso? Parece que reduz significativamente a utilidade do algoritmo.

Para referência, as diretrizes para as quais meu colega de trabalho aponta estão na seção 2.1.2 da 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.

Acho que o parágrafo a seguir pode explicar a motivação, mas não entendo:

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.

i.e. Por que a falha em inundar fluxos não registrados impede que os hosts v3 recebam seu tráfego? (os hosts v3 não sabem se juntar a nenhum grupo em que desejam receber tráfego?) E, no cenário alternativo, a perda de tráfego devido a inundações não seria um problema tão ruim quanto a perda de tráfego devido à não inundação?

    

Answer 1

O problema é descrito no relatório da reunião , que é referenciado como [IETF56] em RFC4541 :

Problem - Router <-> IGMPv2 snooping switch <-> IGMPv3 capable host

Router sends IGMPv3 query, which tells the host to use IGMPv3 Hosts send IGMPv3 reports

What then happens ?

Switch does one of these 3 :

1. Doesn’t forward reports
2. Forwards reports but does not forward data
3. Forwards reports and data but no queries, data then times out

Result - Multicast breaks when you upgrade a router or host (whichever is last) to IGMPv3.

A inundação de fluxos não registrados funciona em torno do problema no caso 1 (quando o comutador antigo não encaminha relatórios do IGMPv3) e não deve fazer diferença nos casos 2 e 3 (quando os relatórios do IGMPv3 passarão pelo comutador antigo).

Quanto a qual problema (queda de tráfego ou inundação excessiva) é pior, isso depende muito de uma situação particular. Em alguns casos, a inundação pode ser pior porque, ao contrário do tráfego perdido, pode não ser percebido imediatamente durante o teste, e quando em algum momento posterior o volume de tráfego aumenta o suficiente para tornar um problema de inundação, a configuração quebrada pode ser amplamente implantada, de trabalho para consertar isso.

    

Answer 2

First, a little background: My understanding is that the purpose of IGMP (and its IPv6 cousin, MLD) is to avoid wasted bandwidth by ensuring that multicast packets only get transmitted to destinations that are actually interested in those packets. This logic is a refinement of an older/simpler switch behavior, which was to broadcast incoming multicast packets to all other ports no matter what, and leave it up to the connected devices to drop multicast packets that they weren't interested in.

Não. A finalidade do IGMP / MLD é que os roteadores saibam qual grupo de multicast foi associado a qualquer host conectado localmente (eles nem se importam com qual deles, porque, naquela época, a mídia compartilhada era esperada). Em seguida, o roteador envia essas informações para um algoritmo de roteamento multicast que trocará essas informações pelos roteadores para criar tabelas de roteamento multicast. Desta forma, uma máquina X conectada a um roteador A pode enviar tráfego multicast para o grupo G, e uma máquina Y conectada a outro roteador B irá recebê-lo se tiver se juntado a G.

O IGMP foi inventado antes da existência dos switches e esperava-se que a mídia entre hosts e roteadores fosse compartilhada. O IGMP foi otimizado para mídia compartilhada, pois forneceu otimizações caso muitos hosts estivessem interessados no mesmo grupo, permitindo que apenas um host enviasse o relatório de associação apenas uma vez (porque todos os hosts receberiam tráfego desse grupo de multicast).

This seems very counterintuitive to me -- why would an algorithm whose entire purpose is to avoid multicast flooding deliberately flood to all ports in the a scenario where nobody is interested in receiving the multicast data?

Os roteadores IGMP / MLD estão sempre interessados em qualquer dado multicast. É seu papel para encaminhá-los depois de tudo. Se um host envia dados multicast ao grupo X, o roteador deve encaminhar o pacote para todos os outros roteadores em que pelo menos um host ingressou no grupo X. O switch não tem conhecimento dessa situação, portanto, se não encaminhará tráfego desconhecido do host para o roteador, seria apenas quebrar roteamento multicast.

Quanto ao motivo pelo qual o encaminhamento de pacotes não registrados para todas as portas deve ser ativado, pode haver razões técnicas para isso, mas, pessoalmente, considero os switches como uma otimização em comparação com os hubs. Eu quero que eles, em sua configuração padrão, otimizem as coisas sem quebrá-las. Se o switch receber o que seriam pacotes ilegítimos ou inesperados, eu gostaria que ele fosse encaminhado de qualquer maneira, porque esse pacote provavelmente foi enviado por um motivo. A última coisa que quero é que meu switch deixe cair pacotes.

    

Answer 3

        Router <-> IGMPv2 snooping switch <-> IGMPv3 capable host

Aqui eu acho que o padrão explica,

O pacote não registrado do Igmpv3 é enviado para o comutador de espionagem (IGMPv2). Ele não deve reconhecer o pacote Igmp e, em seguida, desativar o pacote Igmp, e o pacote de difusão seletiva Igmpv3 não flui para o host Igmpv3.