Exemplo: Configuração de snooping multicast
Entendendo o Multicast Snooping
Dispositivos de rede, como roteadores, operam principalmente no nível de pacote, ou Camada 3. Outros dispositivos de rede, como pontes ou switches LAN, operam principalmente no nível do quadro, ou Camada 2. A multicasting funciona principalmente no nível de pacote, Camada 3, mas há uma maneira de mapear endereços de grupo multicast IP de Camada 3 para endereços de grupo multicast MAC de Camada 2 no nível do quadro.
Os roteadores podem lidar com as informações de endereçamento de Camada 2 e Camada 3 porque o quadro e seus endereços devem ser processados para acessar o pacote encapsulado dentro. Os roteadores podem executar protocolos multicast de Camada 3, como PIM ou IGMP, e determinar onde encaminhar conteúdo multicast ou quando um host em uma interface se junta ou deixa um grupo. No entanto, pontes e switches LAN, como dispositivos de Camada 2, não devem ter acesso às informações multicast dentro dos pacotes que seus quadros transportam.
Como então são as pontes e outros dispositivos de Camada 2 para determinar quando um dispositivo em uma interface se junta ou deixa uma árvore multicast, ou se um host em uma LAN anexada quer receber o conteúdo de um determinado grupo multicast?
A resposta é que o dispositivo de Camada 2 implemente espionagem multicast. Bisbilhotamento multicast é um termo geral e se aplica ao processo de um dispositivo de Camada 2 "bisbilhotando" o conteúdo do pacote de Camada 3 para determinar quais ações são tomadas para processar ou encaminhar um quadro. Existem formas mais específicas de bisbilhotar, como bisbilhotar IGMP ou bisbilhotar PIM. Em todos os casos, a espionagem envolve um dispositivo configurado para funcionar na Camada 2 tendo acesso a informações de Camada 3 (pacote) normalmente "proibidas". Snooping torna a multicasting mais eficiente nesses dispositivos.
Veja também
Entendendo a snooping multicast e a proteção raiz VPLS
A snooping ocorre quando um protocolo de Camada 2, como um protocolo de spanning tree, está ciente dos detalhes operacionais de um protocolo de Camada 3, como o Protocolo de gerenciamento de grupos de Internet (IGMP) ou outro protocolo multicast. O snooping é necessário quando dispositivos de Camada 2, como switches VLAN, devem estar cientes de informações de Camada 3, como os endereços de controle de acesso de mídia (MAC) de membros de um grupo multicast.
A proteção raiz VPLS é um processo de protocolo de árvores de abrangência no qual apenas uma interface em um ambiente multihomed está encaminhando ativamente quadros de protocolo de árvores de abrangência. Isso protege a raiz da árvore de abrangência contra loops de ponte, mas também impede que ambos os dispositivos na topologia multihomed informem informações bisbilhotadas, como relatórios de associação de IGMP.
Por exemplo, considere uma coleção de hosts com capacidade multicast conectados a dois roteadores de borda do cliente (CE1 e CE2) conectados entre si (um link CE1-CE2 está configurado) e roteadores multihomed a dois roteadores de borda de provedor (PE) (PE1 e PE2, respectivamente). O PE ativo só recebe informações de protocolo de spanning tree encaminhadas no link PE-CE ativo, devido à operação de proteção raiz. Enquanto o link CE1-CE2 estiver operacional, isso não é um problema. No entanto, se a ligação entre CE1 e CE2 falhar, e o outro PE se tornar o link ativo de protocolo de spanning tree, nenhuma informação de espionagem multicast estará disponível no novo PE ativo. O novo PE ativo não encaminhará tráfego multicast para o CE e os hosts atendidos por este roteador CE.
A interrupção do serviço é corrigida assim que os hosts enviarem novos relatórios IGMP de associação de grupo aos roteadores CE. No entanto, a interrupção do serviço pode ser evitada se as informações de espionagem multicast estiverem disponíveis para ambos os PEs, apesar da operação normal de proteção de raiz de protocolo de spanning tree.
Você pode configurar a espionagem multicast para ignorar mensagens sobre mudanças na topologia de árvores em domínios de ponte em switches virtuais e switches de roteamento padrão de domínios de ponte. Você pode usar o ignore-stp-topology-change comando para ignorar mensagens sobre mudanças na topologia de árvores
Veja também
Configuração do Multicast Snooping
Para configurar os parâmetros gerais de snooping multicast para roteadores da Série MX, inclua a multicast-snooping-options declaração:
multicast-snooping-options { flood-groups [ ip-addresses ]; forwarding-cache { threshold suppress value <reuse value>; } graceful-restart <restart-duration seconds>; ignore-stp-topology-change; multichassis-lag-replicate-state; nexthop-hold-time milliseconds; traceoptions { file filename <files number> <size size> <world-readable | no-world-readable>; flag flag <flag-modifier> <disable>; } }
Você pode incluir essa declaração nos seguintes níveis de hierarquia:
[edit routing-instances routing-instance-name][edit logical-systems logical-system-name routing-instances routing-instance-name]
Por padrão, a espionagem multicast é desativada. Você pode habilitar a espionagem multicast em tipos de instâncias de switch virtual ou VPLS na hierarquia de instâncias.
Se houver vários domínios de ponte configurados em uma instância de VPLS ou switch virtual, as opções de snooping multicast configuradas no nível de instância se aplicam a todos os domínios da ponte.
A ignore-stp-topology-change declaração é compatível apenas com o tipo de instância de roteamento de switch virtual e não é suportada sob a [edit logical-systems] hierarquia.
A nexthop-hold-time declaração é apoiada apenas na [edit routing-instances routing-instance-name] hierarquia, e apenas para um tipo de switch virtual ou vpls de instância.
Veja também
Exemplo: Configuração de snooping multicast
Este exemplo mostra como configurar a espionagem multicast em um cenário de instância de roteamento VPLS ou ponte.
Requisitos
Este exemplo usa os seguintes componentes de hardware:
Um roteador da Série MX
Um dispositivo de Camada 3 funcionando como um roteador multicast
Antes de começar:
Configure as interfaces.
Configure um protocolo de gateway interior. Consulte a biblioteca de protocolos de roteamento do Junos OS para dispositivos de roteamento.
Configure um protocolo multicast. Esse recurso funciona com os seguintes protocolos multicast:
DVMRP
PIM-DM
PIM-SM
PIM-SSM
Visão geral e topologia
A espionagem do IGMP impede que os dispositivos de Camada 2 indiscriminadamente indiscriminem o tráfego multicast em todas as interfaces. As configurações que você configura para espionagem multicast ajudam a gerenciar o comportamento da espionagem do IGMP.
Você pode configurar opções de espionagem multicast na instância mestre padrão e em instâncias individuais de ponte ou VPLS. A configuração padrão de instância mestre é global e se aplica a todas as instâncias de ponte individual ou VPLS no roteador lógico. A configuração para instâncias individuais substitui a configuração global.
Este exemplo inclui as seguintes declarações:
grupos de inundação — permite listar endereços de grupos multicast para os quais o tráfego deve ser inundado. Esta configuração, se útil para garantir que a espionagem do IGMP não impeça inundações multicast necessárias. O bloco de endereços multicast de 224.0.0.1 a 224.0.0.255 está reservado para uso local de fios. Grupos nessa faixa são designados para vários usos, incluindo protocolos de roteamento e mecanismos de descoberta local. Por exemplo, o OSPF usa 224.0.0.5 para todos os roteadores OSPF.
encaminhamento-cache — especifica como as entradas de encaminhamento são envelhecidas e como o número de entradas é controlado.
Você pode configurar valores de limite no cache de encaminhamento para suprimir (suspender) a espionagem quando as entradas de cache atingirem um determinado máximo e reutilizar o cache quando o número cair para outro valor limite. Por padrão, nenhum valor limite é habilitado no roteador.
O limiar de supressão suprime novas entradas de cache de encaminhamento multicast. Um limiar de reutilização opcional especifica o ponto em que o roteador começa a criar novas entradas de cache de encaminhamento multicast. O intervalo para ambos os limiares é de 1 a 200.000. Se configurado, o valor de reutilização deve ser menor do que o valor de supressão. O valor de supressão é obrigatório. Se você não especificar o valor de reutilização opcional, o número de entradas de cache de encaminhamento multicast se limita ao valor de supressão. Uma nova entrada é criada assim que o número de entradas de cache de encaminhamento multicast ficar abaixo do valor de supressão.
reinicialização graciosa — configura o tempo após o qual as rotas aprendidas antes de uma reinicialização são substituídas por rotas relvadas. Se a reinicialização graciosa para espionagem multicast for desativada, as informações de snooping são perdidas após a reinicialização de um mecanismo de roteamento.
Por padrão, a duração graciosa da reinicialização é de 180 segundos (3 minutos). Você pode definir esse valor entre 0 e 300 segundos. Se você definir a duração para 0, a reinicialização graciosa será efetivamente desativada. Defina esse valor um pouco maior do que o intervalo de resposta a consultas IGMP.
ignore-stp-topology-change — configura o roteador da Série MX para ignorar mensagens sobre a mudança de estado da topologia de árvores de abrangência.
Por padrão, o processo de espionagem IGMP em um roteador da Série MX detecta alterações de estado da interface feitas por qualquer um dos protocolos de árvores de abrangência (STPs).
Em um ambiente multihoming VPLS onde dois roteadores PE estão conectados a dois roteadores CE interconectados e a proteção raiz stp é habilitada nos roteadores PE, uma das interfaces de roteador PE está em estado de encaminhamento e a outra está em estado de bloqueio.
Se o enlace que interconecta os dois roteadores CE falhar, a interface do roteador PE no bloqueio de transições de estado para o estado de encaminhamento.
A interface do roteador PE não espera receber relatórios de associação em resposta à próxima consulta geral ou específica do grupo. Em vez disso, o processo de espionagem do IGMP envia uma mensagem de consulta geral em direção ao roteador CE. Os hosts conectados ao roteador CE respondem com relatórios para todos os grupos em que estão interessados.
Quando a interconexão dos dois roteadores CE é restaurada, o estado original da árvore de abrangência em ambos os roteadores PE é restaurada. O PE de encaminhamento recebe uma mensagem de mudança de topologia de árvores de abrangência e envia uma mensagem de consulta geral em direção ao roteador CE para reconstruir imediatamente o estado de associação do grupo.
Nota:A
ignore-stp-topology-changedeclaração é compatível apenas com o tipo de instância de roteamento de switch virtual .
Topologia
A Figura 1 mostra uma topologia multihoming VPLS na qual uma rede do cliente tem dois dispositivos CE com um link entre eles. Cada CE está conectado a um PE.
multihoming VPLS
Configuração
Procedimento
Configuração rápida da CLI
Para configurar rapidamente este exemplo, copie os seguintes comandos, cole-os em um arquivo de texto, remova quaisquer quebras de linha, altere todos os detalhes necessários para combinar com a configuração da sua rede, copiar e colar os comandos na CLI no nível de [edit] hierarquia e, em seguida, entrar no commit modo de configuração.
set bridge-domains domain1 multicast-snooping-options forwarding-cache threshold suppress 100 set bridge-domains domain1 multicast-snooping-options forwarding-cache threshold reuse 50 set bridge-domains domain1 multicast-snooping-options graceful-restart restart-duration 120 set routing-instances ce1 instance-type virtual-switch set routing-instances ce1 bridge-domains domain1 domain-type bridge set routing-instances ce1 bridge-domains domain1 vlan-id 100 set routing-instances ce1 bridge-domains domain1 interface ge-0/3/9.0 set routing-instances ce1 bridge-domains domain1 interface ge-0/0/6.0 set routing-instances ce1 bridge-domains domain1 multicast-snooping-options flood-groups 224.0.0.5 set routing-instances ce1 bridge-domains domain1 multicast-snooping-options ignore-stp-topology-change
Procedimento passo a passo
O exemplo a seguir exige que você navegue por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar na CLI, consulte o Guia de usuário do Junos OS CLI.
Para configurar a espionagem do IGMP:
Configure configurações de snooping multicast na instância de roteamento mestre.
[edit bridge-domains domain1] user@host# set multicast-snooping-options forwarding-cache threshold suppress 100 reuse 50 user@host# set multicast-snooping-options graceful-restart 120
Configure a instância de roteamento.
[edit routing-instances ce1] user@host# set instance-type virtual-switch
Configure o domínio da ponte na instância de roteamento.
[edit routing-instances ce1 bridge-domains domain1] user@host# set domain-type bridge user@host# set interface ge-0/0/6.0 user@host# set interface ge-0/3/9.0 user@host# set vlan-id 100
Configure grupos de inundação.
[edit routing-instances ce1 bridge-domains domain1] user@host# set multicast-snooping-options flood-groups 224.0.0.5
Configure o roteador para ignorar mensagens sobre mudanças de estado de topologia de árvores de abrangência.
[edit routing-instances ce1 bridge-domains domain1] user@host# set multicast-snooping-options ignore-stp-topology-change
Se você terminar de configurar o dispositivo, confirme a configuração.
user@host# commit
Resultados
Confirme sua configuração inserindo os comandos e show routing-instances a show bridge-domains configuração.
user@host# show bridge-domains
domain1 {
multicast-snooping-options {
forwarding-cache {
threshold {
suppress 100;
reuse 50;
}
}
}
}
user@host# show routing-instances
ce1 {
instance-type virtual-switch;
bridge-domains {
domain1 {
domain-type bridge;
vlan-id 100;
interface ge-0/3/9.0; ## 'ge-0/3/9.0' is not defined
interface ge-0/0/6.0; ## 'ge-0/0/6.0' is not defined
multicast-snooping-options {
flood-groups 224.0.0.5;
ignore-stp-topology-change;
}
}
}
}
Verificação
Para verificar a configuração, execute os seguintes comandos:
mostrar interface de snooping igmp
mostrar igmp snooping associação
mostrar estatísticas de espionagem igmp
mostrar rota de espionagem multicast
tabela de rotas de exibição
Habilitando atualizações em massa para o Multicast Snooping
Sempre que uma interface individual se junta ou deixa um grupo multicast, uma nova entrada de salto próximo é instalada na tabela de roteamento e na tabela de encaminhamento. Você pode usar a nexthop-hold-time declaração para especificar um tempo, de 1 a 1000 milissegundos (ms), durante os quais as mudanças de interface de saída são acumuladas e depois atualizadas em massa para a tabela de roteamento e tabela de encaminhamento. A atualização em massa reduz o tempo de processamento e a sobrecarga de memória necessárias para processar mensagens de adesão e saída. Isso é útil para aplicativos como a internet potocol television (IPTV), em que usuários que mudam de canal podem criar milhares de interfaces se juntando ou deixando um grupo em um curto período. Em cenários de IPTV, normalmente há um número relativamente pequeno e controlado de fluxos e um alto número de interfaces de saída. Usar atualizações em massa pode reduzir o atraso na junção.
Neste exemplo, você configura um tempo de espera de 20 milissegundos para switch virtual do tipo por exemplo, usando a nexthop-hold-time declaração:
Você pode incluir a nexthop-hold-time declaração apenas para tipos de instâncias de roteamento de switch virtual ou vpls no nível de hierarquia a seguir.
[edit routing-instances routing-instance-name multicast-snooping-options]
Se a nexthop-hold-time declaração for excluída da configuração do roteador, as atualizações em massa serão desativadas.
Veja também
Habilitando o snooping multicast para interfaces de grupo de agregação de enlaces multichassis
Inclua a multichassis-lag-replicate-state declaração no nível de [edit multicast-snooping-options] hierarquia para permitir a espionagem do IGMP e a replicação de estado para interfaces de grupo de agregação de enlaces multichassis (MC-LAG).
[edit]
multicast-snooping-options {
multichassis-lag-replicate-state;
}
Replicar a junção e deixar mensagens entre links de uma interface MC-LAG de link duplo permite uma recuperação mais rápida das informações de associação para interfaces MC-LAG que experimentam a interrupção do serviço.
Sem replicação de estado, se uma interface MC-LAG de link duplo tiver uma interrupção de serviço (por exemplo, se um link ativo for de espera), as informações de associação para a interface são recuperadas gerando uma consulta de IGMP à rede. Esse método pode levar de 1 a 10 segundos para ser concluído, o que pode ser muito longo para alguns aplicativos.
Quando a replicação de estado é fornecida para interfaces MC-LAG, o IGMP junta ou deixa mensagens recebidas em um dispositivo MC-LAG são replicadas do link MC-LAG ativo para o link de espera por meio de uma conexão interchassis Communication Protocol (ICCP). O link de espera processa as mensagens como se fossem recebidas do link MC-LAG ativo correspondente, exceto que ela não se adiciona como um próximo salto e não inunda a mensagem para a rede. Após um failover, o status de associação multicast do link pode ser recuperado dentro de alguns segundos ou menos, recuperando as mensagens replicadas.
Este exemplo permite a replicação de estado para interfaces MC-LAG: