Corrija problemas de tráfego multicast na mesma VLAN em switches Catalyst

Introdução

Este documento descreve como corrigir uma falha de aplicação multicast quando ela é implantada na mesma VLAN entre switches Catalyst.

Pré-requisitos

Requisitos

Não existem requisitos específicos para este documento.

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software e hardware:

• Catalyst 6500 com Supervisor Engine 720 que executa o Cisco IOS® Software

• Catalyst 3750 que executa um Cisco IOS Software

• Qualquer switch Catalyst que execute uma versão do Cisco IOS Software e também suporte a espionagem de Internet Group Management Protocol (IGMP)

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Conventions

Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.

Informações de Apoio

Além disso, alguns servidores/aplicativos que usam pacotes multicast para a operação de cluster/alta disponibilidade podem falhar se você não configurar os switches adequadamente. Isso também é abordado neste artigo.

Observação: consulte a seção Matriz de Suporte do Switch Catalyst do Recurso de Rastreamento IGMP do documento Matriz de Suporte dos Switches Catalyst Multicast para ajudar a identificar esses switches.

Problema

O tráfego multicast não passa pelos switches Catalyst, mesmo na mesma VLAN.A Figura 1 descreve esse cenário.

Figura 1 - Configuração de rede com origem e receptores multicast

Diagrama de Rede

A origem multicast é conectada ao Switch 1, que é um Switch Catalyst 6500 com Supervisor Engine 720 que executa o Cisco IOS Software. O Receptor 1 está conectado ao Switch 1 e o Receptor 2 está conectado ao Switch 2. O Switch 2 é um Catalyst 3750. Há um link de Camada 2, de acesso ou tronco, entre o Switch 1 e o Switch 2.

Nessa configuração, você descobre que o Receptor 1, que está no mesmo switch que a origem, obtém o fluxo de multicast sem problemas. No entanto, o receptor 2não recebe nenhum tráfego multicast. Este documento tem como objetivo resolver esse problema.

Revisite os principais conceitos de multicast

Antes de explorar a solução e as diferentes opções que você tem, você deve estar claro sobre certos conceitos-chave de multicast de Camada 2. Esta seção define esses conceitos.

Observação: esta seção fornece uma explicação muito simples e direta que se concentra apenas nesse problema específico. Consulte a seção Informações Relacionadas no final deste documento para obter uma explicação detalhada desses termos.

IGMP

O IGMP é um protocolo que permite que os hosts finais (receptores) informem um roteador multicast (consultante IGMP) sobre a intenção do host final de receber tráfego multicast específico. Este é um protocolo que é executado entre um roteador e os hosts finais e permite:

• Roteadores para perguntar aos hosts finais se eles precisam de um fluxo multicast específico (consulta IGMP)

• Hosts finais para informar ou responder ao roteador se buscam um fluxo multicast específico (relatórios IGMP)

Espionagem de IGMP

O snooping IGMP é um mecanismo para restringir o tráfego multicast somente às portas que têm receptores conectados. O mecanismo aumenta a eficiência porque permite que um switch de Camada 2 envie seletivamente pacotes multicast somente nas portas que precisam deles. Sem a espionagem de IGMP, o switch inunda os pacotes em cada porta. O switch "escuta" a troca de mensagens IGMP pelo roteador e pelos hosts finais. Dessa forma, o switch cria uma tabela de snooping IGMP que tem uma lista de todas as portas que solicitaram um grupo multicast específico.

Porta Mrouter

A porta mrouter é simplesmente a porta do ponto de vista do switch que se conecta a um roteador multicast. A presença de pelo menos uma porta mrouter é absolutamente essencial para que a operação de espionagem de IGMP funcione entre switches.

Multicast em L2

Qualquer tráfego IP versão 4 (IPv4) com um IP de destino no intervalo de 224.0.0.0 a 239.255.255.255 é um fluxo multicast. Todos os pacotes multicast IPv4 são mapeados para um endereço MAC IEEE predefinido com o formato 01.00.5e. xx . xx . xx . xx .

Observação: o snooping IGMP só funciona se o endereço MAC multicast for mapeado para esse intervalo MAC compatível com IEEE. Alguns intervalos multicast reservados são excluídos daqueles rastreados por design. Se um pacote multicast não-conforme for originado em uma rede comutada, o pacote será inundado por toda a VLAN, o que significa que é tratado como tráfego de broadcast.

Entenda o problema e as possíveis soluções

