Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
NESTA PÁGINA
 

Entendendo a bisbilhotagem de MLD

A espionagem de Multicast Listener Discovery (MLD) restringe a inundação do tráfego IPv6 multicast em VLANs. Quando o snooping de MLD é habilitado em uma VLAN, um dispositivo da Juniper Networks examina as mensagens MLD entre hosts e roteadores multicast e descobre quais hosts estão interessados em receber tráfego para um grupo de multicast. Com base no que aprende, o dispositivo encaminha o tráfego multicast apenas para as interfaces na VLAN que estão conectadas aos receptores interessados, em vez de inundar o tráfego para todas as interfaces.

A bisbilhotagem de MLD é compatível com MLD versão 1 (MLDv1) e MLDv2. Para obter detalhes sobre MLDv1 e MLDv2, consulte os seguintes padrões:

  • MLDv1 — Veja RFC 2710, Multicast Listener Discovery (MLD) para IPv6.

  • MLDv2 — consulte RFC 3810, Multicast Listener Discovery Version 2 (MLDv2) para IPv6.

Benefícios do MLD Snooping

  • Optimized bandwidth utilization— O principal benefício da bisbilhotagem de MLD é reduzir a inundação de pacotes. Os dados de multicast IPv6 são encaminhados seletivamente para uma lista de portas que desejam receber os dados, em vez de serem inundados para todas as portas em uma VLAN.

  • Improved security— Ataques de negação de serviço de fontes desconhecidas são evitados.

Como funciona o MLD Snooping

Por padrão, o dispositivo inunda o tráfego multicast de Camada 2 em todas as interfaces pertencentes a essa VLAN no dispositivo, exceto a interface que é a origem do tráfego multicast. Esse comportamento pode consumir quantidades significativas de largura de banda.

Você pode habilitar a bisbilhotagem de MLD para evitar essa inundação. Quando você habilita a bisbilhotagem de MLD, o dispositivo monitora mensagens MLD entre receptores (hosts) e roteadores de multicast e usa o conteúdo das mensagens para criar uma tabela de encaminhamento de multicast IPv6 — um banco de dados de grupos de multicast IPv6 e as interfaces conectadas aos membros interessados de cada grupo. Quando o dispositivo recebe tráfego multicast para um grupo multicast, ele usa a tabela de encaminhamento para encaminhar o tráfego apenas para interfaces conectadas a receptores que pertencem ao grupo multicast.

A Figura 1 mostra um exemplo de fluxo de tráfego multicast com bisbilhotamento de MLD habilitado.

Figura 1: Fluxo de tráfego multicast com rastreamento de MLD habilitado Network setup with a multicast router forwarding traffic for Group 1 and Group 2. EX Series Switch connects to Host A and B directly, Host 1 and 3 in Group 1, Host 2 and 4 in Group 2 via multicast traffic distribution.

Tipos de mensagem MLD

Os roteadores multicast usam MLD para aprender, para cada uma de suas redes físicas conectadas, quais grupos têm ouvintes interessados. Em qualquer sub-rede, um roteador multicast é eleito para atuar como um consultor MLD. O consultor MLD envia os seguintes tipos de consultas aos hosts:

  • Consulta geral — Pergunta se algum host está ouvindo algum grupo.

  • Consulta específica de grupo — Pergunta se algum host está escutando um grupo multicast específico. Essa consulta é enviada em resposta a um host que sai do grupo multicast e permite que o roteador determine rapidamente se algum host restante está interessado no grupo.

  • Consulta específica de grupo e origem — (somente MLD versão 2) Pergunta se algum host está escutando o tráfego multicast de grupo de uma fonte multicast específica. Essa consulta é enviada em resposta a um host, indicando que ele não está mais interessado em receber tráfego multicast de grupo da origem multicast e permite que o roteador determine rapidamente que todos os hosts restantes estão interessados em receber tráfego multicast de grupo dessa fonte.

Os hosts que são ouvintes multicast enviam os seguintes tipos de mensagens:

  • Relatório de associação — indica que o host deseja ingressar em um grupo multicast específico.

  • Relatório de licença — Indica que o host deseja sair de um grupo multicast específico.

Somente hosts MLDv1 usam dois tipos diferentes de relatórios para indicar se desejam ingressar ou sair de um grupo. Os hosts MLDv2 enviam apenas um tipo de relatório, cujo conteúdo indica se eles desejam ingressar ou sair de um grupo. No entanto, para simplificar, a documentação de espionagem do MLD usa o relatório de associação de termo para um relatório que indica que um host deseja ingressar em um grupo e usa o relatório de licença de termo para um relatório que indica que um host deseja sair de um grupo.

Como os hosts entram e saem de grupos multicast

