Todos nós já tivemos uma reclamação de que a "rede" está "lenta" em algum momento: pode estar localizada em uma sala (switch) ou em um computador, pode ser apenas a Internet (DNS? Problema no navegador?), Pode ser apenas um aplicativo (consultas SQL de longa execução? verificação AV em execução?).
Quando você descarta problemas óbvios de sistema e / ou aplicativo, como você testa uma rede quanto a lentidão ou comportamento irregular? Você trabalha nas camadas OSI? Se sim, como proceder para verificar cada camada? O que você faz para garantir que a rede física esteja correta em um ambiente desconhecido? Que tal muitas transmissões ou uma tempestade de transmissão? Camada 3 e acima? traceroute? Alguma outra dica, método, idéia? Recursos e ferramentas indispensáveis (espelhamento de porta, SNMP, monitoramento etc.) para todos os tamanhos de redes?
fonte
Respostas:
tcpdump e wireshark são seus amigos.
Acho que assistir pacotes no fio de uma rede "lenta" versus uma rede "boa" é geralmente o que identifica um problema.
Existem muitos tipos de 'lento'.
Você pode acompanhar a latência de sites locais e da Internet usando uma ferramenta como o SmokePing. (SmokePing pode ser configurado para rastrear a latência do ICMP, bem como a latência do serviço dos serviços TCP)
Seus comutadores devem rastrear pacotes de transmissão versus pacotes unicast. Faça um gráfico dessa proporção.
Também gosto de monitorar traceroutes (verificar nomes de domínio de saltos de ISP entre sites 'importantes').
Espero que esses comentários ajudem.
fonte
É difícil dar respostas específicas, já que 90% desse trabalho é uma experiência que ensina onde procurar por qual tipo de problema e os outros 90% sabem onde procurar no Google para obter dicas de onde começar.
Normalmente, experimento o saco de papel, como fazer com que o cliente demonstre o problema (principalmente para descartar problemas com os dedos e quaisquer problemas que o cliente possa ter ao descrever o problema), e depois tentar duplicar o problema em outro computador. Fazer isso com frequência fornece informações sobre onde procurar.
Não esqueça o problema corretivo de uma reinicialização, especialmente para sistemas Windows, ainda hoje. Costumava ser assim tanto que eu perguntava às pessoas "Você reiniciou? Bem, tente isso e deixe-me saber se o problema persistir" - isso corrigiu uma porcentagem muito grande dos problemas sobre os quais me perguntaram.
Freqüentemente, também há problemas em problemas de resolução de DNS e conectividade básica (ACLs em roteadores, intervalos de ar na rede, pings / traceroutes / mtrs para sites remotos, etc.).
Para serviços que você tem controle direto, a execução de nagios ou algo para garantir que o serviço esteja realmente em execução pode frequentemente desencadear a correção de problemas antes que os clientes falem sobre eles. Você provavelmente também deseja executar estatísticas, diretamente através de munin ou algo assim, ou via SNMP para algo como o Cacti.
Normalmente, tento fazer com que o Cacti funcione contra pelo menos todos os meus switches e firewalls principais; sempre que possível, corro o Cacti contra tudo o que posso. Nesses casos, geralmente procuro coisas como contagem de erros de porta ou tráfego excessivo. Os gráficos de firewall de alguns dispositivos podem mostrar o uso da CPU e sessões simultâneas; você aprenderá em quais limites seu dispositivo de firewall começa a ter problemas.
Seu firewall pode conseguir fazer logon em um dispositivo syslog; Nesse caso, registre tudo o que puder e procure por dicas. Isso será mais fácil se você executar algo como syslog-ng ou rsyslog ou splunk que permita dividir seus logs um pouco, em vez de lidar com um arquivo monolítico.
Eu também tento rodar o nfsen contra pelo menos o interior do meu firewall e a ligação ao provedor de internet sempre que possível. Isso permite que você volte no tempo para ver as sessões e ver quem estava fazendo o que; isso às vezes pode pegar comportamentos interessantes.
fonte
Aqui estão algumas ferramentas úteis para solucionar problemas de latência e outros problemas de rede:
fonte
ping 8.8.8.8
funciona, mas umping -r 9 8.8.8.8
nãoSe você estiver executando uma rede sem fio, uma das lentidões frequentes é a interferência do canal. Um monte de SSIDs em uma área pode realmente diminuir o tráfego da rede. (Pense: a demonstração do iPhone 4 na WWDC '10).
A solução desse problema é bastante fácil se houver um software que mostre os padrões de tráfego sem fio na área. Existe um bom e gratuito e baseado na Web em: http://meraki.com/tools/stumbler . (divulgação: eu trabalho para Meraki)
Para reduzir a interferência, é melhor estar nos canais 1, 6 ou 11. O uso de equipamentos 802.11n com a frequência de 5GHz também pode ajudar.
fonte
Eu sempre começo monitorando as coisas da camada 2 usando o Cacti . Isso fornecerá uma boa quantidade de dados que você poderá usar para procurar padrões e poderá comparar seus gráficos Cacti quando tudo estiver funcionando bem versus quando os usuários veem lentidão.
Provavelmente não encontrará o problema exato, mas fornecerá um bom ponto de partida para ajudar a diminuir o problema.
fonte
Começo no roteador mais externo e caminho até o fim, e medo o desempenho da maneira mais primitiva: use um site de teste de largura de banda ou um site FTP externo conhecido que lhe dará velocidade de upload / download e continue diminuindo até que você encontre o nível em que o problema reside.
Depois de saber onde está o problema, implante suas ferramentas e monitores sofisticados. Mas não perca tempo fazendo essas coisas em todas as camadas. Vai demorar para sempre.
fonte
Você também precisa conhecer seus servidores e o ambiente de área de trabalho / cliente, em vez de simplesmente assumir que o usuário está correto quando diz "a rede está lenta". Você precisa solucionar metodicamente cada problema - como já foi dito, você deve primeiro visualizar e reproduzir idealmente o erro e, a partir daí, trabalhar de uma maneira que faça sentido para o cenário.
Ter uma boa gestão e monitoramento da rede e servidores podem poupar-lhe muito tempo, no entanto, porque você não está tentando chegar a instrumentação on the fly enquanto possivelmente também tentando mitigar ou corrigir os sintomas, e lidar com usuários reclamando /clientes.
As respostas para tcpdump e wireshark não estão erradas; elas podem ser partes vitais do seu kit de ferramentas. Mas, a menos que você tenha certeza absoluta de que é realmente a rede, eles não devem ser a primeira coisa a ser alcançada.
fonte
Rede lenta é um fenômeno comum. A velocidade lenta da rede pode ser causada por várias coisas. solucionar problemas de rede lenta é um dos trabalhos mais comuns e problemáticos no gerenciamento diário da rede.
Segundo a análise, os principais motivos para uma rede lenta são:
Como podemos descobrir rapidamente a causa da lenta rede? É uma boa ideia capturar e analisar pacotes com um analisador de rede (Ax3soft Unicorn, wireshark e assim por diante).
Você também leu o artigo "Localizar motivos para a rede lenta", clicando no URL ( http://www.ids-sax2.com//Unicorn/Tutorials/Find-Reasons-for-Slow-Network-with-Ax3soft-Unicorn .htm ) para visitá-lo.
fonte