Por padrão, os switches Catalyst têm o rastreamento de IGMP habilitado. Com a espionagem de IGMP, o switch rastreia (ou escuta) mensagens de IGMP em todas as portas. O switch cria uma tabela de snooping IGMP que basicamente mapeia um grupo multicast para todas as portas do switch que o solicitaram.

Suponha que, sem qualquer configuração anterior, o Receptor 1 e o Receptor 2 tenham sinalizado suas intenções de receber um fluxo multicast para 239.239.239.239 que mapeia para o endereço MAC multicast L2 de 01.00.5e.6f.ef.ef. Tanto o Switch 1 como o Switch 2 criam uma entrada em suas tabelas de rastreamento para esses receptores em resposta aos relatórios IGMP que os receptores geram. O Switch 1 insere a porta Gigabit Ethernet 2/48 em sua tabela e o Switch 2 insere a porta Fast Ethernet 1/0/47 em sua tabela.

Observação: neste ponto, a origem de multicast não iniciou seu tráfego e nenhum dos switches sabe sobre a porta mrouter do switch.

Quando a origem no Switch 1 começa a transmitir tráfego multicast, o Switch 1 "viu" o relatório IGMP do Receptor 1. Como resultado, o Switch 1 fornece a porta de saída multicast Gigabit Ethernet 2/48. Mas, como o Switch 2 "absorveu" o relatório IGMP do Receptor 2 como parte do processo de rastreamento IGMP, o Switch 1 não vê um relatório IGMP (solicitação de multicast) na porta Gigabit Ethernet 2/46. Como resultado, o Switch 1 não envia nenhum tráfego multicast para o Switch 2. Portanto, o Receptor 2 nunca recebe nenhum tráfego multicast, mesmo que o Receptor 2 esteja na mesma VLAN, mas meramente em um switch diferente da origem multicast.

A razão para esse problema é que o rastreamento de IGMP não é realmente suportado em nenhuma plataforma Catalyst sem um roteador mr. O mecanismo é "interrompido" na ausência de uma porta mrouter. Se você quiser uma correção para essa solução, você deve fazer com que os switches aprendam ou saibam de alguma forma sobre uma porta mrouter. Consulte a seção Soluções deste documento para obter explicações adicionais sobre o procedimento. Você ainda precisa descobrir como a presença de uma porta mrouter nos switches resolve o problema.

Basicamente, quando os switches aprendem ou sabem estaticamente sobre uma porta mrouter, ocorrem duas coisas críticas:

• O switch "retransmite" os relatórios IGMP dos receptores para a porta do roteador mr, o que significa que os relatórios IGMP vão para o roteador multicast. O switch não retransmite todos os relatórios IGMP. Em vez disso, o switch envia apenas alguns dos relatórios para o roteador mr. Para efeitos deste debate, o número de relatórios não é importante. O roteador multicast só precisa saber se há pelo menos um receptor que ainda esteja interessado no downstream multicast. Para fazer a determinação, o roteador multicast recebe os relatórios IGMP periódicos em resposta às suas consultas IGMP.

• Em um cenário multicast somente de origem, no qual nenhum receptor ainda "entrou", o switch envia apenas o fluxo multicast pela porta do roteador mr.

Quando os switches conhecem sua porta mrouter, o Switch 2 retransmite o relatório IGMP que o switch recebeu do Receptor 2 para sua porta mrouter. Esta porta é Fast Ethernet 1/0/33. O Switch 1 obtém esse relatório IGMP na porta do switch Gigabit Ethernet 2/46. Da perspectiva do Switch 1, o switch recebeu apenas outro relatório de IGMP. O switch adiciona essa porta à sua tabela de rastreamento IGMP e começa a enviar o tráfego multicast nessa porta também. Neste ponto, ambos os receptores recebem o tráfego multicast solicitado e o aplicativo funciona como esperado.

Para descobrir como os switches identificam sua porta mrouter de modo que o snooping IGMP funcione como esperado em um ambiente simples, consulte a seção Soluções para obter respostas.

Soluções

Opção 1: Ativar o PIM no roteador de camada 3/interface VLAN

Todas as plataformas Catalyst têm a capacidade de aprender dinamicamente sobre a porta mrouter. Os switches escutam passivamente as mensagens de saudação do Protocol Independent Multicast (PIM) ou as mensagens de consulta IGMP que um roteador multicast envia periodicamente.

Este exemplo configura a interface virtual comutada (SVI) VLAN 1 no Catalyst 6500 com ip pim sparse-mode .

Switch1#show run interface vlan 1
!
interface Vlan1
 ip address 10.1.1.1 255.255.255.0
 ip pim sparse-mode
end

