Por que o multicast torna a WAN inacessível?

3

Estou hesitante em fazer essa pergunta, pois talvez eu não consiga realizar as etapas de diagnóstico para descobrir o que está acontecendo, mas:

Eu preciso re-imaginar um laboratório em uma escola, possivelmente durante o horário escolar. Estou usando um fluxo de multicast, pois dificilmente faz sentido para o servidor compartilhar um arquivo 30 vezes. Eu ajustei a velocidade para baixo para que houvesse headroom e o resto da rede deve ser razoavelmente não afetado.

O que eu descobri é que isso parece nos tirar da WAN. Outros sites são inacessíveis, assim como a internet. A escola não pode ser vista de outro lugar enquanto a restauração multicast estiver sendo executada. (O multicast em si funciona bem).

Falei com meu colega de trabalho responsável pela rede quando isso aconteceu em um site diferente, e ele não conseguiu descobrir nada sobre o que estávamos fazendo que causaria problemas.

Detalhes: Estou fazendo uma restauração de multicast ASR usando o DeployStudio em um Mac OS X Server. A maioria dos nossos switches é da Cisco. Nós temos um número de Pontos de Acesso Sem Fio (e eles parecem passar o fluxo de multicast sem fio; não é o ideal, mas não necessariamente um problema.) Eu coloco o fluxo a uma taxa de 2 Mb / s (eu acho que é megabits, não bytes); sistemas de restauração bem às 8 e às vezes até 12 Mb / s (então eu sei que há sala de cabeça).

É minha preferência fazer streaming multicast em uma rede fisicamente separada de um em uso de produção, ou fazê-lo durante o verão, quando poucos membros da equipe estão por perto, mas eu não tenho esse luxo aqui.

O que pode explicar este problema?

    
por Clinton Blackmore 08.09.2009 / 19:56

4 respostas

4

O problema é provavelmente que o seu switch não lida corretamente com grupos multicast e, em seguida, envia multicast como broadcast (e assim inunda seu wan link, ou pelo menos o wan router) com dados inúteis). Portanto, você deve ter pelo menos um comutador agindo como um Consultor IGMP. Isso pode ser ativado nos Cisco 2960 e 3750 com o comando ip igmp snooping querier . Se sua rede tiver apenas 2950, você definitivamente terá problemas.
Você pode ver facilmente se o seu switch está transmitindo o multicast executando o wireshark em um PC enquanto você reinstala a imagem em outros computadores. (você não deve ver os dados multicast se tudo estiver funcionando bem)

Por favor, diga-nos também qual IP multicast é usado, alguns são reservados e não devem ser usados, alguns podem ser roteados e alguns não são roteáveis (veja link )

    
por 08.09.2009 / 20:25
1

Inundando o roteador que lida com seu acesso ao gateway, talvez?

Existe uma maneira de obter informações SNMP do roteador ou obter informações de log dele, status da CPU, etc.?

    
por 08.09.2009 / 20:12
1

Qual é o tamanho da conexão WAN? Dependendo do endereço multicast usado, pode ser que o tráfego multicast esteja saturando a interface WAN, por exemplo, o endereço multicast 224.0.0.1 significa "todos os hosts nesta sub-rede", o que significa que a interface WAN precisa escutar e descartar o multicast tráfego.

Se a interface WAN tiver que escutar e descartar o tráfego multicast, e o tráfego multicast estiver fluindo a uma taxa de 8 a 12 Mbps, e o link WAN for menor que 8 a 12 mbps, então eu posso ver isso causando o problema.

    
por 08.09.2009 / 20:17
1

Meu palpite é que não é um problema de WAN per se, mas que a interface lateral da LAN do seu roteador está sendo inundada por quadros multicast inundados pelo seu switch.

Como foi mencionado em outro comentário, você precisará habilitar o rastreamento IGMP para permitir que seu switch restrinja corretamente os quadros multicast. Você provavelmente também precisará habilitar o querier de snooping IGMP, a menos que você tenha um roteador multicast (PIM) em cada uma de suas VLANs. Em um switch Cisco, você pode habilitar o snooping IGMP e o querier snooping inserindo os dois comandos a seguir no modo de configuração global:

ip igmp snooping
ip igmp snooping querier

Você deve garantir que o rastreamento do igmp esteja ativado em todos os switches da sua rede. O query do snooping só precisa estar habilitado em um switch, assumindo que o switch tenha um IP em cada uma de suas VLANs. No entanto, meu entendimento é que não vai atrapalhar a ativação do query da snooping em todos os switches. Observe que, para o consultor de espionagem funcionar, o seu comutador precisará de um IP em cada uma de suas VLANs ou, pelo menos, de cada VLAN que tenha tráfego multicast que você esteja preocupado em restringir.

Caso você esteja curioso sobre o motivo de precisar de snooping IGMP:

Como você provavelmente sabe, normalmente um switch fornece tráfego consultando sua tabela CAM. A tabela CAM é preenchida inspecionando o endereço MAC de origem de cada quadro recebido pelo comutador. Cada endereço MAC de origem que o switch vê é adicionado à tabela CAM, junto com a porta do switch em que o quadro em questão entrou no switch. Dessa forma, o switch "aprende" quais endereços MAC estão conectados a cada porta.

O switch usa a tabela CAM para determinar onde entregar os quadros recebidos. Se o endereço MAC de destino for encontrado na tabela CAM, o comutador saberá para qual porta entregar o quadro e o quadro será entregue somente para essa porta. Se o endereço MAC de destino NÃO for encontrado na tabela CAM, o quadro será enviado para todas as portas do switch.

Com o tráfego multicast, o endereço MAC de origem do quadro será o endereço MAC do emissor multicast, mas o endereço MAC de destino do quadro será o endereço MAC de um grupo multicast, não o endereço MAC de um indivíduo específico PC. Esse endereço MAC multicast deve nunca normalmente ser o endereço de origem de qualquer quadro, portanto, em operação normal, o switch nunca saberá para onde enviar quadros multicast. Não terá escolha a não ser inundar os quadros de todas as portas. Quando isso acontece com um fluxo de multicast realmente grande, esses quadros inundados podem às vezes sobrecarregar outros sistemas na rede.

O IGMP é na verdade um protocolo da camada 3 projetado para permitir que hosts IP informem aos roteadores IP que gostariam de ingressar em um grupo de multicast. Tecnicamente, o IGMP não tem nada a ver com switches e camada 2, mas vários fornecedores de switches, incluindo a Cisco, acrescentaram recursos a seus switches que permitem ao switch escutar (ou bisbilhotar) o tráfego IGMP entre hosts IP e IP habilitado para multicast. roteadores.

Infelizmente, a detecção de IGMP só funciona se houver um roteador de multidifusão na (s) sub-rede (s) em questão. Se não houver um roteador habilitado para difusão seletiva, não haverá conversas IGMP para "espionar". É aí que entra o questionador de rastreamento IGMP. Ele envia as consultas de participação IGMP que normalmente seriam enviadas por um roteador multicast PIM, iniciando, assim, a troca do switch para "snoop".

Seria legal se a detecção de IGMP fosse habilitada por padrão na maioria dos switches, mas suponho que a razão disso não seja porque, enquanto o IGMP é um padrão IETF, não há nenhum padrão real para IGMP bisbilhotando.

    
por 09.09.2009 / 00:01