NESTA PÁGINA
Entendendo o MLD Snooping
A espionagem do Multicast Listener Discovery (MLD) restringe a inundação do tráfego multicast IPv6 em VLANs. Quando a espionagem MLD é habilitada em uma 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 então encaminha tráfego multicast apenas para essas interfaces na VLAN que são conectadas a receptores interessados em vez de inundar o tráfego para todas as interfaces.
O snooping MLD oferece suporte a MLD versão 1 (MLDv1) e MLDv2. Para obter mais informações 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 espionagem 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 inundados para todas as portas em uma VLAN.
Improved security— Os 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, exceto pela interface que é a fonte do tráfego multicast. Esse comportamento pode consumir quantidades significativas de largura de banda.
Você pode habilitar a espionagem MLD para evitar essa inundação. Ao ativar a espionagem MLD, o dispositivo monitora mensagens MLD entre receptores (hosts) e roteadores multicast e usa o conteúdo das mensagens para construir 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 sistema de espionagem MLD habilitado.
Tipos de mensagem de MLD
Os roteadores multicast usam o MLD para aprender, para cada uma de suas redes físicas anexadas, quais grupos têm espectadores interessados. Em qualquer sub-rede, um roteador multicast é eleito para atuar como um querier MLD. O querier MLD 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 deixa o grupo multicast e permite que o roteador determine rapidamente se algum hosts remanescentes estão interessados no grupo.
Consulta específica de grupo e fonte — (somente na versão 2 do MLD) Pergunta se algum host está ouvindo o tráfego multicast em grupo a partir 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 da fonte multicast e permite que o roteador determine rapidamente se os hosts remanescentes estão interessados em receber tráfego multicast de grupo dessa fonte.
Os hosts que são escutadores multicast enviam os seguintes tipos de mensagens:
Relatório de associação — indica que o host deseja participar de um grupo multicast específico.
Deixe o relatório — indica que o host deseja 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, com o conteúdo indicando se querem participar ou deixar um grupo. No entanto, para o bem da simplicidade, a documentação de espionagem do MLD usa o relatório de filiação de termo 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 host 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 associação não solicitado que especifica o grupo multicast que o host está tentando participar.
Ao enviar um relatório de associação em resposta a uma consulta de um roteador multicast.
Um roteador multicast continua a encaminhar 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 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 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 associação do 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, embora 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, o host tem interesse no tráfego multicast em grupo apenas dessas fontes na lista de endereços de origem. Se o host enviar um relatório de associação no modo EXCLUDE, o host terá interesse no tráfego multicast em grupo de qualquer fonte , exceto nas 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 deseja se juntar ao grupo multicast e receber pacotes de todas as fontes.
Dispositivos que oferecem suporte a espionagem MLD oferecem suporte a relatórios de associação MLDv2 que estão no modo INCLUDE e EXCLUDE. No entanto, os firewalls 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 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 eles excluiram em seu relatório EXCLUDE. Por exemplo, se o Host 1 quiser tráfego para o grupo G da Fonte A e host 2 quiser tráfego para o grupo G da Fonte B, ambos recebem tráfego para o grupo G, independentemente de A ou B enviar o tráfego.
Interfaces de snooping e encaminhamento MLD
Para determinar como encaminhar o tráfego multicast, o dispositivo habilitado para snooping 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 MLD, o dispositivo adiciona 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 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 multicast-router aprendida não receber consultas MLD em um determinado intervalo, o dispositivo remove a entrada para essa 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 dispositivo em si 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 configuradas e aprendidas dinamicamente no dispositivo.
Regras gerais de encaminhamento
O tráfego multicast recebido na interface do dispositivo em uma VLAN na qual a espionagem MLD é habilitada é encaminhada 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 ambos 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 do IGMP.
Exemplos de MLD Snooping Multicast Forwarding
Os exemplos a seguir são fornecidos para ilustrar como o MLD encaminha tráfego multicast em diferentes topologias:
- Cenário 1: Encaminhamento de dispositivos de tráfego multicast para um roteador multicast e hosts
- Cenário 2: Encaminhamento de dispositivos de 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: Encaminhamento de dispositivos 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 MLD do roteador multicast na interface P1, o MLD snooping descobre que a interface P1 é uma interface de roteador multicast e adiciona a interface à sua tabela de encaminhamento multicast. Ele encaminha quaisquer consultas gerais de MLD que recebe nesta interface para todas as interfaces de host no dispositivo e, por sua vez, encaminha os relatórios de associação que recebe dos hosts para a interface de roteador multicast.
No exemplo, hosts A e C responderam às consultas gerais com relatórios de associação para o grupo ff1e::2010. A snooping 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 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 Fonte B para o 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: Encaminhamento de dispositivos de tráfego multicast para outro dispositivo
No programa de topologia da Figura 3, uma fonte multicast é conectada ao Dispositivo A. O dispositivo A, por sua vez, está conectado a outro dispositivo, o Dispositivo B. Os hosts do 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 multicast-roteador 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 MLD encaminhadas na interface P6, p6 é a interface multicast-roteador para dispositivo B. O dispositivo B encaminha o relatório de associaçã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 associação para sua interface de roteador multicast, inclui interface P5 em sua tabela de encaminhamento multicast como uma interface de membro do grupo e encaminha tráfego multicast da fonte para o Dispositivo B.
Em determinadas implementações, você pode ter que configurar o P6 no Dispositivo B como uma interface multicast-roteador estática para evitar um atraso no tráfego multicast que recebe host. 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 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, pois 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 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 é conectado a uma fonte multicast e a 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 associação. Como resultado, mesmo que o host envie um relatório de associação não solicitado para se juntar a um grupo multicast, sua adesão ao grupo multicast sairá.
Para que a espionagem MLD funcione corretamente nesta rede para que o dispositivo encaminhe tráfego multicast apenas para Hosts A e C, você também pode:
Configure interfaces P2 e P4 como interfaces estáticas de membros de grupo.
Configure uma interface VLAN roteada (RVI), também referida como uma interface integrada de roteamento e ponte (IRB), na VLAN e habilite o MLD nele. Neste caso, o dispositivo em si atua como um querier MLD, e os hosts podem se juntar dinamicamente ao grupo multicast e renovar sua associação de 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 na VLAN 10. O roteador multicast B e 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 fonte em VLAN 10, as RVIs (ou interfaces IRB) devem ser criadas no VLAN 10 e VLAN 20 para permitir o roteamento do tráfego multicast entre as VLANs.