Os hosts podem ingressar em grupos de multicast de duas maneiras:

  • Enviando um relatório de associação não solicitado que especifica o grupo multicast no qual o host está tentando ingressar.

  • Enviando um relatório de associação em resposta a uma consulta de um roteador multicast.

Um roteador multicast continua a encaminhar o tráfego multicast para uma interface, desde que pelo menos um host nessa interface responda às consultas gerais periódicas que indicam sua associação. Para que um host permaneça membro de um grupo multicast, portanto, ele deve continuar a responder às consultas gerais periódicas.

Os hosts podem sair de grupos de multicast de duas maneiras:

  • Não respondendo a consultas periódicas dentro de um intervalo de tempo definido. Isso resulta no que é conhecido como "licença silenciosa".

  • Enviando um relatório de licença.

Observação:

Se um host estiver conectado ao dispositivo por meio de um hub, o host não sairá automaticamente do grupo multicast se ele se desconectar do hub. O anfitrião permanece um membro do grupo até que a associação ao grupo expire e ocorra uma licença silenciosa. Se outro host se conectar à porta do hub antes que a licença silenciosa ocorra, o novo host poderá receber o tráfego de multicast do grupo até a saída silenciosa, mesmo que nunca tenha enviado um relatório de associação.

Suporte para fontes multicast MLDv2

No MLDv2, um host pode enviar um relatório de associação que inclui uma lista de endereços de origem. Quando o host envia um relatório de associação no modo INCLUDE, ele está interessado no tráfego multicast de grupo somente dessas fontes na lista de endereços de origem. Se o host enviar um relatório de associação no modo EXCLUDE, o host estará interessado no tráfego multicast de grupo de qualquer fonte, exceto as fontes na lista de endereços de origem. Um host também pode enviar um relatório EXCLUDE no qual o parâmetro source-list está vazio, o que é conhecido como relatório EXCLUDE NULL. Um relatório EXCLUDE NULL indica que o host deseja ingressar no grupo multicast e receber pacotes de todas as fontes.

Os dispositivos que dão suporte à bisbilhotagem de MLD dão suporte a relatórios de associação MLDv2 que estão no modo INCLUDE e EXCLUDE.

Interfaces de rastreamento e encaminhamento de MLD

Para determinar como encaminhar o tráfego de multicast, o dispositivo com o rastreamento de MLD habilitado mantém informações sobre as seguintes interfaces em sua tabela de encaminhamento de multicast:

  • Interfaces de roteador multicast — Essas interfaces levam a roteadores multicast ou consultas MLD.

  • Interfaces de membros do grupo — essas interfaces levam a hosts que são membros de grupos multicast.

O dispositivo aprende sobre essas interfaces monitorando o tráfego MLD. Se uma interface receber consultas MLD, o dispositivo adicionará a interface à sua tabela de encaminhamento multicast como uma interface de roteador multicast. Se uma interface receber relatórios de associação para um grupo multicast, o dispositivo adicionará a interface à sua tabela de encaminhamento multicast como uma interface de membro do grupo.

As entradas de tabela para interfaces sobre as quais o dispositivo aprende estão sujeitas a envelhecimento. Por exemplo, se uma interface de roteador multicast aprendida não receber consultas MLD dentro de um determinado intervalo, o dispositivo removerá a entrada dessa interface de sua tabela de encaminhamento multicast.

Observação:

Para que o dispositivo aprenda interfaces de roteador multicast e interfaces de membros do grupo, um consultor MLD deve existir na rede. Para que o próprio dispositivo funcione como um consultor MLD, o MLD deve estar habilitado no dispositivo.

Você pode configurar estaticamente uma interface para ser uma interface de roteador multicast ou uma interface de membro do grupo. O dispositivo adiciona uma interface estática à sua tabela de encaminhamento multicast sem precisar aprender sobre a interface, e a entrada na tabela não está sujeita a envelhecimento. Você pode ter uma combinação de interfaces configuradas estaticamente e aprendidas dinamicamente no dispositivo.

Regras gerais de encaminhamento

O tráfego multicast recebido na interface do dispositivo em uma VLAN na qual o bisbilhotamento de MLD está habilitado é encaminhado de acordo com as regras a seguir.

O tráfego do protocolo MLD é encaminhado da seguinte forma:

  • As consultas gerais de MLD recebidas em uma interface de roteador multicast são encaminhadas para todas as outras interfaces na VLAN.

  • As consultas específicas do grupo MLD recebidas em uma interface de roteador multicast são encaminhadas apenas para as interfaces na VLAN que são membros do grupo.

  • Os relatórios MLD recebidos em uma interface de host são encaminhados para interfaces de roteador multicast na mesma VLAN, mas não para as outras interfaces de host na VLAN.

