Como rastrear o motivo da desistência da conexão com a Internet

Question

Cenário: pequenas empresas com cerca de 40 usuários por trás de um firewall Watchguard XTM 3.0 e conexão de Internet de linha dedicada de 20Mb.

Problema: os usuários experimentam desistências ocasionais na conectividade com a Internet. Estes são particularmente irritantes durante as chamadas VOIP, por exemplo, Skype como quebras de conexão. A navegação em sites da Internet também é afetada quando os desistentes ocorrem. Os desistentes são regulares o suficiente para ser um problema de negócios, embora na maioria das vezes tudo esteja bem.

Comentários: Achamos que o problema está no nosso final, já que as chamadas para os mesmos destinatários do Skype de outros lugares, por exemplo, a banda larga doméstica, parecem funcionar bem. O problema também persistiu através de uma atualização do ADSL para a linha alugada. No entanto, gostaríamos de saber definitivamente se o problema está na LAN ou na WAN. Atualmente, os switches não são gerenciados, mas logo serão substituídos por novos switches gerenciados. Os desistentes ocorrem para os usuários em qualquer lugar da LAN, até onde podemos dizer.

Alguma ideia de como rastrear a causa dos desistentes? Eu me pergunto se existe uma maneira de testar a continuidade da conexão dentro do XTM? Você pode ver facilmente que não há desistências de longo , mas como podemos testar para desistências curtas (mas tempo suficiente para interromper uma chamada pelo Skype)?

A razão mais provável é algo na LAN - como reduzir isso sem deixar as pessoas desconectadas por longos períodos?

Tim

    

Answer 1

Encontrar a fonte desse tipo de problema pode ser extremamente frustrante, especialmente se forem raras. No entanto, é assim que eu me aproximo dos problemas de rede intermitentes

1. Mapeie a rede com o melhor de sua capacidade
2. Identifique sistemas potencialmente problemáticos
3. Crie uma solução de monitoramento (de preferência automatizada) para identificar onde o problema está localizado
4. Lide com o problema.

Os passos 1 e 2 devem ser relativamente diretos. Um desenho em um quadro branco com o caminho completo e os sistemas envolvidos é útil. Para o passo 3, costumo usar o Nagios ou outras soluções de monitoramento de longo prazo. Existem muitos plugins para nagios que podem ser úteis, e você pode configurá-lo para monitorar muitas propriedades dos sistemas com uma resolução muito alta do seu NOC. O monitoramento tem dois propósitos. Uma delas é coletar informações para posterior depuração, mas também informa sobre problemas que permitem correlacioná-las mais facilmente a fontes. Quando se trata de problemas de conectividade de rede intermitentes, certifico-me de configurar os testes de monitoramento e conectividade de roteamento para todos os sistemas ao longo do caminho.

Depois de encontrar uma solução para o problema, implemente-a e deixe o monitoramento no local até ter certeza de que o problema foi resolvido.

A propósito, equipamentos não gerenciados não têm lugar em uma rede de produção, como você provavelmente já descobriu. Depurar problemas em uma LAN sem acesso a pelo menos SNMP nos switches é uma enorme dor de cabeça. E se você não tiver sorte, um único patch entre duas portas de rede em algum lugar da rede é suficiente para fazer com que sua rede falhe e queime ...

    

Answer 2

Suponho que você poderia fazer testes de ping simples em seus switches e registrar / acompanhar onde e quando os dropouts ocorrem (e em quais switches eles acontecem), correlacionar esses dados com latência e pings descartados de seus testes de ping. Isso não será especialmente preciso, mas é o melhor que você fará com switches não gerenciados. Também deve ser suficiente fazer uma avaliação instruída sobre se é uma limitação em qualquer switch específico ou um problema maior, como saturação da rede ou largura de banda insuficiente em algum ponto de sua LAN.

Em suma, a solução ea única maneira de realmente reduzir muito isso é obter switches gerenciados para que você possa obter um mapa detalhado do uso da rede (isso pode ser um problema de saturação de rede ou largura de banda insuficiente, fazendo com que os pacotes ser deixado em algum lugar ao longo da linha) e configurar o QoS. Se você usa o VOIP, precisa de QoS .

    

Answer 3

Se você tem algo que está realmente quebrando uma chamada do Skype com apenas uma pequena interrupção para conectividade real (< 15s), isso provavelmente seria algo ativamente derrubando a conexão.

Para o diagnóstico, você poderia adotar uma abordagem analítica executando um rastreamento completo de pacotes (usando Wireshark ou Network Monitor) em uma das estações afetadas até que o problema ocorra e procurando no rastreio possíveis indícios de porque a troca de pacotes UDP a conexão do Skype foi interrompida (já que a chamada do Skype provavelmente será o único protocolo baseado em UDP muito utilizado no momento da chamada, você deve ser capaz de identificar o fluxo facilmente). Você pode ver algo como um pacote inacessível por destino de ICMP de um dos roteadores no caminho, o que lhe daria uma dica sobre onde procurar mais ou apenas a ausência de pacotes de resposta para quaisquer solicitações indicando que é um problema de conectividade entre o cliente e o resto da rede.

Você também pode querer procurar os logs do Watchguard para ver se alguma entrada se correlacionaria com os desmembramentos de conexão relatados. O mesmo vale para os logs do cliente para ver se ele pode ter perdido a conexão e / ou reconfigurado a interface IP.

Além disso, considere possíveis pontos de falha e tente gravar dados de conectividade por trás desses pontos, por exemplo,

• um ping contínuo para um servidor interno para verificar se é algo com a infraestrutura de comutação
• um ping contínuo para o primeiro salto na rede atrás de sua Watchguard para ver se ele pode estar relacionado à Watchguard ou à linha
• um ping contínuo para um host de Internet bem conhecido com boa disponibilidade (como 8.8.8.8) para verificar a conectividade geral com a Internet