Configuração do IGMP
Entendendo os protocolos de associação de grupos
Há uma grande diferença entre os protocolos multicast usados entre o host e o dispositivo de roteamento e entre os próprios dispositivos de roteamento multicast. Os hosts em uma determinada sub-rede precisam informar seu dispositivo de roteamento apenas se eles estão ou não interessados em receber pacotes de um determinado grupo multicast. O host de origem precisa informar seus dispositivos de roteamento apenas que ele é a fonte de tráfego para um determinado grupo multicast. Em outras palavras, nenhum conhecimento detalhado da árvore de distribuição é necessário por nenhum hosts; apenas um protocolo de associação de grupos é necessário para informar os dispositivos de roteamento de sua participação em um grupo multicast. Entre dispositivos de roteamento adjacentes, por outro lado, os protocolos de roteamento multicast devem evitar loops, pois criam uma noção detalhada da topologia e da árvore de distribuição da fonte à folha. Assim, diferentes protocolos multicast são usados para a porção do roteador de host e a parte do roteador-roteador da rede multicast.
Os protocolos de associação de grupos multicast permitem que um dispositivo de roteamento detecte quando um host em uma sub-rede diretamente anexada, normalmente uma LAN, quer receber tráfego de um determinado grupo multicast. Mesmo que mais de um host na LAN queira receber tráfego para esse grupo multicast, o dispositivo de roteamento envia apenas uma cópia de cada pacote para esse grupo multicast nessa interface, devido à natureza de transmissão inerente das LANs. Quando o protocolo de associação de grupos multicast informa ao dispositivo de roteamento que não há hosts interessados na sub-rede, os pacotes são retidos e essa folha é podada da árvore de distribuição.
O Protocolo de Gerenciamento de Grupos de Internet (IGMP) e o Protocolo Multicast Listener Discovery (MLD) são os protocolos padrão de associação de grupos IP multicast: IGMP e MLD têm várias versões que são suportadas por hosts e dispositivos de roteamento:
IGMPv1 — O protocolo original definido na RFC 1112. Uma mensagem de junção explícita é enviada ao dispositivo de roteamento, mas um tempo limite é usado para determinar quando os hosts deixam um grupo. Esse processo desperdiça ciclos de processamento no dispositivo de roteamento, especialmente em dispositivos de roteamento mais antigos ou menores.
IGMPv2 — Definido em RFC 2236. Entre outros recursos, o IGMPv2 adiciona uma mensagem de licença explícita à mensagem de junção para que os dispositivos de roteamento possam determinar com mais facilidade quando um grupo não tem ouvidos interessados em uma LAN.
IGMPv3 — definido em RFC 3376. Entre outros recursos, o IGMPv3 otimiza o suporte para uma única fonte de conteúdo para um grupo multicast, ou multicast específico de origem (SSM).
MLDv1 — Definido em RFC 2710. O MLDv1 é semelhante ao IGMPv2.
MLDv2 — Definido em RFC 3810. MLDv2 semelhante ao IGMPv3.
As várias versões de IGMP e MLD são compatíveis para trás. É comum que um dispositivo de roteamento execute várias versões de IGMP e MLD em interfaces LAN. A compatibilidade para trás é alcançada ao voltar ao mais básico de todas as versões executadas em uma LAN. Por exemplo, se um host estiver executando o IGMPv1, qualquer dispositivo de roteamento conectado à LAN que executa O IGMPv2 pode voltar à operação IGMPv1, eliminando efetivamente as vantagens do IGMPv2. Executar várias versões IGMP garante que os hosts IGMPv1 e IGMPv2 encontrem pares para suas versões no dispositivo de roteamento.
Nas plataformas da Série MX, o IGMPv2 e o IGMPv3 podem ou não podem ser configurados juntos na mesma interface, dependendo da versão do Junos OS em sua instalação. Configurar ambos juntos pode causar um comportamento inesperado no encaminhamento de tráfego multicast.
Veja também
Entendendo o IGMP
O Internet Group Management Protocol (IGMP) gerencia a associação de hosts e dispositivos de roteamento em grupos multicast. Os hosts de IP usam o IGMP para relatar suas associações de grupos multicast a quaisquer dispositivos de roteamento multicast imediatamente vizinhos. Os dispositivos de roteamento multicast usam o IGMP para aprender, para cada uma de suas redes físicas anexadas, quais grupos têm membros.
O IGMP também é usado como transporte para vários protocolos multicast relacionados (por exemplo, protocolo de roteamento multicast de vetor de distância [DVMRP] e protocolo independente multicast versão 1 [PIMv1]).
Um dispositivo de roteamento recebe mensagens explícitas de junção e podar daqueles dispositivos de roteamento vizinhos que têm membros do grupo downstream. Quando o PIM é o protocolo multicast em uso, o IGMP inicia o processo da seguinte forma:
Para se juntar a um grupo multicast, g, um host transmite suas informações de associação através do IGMP.
O dispositivo de roteamento então encaminha pacotes de dados endereçados a um grupo G multicast apenas para aquelas interfaces nas quais mensagens de junção explícitas foram recebidas.
Um roteador designado (DR) envia mensagens periódicas de junção e podar em direção a um ponto de encontro (RP) específico do grupo para cada grupo para o qual tenha membros ativos. Um ou mais dispositivos de roteamento são designados automaticamente ou estaticamente como RP, e todos os dispositivos de roteamento devem se juntar explicitamente através da RP.
Cada dispositivo de roteamento ao longo do caminho em direção à RP cria um estado curinga (de qualquer fonte) para o grupo e envia mensagens de junção e podadas em direção ao RP.
O termo entrada de rota é usado para se refere ao estado mantido em um dispositivo de roteamento para representar a árvore de distribuição.
Uma entrada de rota pode incluir campos como:
endereço fonte
endereço do grupo
interface de entrada da qual os pacotes são aceitos
lista de interfaces de saída para as quais os pacotes são enviados
Temporizadores
bits de bandeira
A interface de entrada de rota curinga aponta para a RP.
As interfaces de saída apontam para os dispositivos de roteamento downstream vizinhos que enviaram mensagens de junção e podar em direção à RP, bem como para os hosts diretamente conectados que solicitaram a adesão ao grupo G.
Esse estado cria uma árvore de distribuição compartilhada, centrada em RP, que atinge todos os membros do grupo.
O IGMP também é usado como transporte para vários protocolos multicast relacionados (por exemplo, protocolo de roteamento multicast de vetor de distância [DVMRP] e protocolo independente multicast versão 1 [PIMv1]).
A partir do Junos OS Release 15.2, o PIMv1 não tem suporte.
O IGMP é parte integral do IP e deve ser habilitado em todos os dispositivos de roteamento e hosts que precisam receber tráfego IP multicast.
Para cada rede conectada, um dispositivo de roteamento multicast pode ser um querier ou um nonquerier. O dispositivo de roteamento querier envia periodicamente mensagens de consulta geral para solicitar informações de associação de grupos. Hosts na rede que são membros de um grupo multicast enviam mensagens de relatório. Quando um host deixa um grupo, ele envia uma mensagem de grupo de licença.
A versão 3 do IGMP (IGMPv3) oferece suporte a listas de inclusão e exclusão. As listas de inclusão permitem que você especifique quais fontes podem enviar para um grupo multicast. Esse tipo de grupo multicast é chamado de grupo multicast específico de origem (SSM), e seu endereço multicast é 232/8.
O IGMPv3 oferece suporte para filtragem de fontes. Por exemplo, um dispositivo de roteamento pode especificar dispositivos de roteamento específicos dos quais aceita ou rejeita o tráfego. Com o IGMPv3, um dispositivo de roteamento multicast pode saber quais fontes são de interesse dos dispositivos de roteamento vizinhos.
O modo de exclusão funciona o oposto de uma lista de inclusão. Ele permite que qualquer fonte, exceto as listadas, enviem para o grupo SSM.
O IGMPv3 interopera com as versões 1 e 2 do protocolo. No entanto, para permanecer compatíveis com hosts IGMP e dispositivos de roteamento mais antigos, os dispositivos de roteamento IGMPv3 também devem implementar as versões 1 e 2 do protocolo. O IGMPv3 oferece suporte aos seguintes tipos de registro de relatório de associação: o modo é permitido, permite novas fontes e bloqueia fontes antigas.
Veja também
Configuração do IGMP
Antes de começar:
Determine se o roteador está diretamente conectado a alguma fonte multicast. Os receptores devem ser capazes de localizar essas fontes.
Determine se o roteador está diretamente conectado a algum receptor de grupo multicast. Se os receptores estiverem presentes, o IGMP é necessário.
Determine se deve configurar o multicast para usar modo esparso, denso ou denso esparso. Cada modo tem considerações de configuração diferentes.
Determine o endereço da RP se o modo esparso ou denso esparso for usado.
Determine se deve localizar o RP com a configuração estática, BSR ou método auto-RP.
Determine se deve configurar o multicast para usar sua própria tabela de roteamento RPF ao configurar o PIM em modo esparso, denso ou denso.
Configure os protocolos SAP e SDP para ouvir anúncios de sessões multicast. Consulte a configuração do protocolo de anúncio da sessão.
Para configurar o Protocolo de Gerenciamento de Grupos de Internet (IGMP), inclua a igmp
declaração:
igmp { accounting; interface interface-name { disable; (accounting | no-accounting); group-policy [ policy-names ]; immediate-leave; oif-map map-name; promiscuous-mode; ssm-map ssm-map-name; static { group multicast-group-address { exclude; group-count number; group-increment increment; source ip-address { source-count number; source-increment increment; } } } version version; } query-interval seconds; query-last-member-interval seconds; query-response-interval seconds; robust-count number; 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 protocols]
[edit logical-systems logical-system-name protocols]
Por padrão, o IGMP é habilitado em todas as interfaces nas quais você configura o Protocol Independent Multicast (PIM) e em todas as interfaces de broadcast nas quais você configura o Protocolo de roteamento multicast de vetor de distância (DVMRP).
Você pode configurar o IGMP em uma interface sem configurar o PIM. O PIM geralmente não é necessário em interfaces downstream IGMP. Portanto, apenas uma "interface pseudo PIM" é criada para representar todas as interfaces de downstream IGMP (somente IGMP) no roteador. Isso reduz a quantidade de recursos do roteador, como a memória, que são consumidos. Você deve configurar o PIM em interfaces IGMP upstream para permitir o roteamento multicast, realizar o encaminhamento de caminho inverso para pacotes de dados multicast, preencher a tabela de encaminhamento multicast para interfaces upstream e, no caso do modo esparso PIM e PIM bidirecional, para distribuir associações de grupos IGMP no domínio de roteamento multicast.
Habilitando o IGMP
O Internet Group Management Protocol (IGMP) gerencia grupos multicast estabelecendo, mantendo e removendo grupos em uma sub-rede. Os dispositivos de roteamento multicast usam o IGMP para saber quais grupos têm membros em cada uma de suas redes físicas anexadas. O IGMP deve ser habilitado para que o roteador receba pacotes multicast IPv4. O IGMP só é necessário para redes IPv4, porque o multicast é tratado de forma diferente em redes IPv6. O IGMP é habilitado automaticamente em todas as interfaces IPv4 nas quais você configura o PIM e em todas as interfaces de transmissão IPv4 quando você configura o DVMRP.
Se o IGMP não estiver sendo executado em uma interface — seja porque o PIM e o DVMRP não estão configurados na interface ou porque o IGMP está explicitamente desativado na interface — você pode habilitar explicitamente o IGMP.
Habilitar explicitamente o IGMP:
Veja também
Modificação do intervalo de mensagens de consulta de host do IGMP
O objetivo do IGMP é manter os roteadores atualizados com a associação em grupo de toda a sub-rede. Os roteadores não precisam saber quem são todos os membros, apenas que os membros existem. Cada host mantém o controle de quais grupos multicast são subscritos. Em cada link, um roteador é eleito o querier. O roteador querier IGMP envia periodicamente mensagens gerais de consulta de host em cada rede anexada para solicitar informações de associação. As mensagens são enviadas para o endereço de grupo multicast de todos os sistemas, 224.0.0.1.
O intervalo de consulta, o intervalo de resposta e a variável robustez estão relacionados, na medida em que são todas as variáveis usadas para calcular o tempo limite de adesão do grupo. O tempo limite de associação do grupo é o número de segundos que devem ser passados antes que um roteador multicast determine que não existe mais membros de um grupo de host em uma sub-rede. O tempo limite de associação do grupo é calculado como a (variável de robustez x intervalo de consulta) + (intervalo de resposta à consulta). Se nenhum relatório for recebido para um determinado grupo antes que o tempo limite de associação do grupo tenha expirado, o dispositivo de roteamento deixa de encaminhar pacotes multicast de origem remota para esse grupo na rede anexada.
Por padrão, as mensagens de consulta de host são enviadas a cada 125 segundos. Você pode alterar esse intervalo para alterar o número de mensagens IGMP enviadas na sub-rede.
Para modificar o intervalo de consulta:
Veja também
Modificação do intervalo de resposta a consultas de IGMP
O intervalo de resposta à consulta é o tempo máximo que pode passar entre quando o roteador querier envia uma mensagem de consulta de host e quando ele recebe uma resposta de um host. A configuração desse intervalo permite ajustar os picos de explosão de mensagens IGMP na sub-rede. Definir um intervalo maior para tornar o tráfego menos estourado. O tráfego estourado refere-se a um padrão desigual de transmissão de dados: às vezes uma taxa de transmissão de dados muito alta, enquanto em outros momentos uma taxa de transmissão de dados muito baixa.
O intervalo de resposta à consulta, o intervalo de consulta de host e a variável de robustez estão relacionados, pois são todas variáveis usadas para calcular o tempo limite de associação do grupo. O tempo limite de associação do grupo é o número de segundos que devem ser passados antes que um roteador multicast determine que não existe mais membros de um grupo de host em uma sub-rede. O tempo limite de associação do grupo é calculado como a (variável de robustez x intervalo de consulta) + (intervalo de resposta à consulta). Se nenhum relatório for recebido para um determinado grupo antes que o tempo limite de associação do grupo tenha expirado, o dispositivo de roteamento deixa de encaminhar pacotes multicast de origem remota para esse grupo na rede anexada.
O intervalo de resposta de consulta padrão é de 10 segundos. Você pode configurar um intervalo de subsecond de até um dígito à direita do ponto decimais. A faixa configurável é de 0,1 a 0,9, depois em intervalos de 1 segundo de 1 a 999.999.
Para modificar o intervalo de resposta à consulta:
Veja também
Especificando a remoção imediata do host para IGMP
A configuração de licença imediata é útil para minimizar a latência de licença de associações IGMP. Quando essa configuração é habilitada, o dispositivo de roteamento deixa o grupo multicast imediatamente após o último host deixar o grupo multicast.
A configuração de licença imediata permite o rastreamento do host, o que significa que o dispositivo mantém o controle dos hosts que enviam mensagens de junção. Isso permite que o IGMP determine quando o último host envia uma mensagem de licença para o grupo multicast.
Quando a configuração de licença imediata é habilitada, o dispositivo remove uma interface da entrada da tabela de encaminhamento sem antes enviar consultas específicas do grupo IGMP para a interface. A interface é podada da árvore multicast para o grupo multicast especificado na mensagem de licença IGMP. A configuração de licença imediata garante o gerenciamento ideal de largura de banda para hosts em uma rede comutada, mesmo quando vários grupos multicast estão sendo usados simultaneamente.
Quando a licença imediata é desativada e um host envia uma mensagem de grupo de licença, o dispositivo de roteamento primeiro envia uma consulta em grupo para determinar se outro receptor responde. Se nenhum receptor responder, o dispositivo de roteamento remove todos os hosts da interface do grupo multicast. A licença imediata é desativada por padrão tanto para a versão 2 do IGMP quanto para a versão 3 do IGMP.
Embora o rastreamento do host esteja habilitado para IGMPv2 e MLDv1 quando você habilitar a licença imediata, use licença imediata com essas versões apenas quando houver um host na interface. A razão é que o IGMPv2 e o MLDv1 usam um mecanismo de supressão de relatório pelo qual apenas um host em uma interface envia um relatório de participação de grupo em resposta a uma consulta de associação. Os outros hosts interessados suprimem seus relatórios. O objetivo desse mecanismo é evitar uma série de relatórios para o mesmo grupo. Mas também interfere no rastreamento do host, porque o roteador só sabe sobre um host interessado e não sabe sobre os outros.
Para habilitar a licença imediata em uma interface:
Veja também
Filtragem de relatórios IGMP indesejados no nível de interface IGMP
Suponha que você precise limitar as sub-redes que podem se juntar a um determinado grupo multicast. A group-policy
declaração permite filtrar relatórios IGMP indesejados no nível da interface. Quando esta declaração é habilitada em um roteador que executa iGMP versão 2 (IGMPv2) ou versão 3 (IGMPv3), após o roteador receber um relatório IGMP, o roteador compara o grupo com a política de grupo especificada e executa a ação configurada nessa política (por exemplo, rejeita o relatório se a política corresponde ao endereço ou rede definido).
Você define a política para combinar apenas endereços de grupo IGMP (para IGMPv2) usando a declaração da política para combinar com o endereço do route-filter
grupo. Você define a política para combinar endereços IGMP (fonte, grupo) (para IGMPv3) usando a declaração da política para combinar com o endereço do route-filter
grupo e a declaração da source-address-filter
política para combinar com o endereço de origem.
Nas plataformas da Série MX, o IGMPv2 e o IGMPv3 podem ou não podem ser configurados juntos na mesma interface, dependendo da versão do Junos OS em sua instalação. Configurar ambos juntos pode causar um comportamento inesperado no encaminhamento de tráfego multicast.
Filtrar relatórios IGMP indesejados:
Veja também
Aceitando mensagens IGMP de sub-redes remotas
Por padrão, as interfaces IGMP aceitam mensagens IGMP apenas da mesma sub-rede. Incluir a promiscuous-mode
declaração permite que o dispositivo de roteamento aceite mensagens IGMP de sub-redes conectadas indiretamente.
Quando você habilita o IGMP em uma interface Ethernet sem números que usa um endereço loopback /32 como endereço de doador, você deve configurar o modo promíscuo IGMP para aceitar os pacotes IGMP recebidos nesta interface.
Ao habilitar o modo promíscuo, todos os roteadores do segmento de ethernet devem ser configurados com a declaração de modo promíscuo. Caso contrário, apenas a interface configurada com o endereço IPv4 mais baixo funciona como a mais querier para IGMP para este segmento Ethernet.
Para habilitar o modo promíscuo de IGMP em uma interface:
Veja também
Modificação do intervalo de consulta de último membro do IGMP
O intervalo de consulta de último membro é a quantidade máxima de tempo entre mensagens de consulta específicas do grupo, incluindo aquelas enviadas em resposta a mensagens de grupo de licença. Você pode configurar esse intervalo para alterar o tempo necessário para que um dispositivo de roteamento detecte a perda do último membro de um grupo.
Quando o dispositivo de roteamento que está servindo como querier recebe uma mensagem de grupo de licença de um host, o dispositivo de roteamento envia várias consultas específicas do grupo para o grupo que está sendo deixado. O querier envia um número específico dessas consultas em um intervalo específico. O número de consultas enviadas é chamado de contagem de consultas de último membro. O intervalo em que as consultas são enviadas é chamado de intervalo de consulta de último membro. Como ambas as configurações são configuráveis, você pode ajustar a latência de licença. A latência de licença IGMP é o momento entre uma solicitação para deixar um grupo multicast e o recebimento do último byte de dados para o grupo multicast.
A contagem de consultas de último membro x (vezes) o intervalo de consulta de último membro = (igual) o tempo necessário para um dispositivo de roteamento determinar que o último membro de um grupo deixou o grupo e parar de encaminhar o tráfego do grupo.
O intervalo padrão de consulta de último membro é de 1 segundo. Você pode configurar um intervalo de subsecond de até um dígito à direita do ponto decimais. A faixa configurável é de 0,1 a 0,9, depois em intervalos de 1 segundo de 1 a 999.999.
Para modificar este intervalo:
Você pode configurar a contagem de consultas de último membro configurando a variável de robustez. Os dois são sempre iguais.
Veja também
Modificando a variável de robustez do IGMP
Ajuste a variável de robustez do IGMP para permitir a perda esperada de pacotes em uma sub-rede. A contagem robusta altera automaticamente certos intervalos de mensagem IGMP para IGMPv2 e IGMPv3. Aumentar a contagem robusta permite mais perda de pacotes, mas aumenta a latência de licença da sub-rede.
Quando o roteador de consulta recebe uma mensagem de licença IGMP em uma rede compartilhada executando o IGMPv2, o roteador de consulta deve enviar uma mensagem de consulta de grupo IGMP a um número especificado de vezes. O número de mensagens de consulta de grupo de IGMP enviadas é determinado pela contagem robusta.
O valor da variável robustez também é usado no cálculo dos seguintes intervalos de mensagem IGMP:
Intervalo de membros do grupo — Quantidade de tempo que deve passar antes que um roteador multicast determine que não há mais membros de um grupo em uma rede. Este intervalo é calculado da seguinte forma: (variável de robustez x intervalo de consulta) + (1 x intervalo de resposta por consulta).
Outro intervalo presente mais querido — a contagem robusta é usada para calcular a quantidade de tempo que deve passar antes que um roteador multicast determine que não há mais outro roteador multicast que seja o querier. Este intervalo é calculado da seguinte forma: (variável de robustez x intervalo de consulta) + (0,5 x intervalo de resposta por consulta).
Contagem de consultas de último membro — número de consultas específicas de grupo enviadas antes que o roteador assuma que não há membros locais de um grupo. O número de consultas é igual ao valor da variável robustez.
No IGMPv3, uma mudança de estado de interface faz com que o sistema transmita imediatamente um relatório de mudança de estado dessa interface. Caso o relatório de mudança de estado seja perdido por um ou mais roteadores multicast, ele é retransmitido. O número de vezes em que é retransmitido é a contagem robusta menos uma. No IGMPv3, a contagem robusta também é um fator na determinação do intervalo de membros do grupo, do intervalo mais antigo da versão mais querier e do outro intervalo presente mais querier.
Por padrão, a variável de robustez é definida para 2. Você pode querer aumentar esse valor se esperar que uma sub-rede perca pacotes.
O número pode ser de 2 a 10.
Para alterar o valor da variável robustez:
Veja também
Limitando a taxa máxima de mensagens IGMP
Esta seção descreve como alterar o limite para o número máximo de pacotes IGMP transmitidos em 1 segundo pelo roteador.
Aumentar o número máximo de pacotes IGMP transmitidos por segundo pode ser útil em um roteador com um grande número de interfaces participando do IGMP.
Para alterar o limite para o número máximo de pacotes IGMP, o roteador pode transmitir em 1 segundo, incluir a maximum-transmit-rate
declaração e especificar o número máximo de pacotes por segundo a serem transmitidos.
Veja também
Mudando a versão IGMP
Por padrão, o dispositivo de roteamento executa o IGMPv2. Os dispositivos de roteamento que executam diferentes versões do IGMP determinam a versão mais baixa comum do IGMP que é suportada por hosts em sua sub-rede e opera nessa versão.
Para habilitar a funcionalidade multicast específica de origem (SSM), você deve configurar a versão 3 no host e o dispositivo de roteamento diretamente conectado do host. Se um endereço de origem for especificado em um grupo multicast que esteja configurado estaticamente, a versão deve ser definida como IGMPv3.
Se um grupo multicast estático estiver configurado com o endereço de origem definido, e a versão IGMP estiver configurada para ser a versão 2, a fonte será ignorada e apenas o grupo será adicionado. Neste caso, a adesão é tratada como um grupo IGMPv2.
Se você configurar a configuração da versão IGMP no nível de hierarquia de interface individual, ela se sobrepõe à interface all
declaração. Ou seja, a nova interface não herda o número de versão que você especificou com a interface all
declaração. Por padrão, essa nova interface é habilitada com version 2
. Você deve especificar explicitamente um version number
ao adicionar uma nova interface. Por exemplo, se você especificasse version 3
com interface all
, você precisaria configurar a version 3
declaração para a nova interface. Além disso, se você configurar uma interface para um grupo multicast no nível de [edit interface interface-name static group multicast-group-address]
hierarquia, você deve especificar um version number
bem como os outros parâmetros de grupo. Caso contrário, a interface é habilitada com o padrão version 2
.
Se você já tiver configurado o dispositivo de roteamento para usar a versão 1 (IGMPv1) do IGMP e depois configurá-lo para usar o IGMPv2, o dispositivo de roteamento continua a usar o IGMPv1 por até 6 minutos e depois usa o IGMPv2.
Para mudar para IGMPv3 para funcionalidade SSM:
Nas plataformas da Série MX, o IGMPv2 e o IGMPv3 podem ou não podem ser configurados juntos na mesma interface, dependendo da versão do Junos OS em sua instalação. Configurar ambos juntos pode causar um comportamento inesperado no encaminhamento de tráfego multicast.
Veja também
Habilitando a associação de grupos estáticos do IGMP
Você pode criar uma associação de grupo estática de IGMP para testar o encaminhamento multicast sem um host receptor. Quando você habilita a associação de grupos estáticos do IGMP, os dados são encaminhados para uma interface sem que essa interface receba relatórios de associação de hosts downstream. O roteador no qual você habilita a associação estática do grupo IGMP deve ser o roteador designado (DR) para a sub-rede. Caso contrário, o tráfego não flui rio abaixo.
Ao habilitar a associação de grupos estáticos do IGMP, você não pode configurar vários grupos usando a contagem de grupos, incremento de grupo, contagem de fontes e source-increment
declarações se toda a opção for especificada como a interface IGMP.
O ajuste de classe de serviço (CoS) não é suportado com a associação de grupos estáticos do IGMP.
Neste exemplo, você cria o grupo estático 233.252.0.1.
Quando você configura entradas de grupo IGMP estáticas em links ponto a ponto que conectam dispositivos de roteamento a um ponto de encontro (RP), as entradas estáticas do grupo IGMP não geram mensagens de junção em direção ao RP.
Ao criar uma associação de grupos estáticos de IGMP para testar o encaminhamento multicast em uma interface na qual deseja receber tráfego multicast, você pode especificar que vários grupos estáticos serão criados automaticamente. Isso é útil quando você deseja testar o encaminhamento a vários receptores sem precisar configurar cada receptor separadamente.
Neste exemplo, você cria três grupos.
No DR, configure o número de grupos estáticos a serem criados incluindo a
group-count
declaração e especificando o número de grupos a serem criados.[edit protocols igmp] user@host# set interface fe-0/1/2 static group 233.252.0.1 group-count 3
Depois de confirmar a configuração, use o
show configuration protocol igmp
comando para verificar a configuração do protocolo IGMP.user@host> show configuration protocol igmp
interface fe-0/1/2.0 { static { group 233.252.0.1 { group-count 3; } } }
Depois de ter cometido a configuração e depois que a fonte estiver enviando tráfego, use o
show igmp group
comando para verificar se os grupos estáticos 233.252.0.1, 233.252.0.2 e 233.252.0.3 foram criados.user@host> show igmp group Interface: fe-0/1/2 Group: 233.252.0.1 Source: 10.0.0.2 Last reported by: Local Timeout: 0 Type: Static Group: 233.252.0.2 Source: 10.0.0.2 Last reported by: Local Timeout: 0 Type: Static Group: 233.252.0.3 Source: 10.0.0.2 Last reported by: Local Timeout: 0 Type: Static
Ao criar uma associação de grupo estática de IGMP para testar o encaminhamento multicast em uma interface na qual deseja receber tráfego multicast, você também pode configurar o endereço do grupo a ser incrementado automaticamente para cada grupo criado. Isso é útil quando você deseja testar o encaminhamento a vários receptores sem precisar configurar cada receptor separadamente e quando não quiser que os endereços do grupo sejam sequenciais.
Neste exemplo, você cria três grupos e aumenta o endereço do grupo em um incremento de dois para cada grupo.
Na DR, configure o incremento do endereço do grupo incluindo a
group-increment
declaração e especificando o número pelo qual o endereço deve ser incrementado para cada grupo. O incremento é especificado em notação decimal pontilhada semelhante a um endereço IPv4.[edit protocols igmp] user@host# set interface fe-0/1/2 static group 233.252.0.1 group-count 3 group-increment 0.0.0.2
Depois de confirmar a configuração, use o
show configuration protocol igmp
comando para verificar a configuração do protocolo IGMP.user@host> show configuration protocol igmp
interface fe-0/1/2.0 { version 3; static { group 233.252.0.1 { group-increment 0.0.0.2; group-count 3; } } }
Depois de ter cometido a configuração e depois que a fonte estiver enviando tráfego, use o
show igmp group
comando para verificar se os grupos estáticos 233.252.0.1, 233.252.0.3 e 233.252.0.5 foram criados.user@host> show igmp group Interface: fe-0/1/2 Group: 233.252.0.1 Source: 10.0.0.2 Last reported by: Local Timeout: 0 Type: Static Group: 233.252.0.3 Source: 10.0.0.2 Last reported by: Local Timeout: 0 Type: Static Group: 233.252.0.5 Source: 10.0.0.2 Last reported by: Local Timeout: 0 Type: Static
Ao criar uma associação de grupo estática de IGMP para testar o encaminhamento multicast em uma interface na qual você deseja receber tráfego multicast, e sua rede estiver operando no modo multicast (SSM) específico de origem, você também pode especificar se o endereço fonte multicast será aceito. Isso é útil quando você deseja testar o encaminhamento para receptores multicast de uma fonte multicast específica.
Se você especificar um endereço em grupo na faixa SSM, você também deve especificar uma fonte.
Se um endereço de origem for especificado em um grupo multicast que esteja configurado estaticamente, a versão IGMP na interface deve ser definida para IGMPv3. IGMPv2 é o valor padrão.
Neste exemplo, você cria o grupo 233.252.0.1 e aceita o endereço IP 10.0.0.2 como a única fonte.
No DR, configure o endereço fonte incluindo a
source
declaração e especificando o endereço IPv4 do host de origem.[edit protocols igmp] user@host# set interface fe-0/1/2 static group 233.252.0.1 source 10.0.0.2
Depois de confirmar a configuração, use o
show configuration protocol igmp
comando para verificar a configuração do protocolo IGMP.user@host> show configuration protocol igmp
interface fe-0/1/2.0 { version 3; static { group 233.252.0.1 { source 10.0.0.2; } } }
Depois de ter cometido a configuração e a fonte estar enviando tráfego, use o
show igmp group
comando para verificar se o grupo estático 233.252.0.1 foi criado e essa fonte 10.0.0.2 foi aceita.user@host> show igmp group Interface: fe-0/1/2 Group: 233.252.0.1 Source: 10.0.0.2 Last reported by: Local Timeout: 0 Type: Static
Ao criar uma associação de grupos estáticos de IGMP para testar o encaminhamento multicast em uma interface na qual deseja receber tráfego multicast, você pode especificar que várias fontes multicast serão aceitas automaticamente. Isso é útil quando você deseja testar o encaminhamento para receptores multicast de mais de uma fonte multicast especificada.
Neste exemplo, você cria o grupo 233.252.0.1 e aceita endereços 10.0.0.2, 10.0.0.3 e 10.0.0.4 como fontes.
No DR, configure o número de endereços de origem multicast a serem aceitos incluindo a
source-count
declaração e especificando o número de fontes a serem aceitas.[edit protocols igmp] user@host# set interface fe-0/1/2 static group 233.252.0.1 source 10.0.0.2 source-count 3
Depois de confirmar a configuração, use o
show configuration protocol igmp
comando para verificar a configuração do protocolo IGMP.user@host> show configuration protocol igmp
interface fe-0/1/2.0 { version 3; static { group 233.252.0.1 { source 10.0.0.2 { source-count 3; } } } }
Depois de ter cometido a configuração e a fonte estar enviando tráfego, use o
show igmp group
comando para verificar se o grupo estático 233.252.0.1 foi criado e que as fontes 10.0.0.2, 10.0.0.3 e 10.0.4 foram aceitas.user@host> show igmp group Interface: fe-0/1/2 Group: 233.252.0.1 Source: 10.0.0.2 Last reported by: Local Timeout: 0 Type: Static Group: 233.252.0.1 Source: 10.0.0.3 Last reported by: Local Timeout: 0 Type: Static Group: 233.252.0.1 Source: 10.0.0.4 Last reported by: Local Timeout: 0 Type: Static
Quando você configura grupos estáticos em uma interface na qual deseja receber tráfego multicast e especifica que várias fontes multicast são aceitas automaticamente, você também pode especificar o número pelo qual o endereço deve ser incrementado para cada fonte aceita. Isso é útil quando você deseja testar o encaminhamento a vários receptores sem precisar configurar cada receptor separadamente e não deseja que os endereços de origem sejam sequenciais.
Neste exemplo, você cria o grupo 233.252.0.1 e aceita endereços 10.0.0.2, 10.0.0.4 e 10.0.0.6 como fontes.
Configure o incremento de endereço de origem multicast incluindo a
source-increment
declaração e especificando o número pelo qual o endereço deve ser incrementado para cada fonte. O incremento é especificado em notação decimal pontilhada semelhante a um endereço IPv4.[edit protocols igmp] user@host# set interface fe-0/1/2 static group 233.252.0.1 source 10.0.0.2 source-count 3 source-increment 0.0.0.2
Depois de confirmar a configuração, use o
show configuration protocol igmp
comando para verificar a configuração do protocolo IGMP.user@host> show configuration protocol igmp
interface fe-0/1/2.0 { version 3; static { group 233.252.0.1 { source 10.0.0.2 { source-count 3; source-increment 0.0.0.2; } } } }
Depois de ter cometido a configuração e depois que a fonte estiver enviando tráfego, use o
show igmp group
comando para verificar se o grupo estático 233.252.0.1 foi criado e que as fontes 10.0.0.2, 10.0.0.4 e 10.0.6 foram aceitas.user@host> show igmp group Interface: fe-0/1/2 Group: 233.252.0.1 Source: 10.0.0.2 Last reported by: Local Timeout: 0 Type: Static Group: 233.252.0.1 Source: 10.0.0.4 Last reported by: Local Timeout: 0 Type: Static Group: 233.252.0.1 Source: 10.0.0.6 Last reported by: Local Timeout: 0 Type: Static
Quando você configura grupos estáticos em uma interface na qual deseja receber tráfego multicast e sua rede está operando no modo multicast (SSM) específico de origem, você pode especificar se determinados endereços de origem multicast serão excluídos.
Por padrão, o endereço de origem multicast configurado em um grupo estático opera no modo incluem. No modo de inclusão, o tráfego multicast para o grupo é aceito a partir do endereço de origem configurado. Você também pode configurar o grupo estático para operar no modo exclude. No modo de exclusão, o tráfego multicast para o grupo é aceito em qualquer endereço que não seja o endereço de origem configurado.
Se um endereço de origem for especificado em um grupo multicast que esteja configurado estaticamente, a versão IGMP na interface deve ser definida para IGMPv3. IGMPv2 é o valor padrão.
Neste exemplo, você exclui o endereço 10.0.0.2 como fonte para o grupo 233.252.0.1.
No DR, configure um grupo estático multicast para operar no modo excludente, incluindo a
exclude
declaração e especificando qual endereço fonte IPv4 excluirá.[edit protocols igmp] user@host# set interface fe-0/1/2 static group 233.252.0.1 exclude source 10.0.0.2
Depois de confirmar a configuração, use o
show configuration protocol igmp
comando para verificar a configuração do protocolo IGMP.user@host> show configuration protocol igmp
interface fe-0/1/2.0 { version 3; static { group 233.252.0.1 { exclude; source 10.0.0.2; } } }
Depois de ter cometido a configuração e a fonte estar enviando tráfego, use o
show igmp group detail
comando para verificar se o grupo estático 233.252.0.1 foi criado e que o grupo está estático está operando no modo exclude.user@host> show igmp group detail Interface: fe-0/1/2 Group: 233.252.0.1 Group mode: Exclude Source: 10.0.0.2 Last reported by: Local Timeout: 0 Type: Static
Veja também
Gravação de IGMP Participe e deixe eventos
Para determinar se o ajuste de IGMP é necessário em uma rede, você pode configurar o dispositivo de roteamento para registrar a participação e a saída de eventos do IGMP. Você pode registrar eventos globalmente para o dispositivo de roteamento ou para interfaces individuais.
A Tabela 1 descreve os eventos IGMP recordes.
ERRMSG Tag |
Definição |
---|---|
RPD_IGMP_JOIN |
Registro IGMP participar de eventos. |
RPD_IGMP_LEAVE |
Registros IGMP deixam eventos. |
RPD_IGMP_ACCOUNTING_ON |
Registra quando a contabilidade IGMP é habilitada em uma interface IGMP. |
RPD_IGMP_ACCOUNTING_OFF |
Registros quando a contabilidade IGMP é desativada em uma interface IGMP. |
RPD_IGMP_MEMBERSHIP_TIMEOUT |
Registra eventos de tempo limite de associação do IGMP. |
Para habilitar a contabilidade IGMP:
Veja também
Limitar o número de grupos multicast IGMP se junta em interfaces lógicas
A group-limit
declaração permite que você limite o número de grupos multicast IGMP para interfaces lógicas. Quando esta declaração é habilitada em um roteador que executa iGMP versão 2 (IGMPv2) ou versão 3 (IGMPv3), o limite é aplicado após o recebimento do relatório do grupo. Assim que o limite do grupo for atingido, os pedidos de adesão subsequentes são rejeitados.
Ao configurar limites para grupos multicast IGMP, lembre-se do seguinte:
Cada grupo de qualquer fonte (*,G) conta como um grupo rumo ao limite.
Cada grupo específico de origem (S,G) conta como um grupo rumo ao limite.
Grupos no modo de exclusão do IGMPv3 são contados no limite.
Vários grupos específicos de origem contam individualmente em direção ao limite do grupo, mesmo que sejam para o mesmo grupo. Por exemplo, (S1, G1) e (S2, G1) contariam como dois grupos em direção ao limite configurado.
Combinações de grupos de qualquer fonte e grupos específicos de origem contam individualmente para o limite do grupo, mesmo que sejam para o mesmo grupo. Por exemplo, (*, G1) e (S, G1) contariam como dois grupos em direção ao limite configurado.
Configurar e comprometer um limite de grupo em uma rede que é menor do que o que já existe na rede resulta na remoção de todos os grupos da configuração. Em seguida, os grupos devem solicitar a desapresentação da rede (até o limite de grupo recém configurado).
Você pode limitar dinamicamente grupos multicast em interfaces lógicas de IGMP usando perfis dinâmicos.
A partir do Junos OS Release 12.2, você pode configurar opcionalmente um limiar de alerta de log de sistema para o grupo multicast IGMP recebido na interface lógica. É útil revisar as mensagens de log do sistema para fins de solução de problemas e detectar se uma quantidade excessiva de junções de grupo multicast de IGMP foi recebida na interface. Essas mensagens de log transmitem quando o limite de grupo configurado foi excedido, quando o limite configurado foi excedido e quando o número de grupos cai abaixo do limiar configurado.
A group-threshold
declaração permite configurar o limite em que uma mensagem de aviso está registrada. O intervalo é de 1 a 100%. O limite de aviso é uma porcentagem do limite do grupo, de modo que você deve configurar a group-limit
declaração para configurar um limite de aviso. Por exemplo, quando o número de grupos excede o limite de aviso configurado, mas permanece abaixo do limite de grupo configurado, grupos multicast continuam a ser aceitos e o dispositivo registra a mensagem de aviso. Além disso, o dispositivo registra uma mensagem de aviso após o número de grupos cair abaixo do limiar de aviso configurado. Você pode especificar ainda a quantidade de tempo (em segundos) entre as mensagens de log configurando a log-interval
declaração. O intervalo é de 6 a 32.767 segundos.
Você pode considerar o estrangulamento de mensagens de log porque cada entrada adicionada após o limiar configurado e cada entrada recusada após o limite configurado faz com que uma mensagem de aviso seja registrada. Ao configurar um intervalo de log, você pode reduzir a quantidade de mensagens de aviso de log de sistema geradas para o grupo multicast IGMP.
Nos roteadores da Série ACX, o número máximo de rotas multicast é de 1024.
Para limitar a participação de grupos multicast em uma interface lógica de IGMP:
Para confirmar sua configuração, use o show protocols igmp
comando. Para verificar a operação do IGMP na interface, incluindo o limite de grupo configurado e o limite de aviso opcional e intervalo entre mensagens de log, use o show igmp interface
comando.
Veja também
Rastreamento do tráfego de protocolo IGMP
As operações de rastreamento registram mensagens detalhadas sobre a operação de protocolos de roteamento, como os vários tipos de pacotes de protocolo de roteamento enviados e recebidos, e ações de políticas de roteamento. Você pode especificar quais operações de rastreamento estão registradas, incluindo bandeiras de rastreamento específicas. A tabela a seguir descreve as bandeiras que você pode incluir.
Bandeira |
Descrição |
---|---|
todo |
Trace todas as operações. |
notificação do cliente |
Trace notificações. |
Geral |
Trace o fluxo geral. |
grupo |
Trace as operações do grupo. |
notificação do host |
Rastreie as notificações do host. |
deixar |
Rastrear mensagens de grupo de licença (apenas IGMPv2). |
mtrace |
Trace pacotes de mtrace. Use o |
normal |
Trace eventos normais. |
Pacotes |
Rastreie todos os pacotes IGMP. |
política |
Trace o processamento de políticas. |
consulta |
Trace mensagens de consulta de membros do IGMP, incluindo consultas gerais e específicas do grupo. |
relatório |
Rastrear mensagens de relatório de associação. |
rota |
Trace informações de roteamento. |
estado |
Trace as transições de estado. |
tarefa |
Trace o processamento de tarefas. |
temporizador |
Trace o processamento do temporização. |
No exemplo a seguir, o rastreamento é habilitado para todos os pacotes de protocolo de roteamento. Em seguida, o rastreamento é limitado para se concentrar apenas em pacotes IGMP de um tipo específico. Para configurar as operações de rastreamento para IGMP:
Veja também
Desativação do IGMP
Para desativar o IGMP em uma interface, inclua a disable
declaração:
disable;
Você pode incluir essa declaração nos seguintes níveis de hierarquia:
[edit protocols igmp interface interface-name]
[edit logical-systems logical-system-name protocols igmp interface interface-name]
Nota:Os roteadores da Série ACX não suportam o
[edit logical-systems logical-system-name protocols]
nível de hierarquia.
Veja também
IGMP e roteamento ativo sem parar
As configurações de roteamento ativo (NSR) sem interrupções incluem dois mecanismos de roteamento que compartilham informações para que o roteamento não seja interrompido durante o failover do mecanismo de roteamento. Essas configurações de NSR incluem suporte passivo com IGMP em conexão com o PIM. O mecanismo de roteamento primário usa IGMP para determinar seu estado de multicast PIM, e essas informações derivadas do IGMP são replicadas no mecanismo de roteamento de backup. O IGMP no novo mecanismo de roteamento primário (após o failover) reaprende as informações de estado rapidamente por meio da operação IGMP. Nesse ínterim, o novo mecanismo de roteamento primário retém o estado PIM derivado do IGMP como recebido pelo processo de replicação do antigo mecanismo de roteamento primário. Essas informações de estado são atualizadas a menos que seja atualizada pelo IGMP no novo mecanismo de roteamento primário. Nenhuma configuração adicional de IGMP é necessária.
Veja também
Tabela de histórico de mudanças
O suporte de recursos é determinado pela plataforma e versão que você está usando. Use o Feature Explorer para determinar se um recurso é suportado em sua plataforma.