- Switch 1 now reflects itself (Actually the internal router port) as an Mrouter port. 

Switch1#show ip igmp snooping mrouter 
vlan            ports
-----+----------------------------------------
   1  Router

- Switch 2 receives the same PIM hellos on its Fa 1/0/33 interface. So it assigns that port as its Mrouter port.

Switch2#show ip igmp snooping mrouter 
Vlan    ports
----    -----
   1    Fa1/0/33(dynamic)

Opção 2: Ativar o recurso IGMP Querier em um switch Catalyst de Camada 2

Quando uma rede/VLAN não tem um roteador que possa assumir a função de roteador multicast e fornecer a descoberta de mrouter nos switches, você pode ativar o recurso consultante IGMP. O recurso permite que o switch de Camada 2 crie proxy para um roteador multicast e envie consultas IGMP periódicas nessa rede. Essa ação faz com que o switch se considere uma porta mrouter. O restante dos switches na rede simplesmente definem suas respectivas portas mrouter como a interface na qual receberam essa consulta IGMP.

Switch2(config)#ip igmp snooping querier

Switch2#show ip igmp snooping querier 
Vlan      IP Address     IGMP Version   Port               
-------------------------------------------------------------
1         10.1.1.2        v2             Switch

O Switch 1 vê agora que a porta Gig 2/46 está vinculada ao Switch 2 como uma porta mrouter.

Switch1#show ip igmp snooping mrouter 
vlan            ports
-----+----------------------------------------
   1  Gi2/46

Quando a origem no Switch 1 começa a transmitir o tráfego multicast, o Switch 1 encaminha o tráfego multicast para o Receptor 1 encontrado através de snooping IGMP (isto é, porta de saída Gig 2/48) e para a porta mrouter (isto é, porta de saída Gig 2/46).

Opção 3: Configurar a porta estática do roteador principal no switch

O tráfego multicast falha dentro da mesma VLAN de Camada 2 devido à falta de uma porta mrouter nos switches, a seção Compreender o Problema e suas Soluções aborda este tópico. Se você configurar estaticamente uma porta mrouter em todos os switches, os relatórios de IGMP podem ser retransmitidos nessa VLAN para todos os switches. Como resultado, o multicasting é possível. Portanto, no exemplo, você deve configurar estaticamente o Switch Catalyst 3750 para ter Fast Ethernet 1/0/33 como uma porta mrouter.

Neste exemplo, você precisa de uma porta mrouter estática apenas no Switch 2:

Switch2(config)#ip igmp snooping vlan 1 mrouter interface fastethernet 1/0/33

Switch2#show ip igmp snooping mrouter
Vlan    ports
----    -----
   1    Fa1/0/33(static)

Opção 4: Configurar entradas MAC de multicast estáticas em todos os switches

Você pode fazer uma entrada estática de CAM (Content-addressable memory) para o endereço MAC multicast em todos os switches para todas as portas receptorase portas downstream do switch. Qualquer switch obedece às regras estáticas de entrada de CAM e envia o pacote por todas as interfaces especificadas na tabela CAM. Essa é a solução menos escalável para um ambiente que tem muitos aplicativos multicast.

Switch1(config)#mac-address-table static 0100.5e6f.efef vlan 1 interface gigabitethernet 2/46 gigabitethernet 2/48

Switch1#show mac-address-table multicast vlan 1

 vlan   mac address     type   learn qos             ports
-----+---------------+--------+-----+---+--------------------------------
   1  0100.5e6f.efef    static  Yes          -   Gi2/46,Gi2/48


Switch2(config)#mac-address-table static 0100.5e6f.efef vlan 1 interface fastethernet 1/0/47

Switch2#show mac-address-table multicast vlan 1
Vlan    Mac Address       Type       Ports
----    -----------       ----       -----
   1    0100.5e6f.efef    USER        Fa1/0/47

Opção 5: Desativar o IGMP Snooping em todos os switches

Se você desabilitar o snooping IGMP, todos os switches tratarão o tráfego multicast como um tráfego de broadcast. Isso inunda o tráfego para todas as portas nessa VLAN, independentemente de as portas terem receptores interessados para esse fluxo multicast.

Switch1(config)#no ip igmp snooping

Switch2(config)#no ip igmp snooping

Informações Relacionadas

• Multicast em uma rede de campus: rastreamento de CGMP e IGMP
• Matriz de suporte de Switches de transmissão múltipla Catalyst
• Suporte a Multicast IP
• Notas técnicas para solucionar problemas com multicast IP
• Guia de solução de problemas de multicast IP
• Suporte técnico e downloads da Cisco