O tráfego multicast que não é tráfego de protocolo MLD é encaminhado da seguinte forma:

  • Um pacote multicast não registrado — ou seja, um pacote de um grupo que não tem membros atuais — é encaminhado para todas as interfaces de roteador de multicast na VLAN.

  • Um pacote multicast registrado é encaminhado apenas para as interfaces de host na VLAN que são membros do grupo multicast e para todas as interfaces de roteador de multicast na VLAN.

Observação:

Quando o IGMP e o MLD snooping estão habilitados no mesmo VLAN, as interfaces multicast-roteador são criadas como parte da configuração de snooping IGMP e MLD. O tráfego multicast não registrado não é bloqueado e pode ser passado por interfaces de roteador, portanto, devido a limitações de hardware, o tráfego multicast IPv4 não registrado pode ser passado pelas interfaces de roteador de multicast criadas como parte da configuração de rastreamento de MLD, e o tráfego multicast IPv6 não registrado pode passar por interfaces de roteador de multicast criadas como parte da configuração de rastreamento IGMP.

Exemplos de MLD Snooping Encaminhamento multicast

Os exemplos a seguir são fornecidos para ilustrar como a bisbilhotagem de MLD encaminha o tráfego multicast em diferentes topologias:

Cenário 1: Dispositivo encaminhando tráfego multicast para um roteador multicast e hosts

Na topologia mostrada na Figura 2, o dispositivo que atua como um dispositivo de Camada 2 recebe tráfego multicast pertencente ao grupo multicast ff1e::2010 da Fonte A, que está conectada ao roteador multicast. Ele também recebe tráfego multicast pertencente ao grupo multicast ff15::2 da Fonte B, que está conectada diretamente ao dispositivo. Todas as interfaces do dispositivo pertencem à mesma VLAN.

Como o dispositivo recebe consultas MLD do roteador multicast na interface P1, o rastreamento de MLD aprende que a interface P1 é uma interface de roteador multicast e adiciona a interface à sua tabela de encaminhamento multicast. Ele encaminha todas as consultas gerais de MLD recebidas nessa interface para todas as interfaces de host no dispositivo e, por sua vez, encaminha relatórios de associação recebidos dos hosts para a interface do roteador multicast.

No exemplo, os hosts A e C responderam às consultas gerais com relatórios de associação para o grupo ff1e::2010. A bisbilhotagem MLD adiciona as interfaces P2 e P4 à sua tabela de encaminhamento multicast como interfaces de membros para o grupo ff1e::2010. Ele encaminha o tráfego multicast de grupo recebido da Origem A para os Hosts A e C, mas não para os Hosts B e D.

O anfitrião B respondeu às perguntas gerais com um relatório de associação para o grupo ff15::2. O dispositivo adiciona a interface P3 à sua tabela de encaminhamento multicast como uma interface de membro para o grupo ff15::2 e encaminha o tráfego multicast que recebe da Origem B para o Host B. O dispositivo também encaminha o tráfego multicast que recebe da Origem B para a interface P1 do roteador multicast.

Figura 2: Cenário 1: Dispositivo encaminhando tráfego multicast para um roteador multicast e hosts Multicast routing diagram: Multicast Router connects Sources A ff1e::2010 and B ff15::2 to Hosts A, B, C, and D. Arrows show traffic flow.

Cenário 2: Dispositivo encaminhando tráfego multicast para outro dispositivo

Na topologia mostrada na Figura 3, uma fonte de multicast está conectada ao Dispositivo A. O Dispositivo A, por sua vez, está conectado a outro dispositivo, o Dispositivo B. Os hosts nos Dispositivos A e B são membros potenciais do grupo de multicast. Ambos os dispositivos estão agindo como dispositivos de Camada 2, e todas as interfaces nos dispositivos são membros da mesma VLAN.

O dispositivo A recebe consultas MLD do roteador multicast na interface P1, tornando a interface P1 uma interface de roteador multicast para o dispositivo A. O dispositivo A encaminha todas as consultas gerais recebidas nessa interface para as outras interfaces do dispositivo, incluindo a interface que conecta o dispositivo B. Como o Dispositivo B recebe as consultas MLD encaminhadas na interface P6, P6 é a interface de roteador multicast para o Dispositivo B. O Dispositivo B encaminha o relatório de associação que recebe do Host C para o Dispositivo A por meio de sua interface de roteador multicast. O dispositivo A encaminha o relatório de associação para sua interface de roteador multicast, inclui a interface P5 em sua tabela de encaminhamento multicast como uma interface de membro do grupo e encaminha o tráfego multicast da origem para o dispositivo B.

