NESTA PÁGINA
Entender o MLD Snooping
A espionagem do Multicast Listener Discovery (MLD) limita a inundação do tráfego multicast IPv6 em VLANs. Quando o bisbilhotamento MLD é habilitado em um VLAN, um dispositivo da Juniper Networks examina mensagens MLD entre hosts e roteadores multicast e descobre quais hosts estão interessados em receber tráfego para um grupo multicast. Com base no que aprende, o dispositivo encaminha o tráfego multicast apenas para essas interfaces na VLAN que estão conectadas a receptores interessados em vez de inundar o tráfego para todas as interfaces.
A espionagem MLD oferece suporte para MLD versão 1 (MLDv1) e MLDv2. Para obter detalhes sobre MLDv1 e MLDv2, veja os seguintes padrões:
MLDv1 — veja RFC 2710, Multicast Listener Discovery (MLD) para IPv6.
MLDv2 — veja RFC 3810, Multicast Listener Discovery Version 2 (MLDv2) para IPv6.
Benefícios do MLD Snooping
Optimized bandwidth utilization— O principal benefício da bisbilhotagem do MLD é reduzir a inundação de pacotes. Os dados multicast IPv6 são encaminhados seletivamente para uma lista de portas que desejam receber os dados, em vez de serem alagados 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 à VLAN do dispositivo, com exceção da interface que é a fonte do tráfego multicast. Esse comportamento pode consumir quantidades significativas de largura de banda.
Você pode habilitar a bisbilhotagem da MLD para evitar essa inundação. Quando você permite a espionagem MLD, o dispositivo monitora mensagens MLD entre receptores (hosts) e roteadores multicast e usa o conteúdo das mensagens para criar uma tabela de encaminhamento multicast IPv6 — um banco de dados de grupos 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 o uso de bisbilhotamento MLD habilitado.
Tipos de mensagem MLD
Os roteadores multicast usam o 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 querier MLD. O MLD querier envia os seguintes tipos de consultas aos hosts:
Consulta geral — pergunta se algum host está ouvindo algum grupo.
Consulta específica do grupo — pergunta se algum host está ouvindo 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 hosts restantes está interessado no grupo.
Consulta específica de grupo e fonte — (somente versão MLD 2) Pergunte se algum host está ouvindo o tráfego multicast em 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 em grupo a partir da fonte multicast e permite que o roteador determine rapidamente quaisquer hosts restantes estão interessados em receber tráfego multicast em grupo dessa fonte.
Os hosts que são ouvintes multicast enviam os seguintes tipos de mensagens:
Relatório de membros — indica que o host quer se juntar a um grupo multicast específico.
Deixe o relatório — indica que o host quer deixar um grupo multicast específico.
Apenas os hosts MLDv1 usam dois tipos diferentes de relatórios para indicar se querem participar ou deixar um grupo. Os hosts MLDv2 enviam apenas um tipo de relatório, do qual o conteúdo indica se eles querem participar ou deixar um grupo. No entanto, por causa da simplicidade, a documentação de bisbilhotamento do MLD usa o termo relatório de adesão para um relatório que indica que um host quer se juntar a um grupo e usa o relatório de licença de termo para um relatório que indica que um anfitrião quer deixar um grupo.
Como os hosts se juntam e deixam grupos multicast
Os hosts podem se juntar a grupos multicast de duas maneiras:
Ao enviar um relatório de membros não solicitado que especifica o grupo multicast que o host está tentando participar.
Ao enviar um relatório de membros 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 adesã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 deixar grupos multicast de duas maneiras:
Não respondendo a consultas periódicas em um intervalo de tempo definido. Isso resulta no que é conhecido como uma "licença silenciosa".
Enviando um relatório de licença.
Se um host estiver conectado ao dispositivo por meio de um hub, o host não deixará automaticamente o grupo multicast se ele se desconectar do hub. O anfitrião continua sendo um membro do grupo até que a adesão ao grupo saia e ocorra uma licença silenciosa. Se outro host se conectar à porta do hub antes que a licença silenciosa ocorra, o novo host pode receber o tráfego multicast do grupo até a licença silenciosa, mesmo que nunca tenha enviado um relatório de adesão.
Suporte para fontes MLDv2 Multicast
No MLDv2, um host pode enviar um relatório de adesão que inclui uma lista de endereços de origem. Quando o host envia um relatório de adesão no modo INCLUDE, o host está interessado no tráfego multicast em grupo apenas a partir dessas fontes na lista de endereços de origem. Se o host enviar um relatório de adesão no modo EXCLUDE, o host está interessado em tráfego multicast em grupo de qualquer fonte , exceto as fontes da lista de endereços de origem. Um host também pode enviar um relatório EXCLUDE no qual o parâmetro da lista de origem está vazio, que é conhecido como um relatório EXCLUDE NULL. Um relatório EXCLUDE NULL indica que o host quer se juntar ao grupo multicast e receber pacotes de todas as fontes.
Dispositivos que oferecem suporte a bisbilhotamento MLDv2 oferecem relatórios de membros que estão no modo INCLUDE e EXCLUDE. No entanto, os dispositivos da Série SRX, switches da Série QFX e switches da Série EX que executam a espionagem MLD, com exceção dos switches EX9200, não oferecem suporte ao encaminhamento por fonte. 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 hop 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 eles não incluíram em seu relatório INCLUDE ou de uma fonte que eles excluiram em seu relatório EXCLUDE. Por exemplo, se o Host 1 quiser tráfego para o grupo G da Fonte A e do Host 2 quiser tráfego para o grupo G da Fonte B, ambos receberão tráfego para o grupo G, independentemente de A ou B enviarem o tráfego.
Interfaces de bisbilhotamento e encaminhamento MLD
Para determinar como encaminhar o tráfego multicast, o dispositivo habilitado para bisbilhotamento MLD mantém informações sobre as seguintes interfaces em sua tabela de encaminhamento multicast:
Interfaces de roteador multicast — essas interfaces levam a roteadores multicast ou queriers MLD.
Interfaces de membros de 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 de MLD, o dispositivo adiciona a interface à sua tabela de encaminhamento multicast como uma interface de roteador multicast. Se uma interface receber relatórios de membros de um grupo multicast, o dispositivo adiciona 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 ao envelhecimento. Por exemplo, se uma interface de roteador multicast aprendida não receber consultas MLD em um determinado intervalo, o dispositivo remove a entrada dessa interface de sua tabela de encaminhamento multicast.
Para que o dispositivo aprenda interfaces de roteador multicast e interfaces de membros de grupo, um querier MLD deve existir na rede. Para que o próprio dispositivo funcione como um querier MLD, o MLD deve ser habilitado no dispositivo.
Você pode configurar estaticamente uma interface para ser uma interface de roteador multicast ou uma interface de membro de 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 ao envelhecimento. Você pode ter uma mistura de interfaces estaticamente configuradas e aprendidas dinamicamente no dispositivo.
Regras de encaminhamento geral
O tráfego multicast recebido na interface do dispositivo em um VLAN no qual a espionagem MLD é habilitada é encaminhado de acordo com as seguintes regras.
O tráfego de 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 da VLAN.
As consultas específicas do grupo MLD recebidas em uma interface de roteador multicast são encaminhadas apenas para essas 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 para um grupo que não tem membros atuais — é encaminhado para todas as interfaces de roteador multicast na VLAN.
Um pacote multicast registrado é encaminhado apenas para essas interfaces de host na VLAN que são membros do grupo multicast e para todas as interfaces de roteador multicast na VLAN.
Quando o IGMP e o MLD são habilitados na mesma VLAN, interfaces de roteador multicast são criadas como parte da configuração de espionagem 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 multicast criadas como parte da configuração de espionagem MLD, e o tráfego multicast IPv6 não registrado pode passar por interfaces de roteador multicast criadas como parte da configuração de espionagem IGMP.
Exemplos do MLD Snooping Multicast Forwarding
Os exemplos a seguir são fornecidos para ilustrar como o MLD encaminha o tráfego multicast em diferentes topologias:
- Cenário 1: o encaminhamento de tráfego multicast para um roteador multicast e hosts
- Cenário 2: dispositivo que encaminha tráfego multicast para outro dispositivo
- Cenário 3: Dispositivo conectado apenas a hosts (sem querier MLD)
- Cenário 4: Dispositivo de Camada 2/Camada 3 encaminhando tráfego multicast entre VLANs
Cenário 1: o encaminhamento de 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á conectado ao roteador multicast. Ele também recebe tráfego multicast pertencente ao grupo multicast ff15:2 da Fonte B, que está conectado diretamente ao dispositivo. Todas as interfaces do dispositivo pertencem à mesma VLAN.
Como o dispositivo recebe consultas de MLD do roteador multicast na interface P1, o MLD snooping 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 que recebe nesta interface para todas as interfaces de host do dispositivo e, por sua vez, encaminha os relatórios de membros que recebe dos hosts para a interface do roteador multicast.
No exemplo, hosts A e C responderam às consultas gerais com relatórios de membros para o grupo ff1e::2010. A espionagem MLD adiciona interfaces P2 e P4 à sua tabela de encaminhamento multicast como interfaces de membro para o grupo ff1e::2010. Ele encaminha o tráfego multicast do grupo recebido da Fonte A para Hosts A e C, mas não para hosts B e D.
O Host B respondeu às consultas gerais com um relatório de adesão para o grupo ff15::2. O dispositivo adiciona a interface P3 à sua tabela de encaminhamento multicast como interface de membro para o grupo ff15::2 e encaminha o tráfego multicast que recebe da Fonte B ao Host B. O dispositivo também encaminha o tráfego multicast que recebe da Fonte B para a interface de roteador multicast P1.
Cenário 2: dispositivo que encaminha tráfego multicast para outro dispositivo
No programa de topologia da Figura 3, uma fonte multicast está conectada ao dispositivo A. O dispositivo A, por sua vez, está conectado a outro dispositivo, o Dispositivo B. Hosts no Dispositivo A e B são membros potenciais do grupo multicast. Ambos os dispositivos estão atuando como dispositivos de Camada 2, e todas as interfaces nos dispositivos são membros da mesma VLAN.
O dispositivo A recebe consultas de MLD do roteador multicast na interface P1, tornando a interface P1 uma interface de roteador multicast para dispositivo A. O dispositivo A encaminha todas as consultas gerais que recebe nesta interface para as outras interfaces do dispositivo, incluindo a interface que conecta o Dispositivo B. Como o Dispositivo B recebe as consultas de MLD encaminhadas na interface P6, o P6 é a interface de roteador multicast para dispositivo B. O dispositivo B encaminha o relatório de adesão que recebe do Host C ao Dispositivo A por meio de sua interface de roteador multicast. O Dispositivo A encaminha o relatório de membros para sua interface multicast-router, 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 ao Dispositivo B.
Em determinadas implementações, você pode ter que configurar o P6 no Dispositivo B como uma interface estática de roteador multicast para evitar um atraso em um host recebendo tráfego multicast. Por exemplo, se o Dispositivo B receber relatórios de membros não solicitados de seus hosts antes de saber qual interface é sua interface de roteador multicast, ele não encaminha esses relatórios para o Dispositivo A. Se o dispositivo A receber tráfego multicast, ele não encaminha o tráfego para o dispositivo B, porque não recebeu nenhum relatório de adesão na interface P5. Esse problema será resolvido quando o roteador multicast enviar sua próxima consulta geral; no entanto, pode causar um atraso no host recebendo 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 querier MLD)
Na topologia mostrada na Figura 4, o dispositivo está conectado a uma fonte multicast e aos hosts. Não há roteador multicast nesta topologia — portanto, não há nenhum querier MLD. Sem um querier MLD para responder, um host não envia relatórios periódicos de membros. Como resultado, mesmo que o host envie um relatório de membros não solicitado para se juntar a um grupo multicast, sua participação no grupo multicast será um tempo.
Para que o MLD funcione corretamente nesta rede para que o dispositivo encaminhe tráfego multicast apenas para hosts A e C, você pode:
Configure interfaces P2 e P4 como interfaces estáticas de membros de grupo.
Configure uma interface VLAN roteada (RVI), também conhecida como uma interface integrada de roteamento e ponte (IRB), no VLAN e habilite o MLD nela. Nesse caso, o próprio dispositivo atua como um querier MLD, e os hosts podem se juntar dinamicamente ao grupo multicast e renovar sua participação em grupo respondendo às consultas.
Cenário 4: Dispositivo de Camada 2/Camada 3 encaminhando tráfego multicast entre VLANs
Na topologia mostrada na Figura 5, uma fonte multicast, o Roteador Multicast A e hosts A e B estão conectados ao dispositivo e estão no VLAN 10. O roteador multicast B e os hosts C e D também estão conectados ao dispositivo e estão no 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 fonte em VLAN 10, as RVIs (ou interfaces IRB) devem ser criadas em VLAN 10 e VLAN 20 para permitir o roteamento do tráfego multicast entre as VLANs.