Figura 3: Cenário 2: Dispositivo encaminhando tráfego multicast para outro dispositivo Network topology diagram showing multicast communication: Source server sends multicast traffic through a router to Switch A and Switch B. Hosts A and B connect to Switch A; Hosts C and D connect to Switch B.

Em determinadas implementações, talvez seja necessário configurar P6 no Dispositivo B como uma interface de roteador multicast estática para evitar um atraso em um host que recebe tráfego multicast. Por exemplo, se o Dispositivo B receber relatórios de associação não solicitados de seus hosts antes de saber qual interface é sua interface de roteador multicast, ele não encaminhará esses relatórios para o Dispositivo A. Se o Dispositivo A receber tráfego multicast, ele não encaminhará o tráfego para o Dispositivo B, porque não recebeu nenhum relatório de associação na interface P5. Esse problema será resolvido quando o roteador multicast enviar sua próxima consulta geral; no entanto, isso pode causar um atraso no host que recebe tráfego multicast. Você pode configurar estaticamente a interface P6 como uma interface de roteador multicast para resolver esse problema.

Cenário 3: dispositivo conectado apenas a hosts (sem MLD Consultier)

Na topologia mostrada na Figura 4, o dispositivo está conectado a uma fonte multicast e a hosts. Não há roteador multicast nessa topologia — portanto, não há consulta MLD. Sem um consultor MLD para responder, um anfitrião não envia relatórios periódicos de associação. Como resultado, mesmo que o host envie um relatório de associação não solicitado para ingressar em um grupo multicast, sua associação no grupo multicast atingirá o tempo limite.

Para que o rastreamento de MLD funcione corretamente nessa rede para que o dispositivo encaminhe o tráfego multicast apenas para os hosts A e C, você pode:

  • Configure as interfaces P2 e P4 como interfaces estáticas de membros do grupo.

  • Configure uma interface VLAN roteada (RVI), também conhecida como interface de roteamento e ponte integrada (IRB), na VLAN e habilite o MLD nela. Nesse caso, o próprio dispositivo atua como um consultor MLD e os hosts podem ingressar dinamicamente no grupo multicast e atualizar sua associação de grupo respondendo às consultas.

Figura 4: Cenário 3: Dispositivo conectado apenas a hosts (sem MLD Consultier) Network topology diagram showing data flow from a source device to multiple hosts through a switch in a LAN setup.

Cenário 4: Encaminhamento de dispositivos de Camada 2/Camada 3 tráfego multicast entre VLANs

Na topologia mostrada na Figura 5, uma fonte multicast, o roteador multicast A e os hosts A e B estão conectados ao dispositivo e estão na VLAN 10. O roteador multicast B e os hosts C e D também estão conectados ao dispositivo e estão na VLAN 20.

Em um ambiente de Camada 2 puro, o tráfego não é encaminhado entre VLANs. Para que o Host C receba o tráfego multicast da origem na VLAN 10, os RVIs (ou interfaces IRB) devem ser criados na VLAN 10 e na VLAN 20 para permitir o roteamento do tráfego multicast entre as VLANs.

Figura 5: Cenário 4: Dispositivo de Camada 2/Camada 3 encaminhando tráfego multicast entre VLANs Network topology with multicast routing and VLANs: Source 11.1.1.10 sends multicast traffic via Multicast Routers A and B to Hosts A and B on VLAN 10 and Hosts C and D on VLAN 20.

Comportamento de espionagem de MLD específico da plataforma

Use o Explorador de Recursos para confirmar o suporte à plataforma e à versão para recursos específicos.

Use a tabela a seguir para analisar o comportamento específico da sua plataforma.

Tabela 1: Comportamento de espionagem de MLD específico da plataforma

Plataforma

Diferença

Firewalls da Série SRX, switches da Série QFX e switches da Série EX que executam bisbilhotamento de MLD, exceto para switches EX9200

  • Não ofereça suporte ao encaminhamento por origem. Em vez disso, o dispositivo consolida todos os relatórios de modo INCLUDE e EXCLUDE que recebe em uma VLAN para um grupo especificado em uma única rota que inclui todas as fontes multicast para esse grupo, com o próximo salto sendo todas as interfaces que têm receptores interessados para o grupo. Como resultado, os receptores interessados na VLAN podem receber tráfego de uma fonte que não incluíram em seu relatório INCLUDE ou de uma fonte que excluíram em seu relatório EXCLUDE. Por exemplo, se o Host 1 quiser tráfego para o grupo G da Origem A e o Host 2 quiser tráfego para o grupo G da Origem B, ambos receberão tráfego para o grupo G, independentemente de A ou B enviar o tráfego.

Documentação relacionada