Diagnosticando e depurando problemas de congestionamento / conexão da LAN

Question

Quais são as principais ferramentas / metodologias do N usadas para diagnosticar e reparar problemas de rede?

Considerando uma rede local, por exemplo, onde os usuários podem fazer ping de maneira consistente em um servidor externo, mas as conexões que exigem muitos dados são escassas; como você começaria a resolver os problemas de rede?

Eu imagino que problemas como congestionamento, restrições de largura de banda, restrições de taxa de transferência etc. são fatores, mas não sei como diagnosticar esses problemas.

Estou especialmente interessado em ambientes LAN (em vez de WAN)

    

Answer 1

Este é um assunto muito amplo, mas como um começo, um farejador de rede \ pacotes é uma ferramenta inestimável. Existem muitos disponíveis. Eu costumo usar várias ferramentas dependendo do tipo de problema de rede que é. Eu uso o Wireshark principalmente para solucionar problemas entre dois dispositivos específicos (cliente para servidor, servidor para servidor, etc), e uso o Colasoft Capsa para solucionar problemas de congestionamento e utilização. O Wireshark é muito bom em mostrar as porcas e parafusos das conversas em rede, mas pode ser um pouco avassalador ao tentar "visualizar" um problema geral de congestionamento ou utilização. O Colasoft Capsa é muito melhor para obter uma visão "visualizada" do problema.

Se você estiver com uma comunicação de rede lenta \ desempenho (devido a congestionamento e \ ou utilização), será necessário procurar o seguinte:

Um grande número de difusões de rede (na camada de rede ou na camada física) e \ ou um grande número de retransmissões TCP e confirmações lentas.

Um grande número de transmissões pode ser uma indicação de um NIC, host, switch, software, driver, etc., mal configurado ou com defeito, e também pode ser uma indicação de uma infecção por malware em algum ponto da rede. As transmissões podem causar congestionamento e, por sua vez, alta utilização de links de rede (portas de switch), pois cada host deve ouvir o tráfego de broadcast para determinar se o tráfego é destinado a si mesmo.

As retransmissões TCP e confirmações lentas são também uma indicação do congestionamento da rede. O congestionamento faz com que os pacotes sejam lentos para serem transmitidos e recebidos e faz com que os ACKs sejam recebidos "atrasados", forçando o host transmissor a retransmitir o pacote pelo qual está aguardando o ACK. Se você tem um congestionamento de tal forma que é a causa de retransmissões e ack's lentos, então pode ter certeza de que está causando problemas de desempenho.

    

Answer 2

Eu usei mtr (traceroute baseado em tela linux) com uma taxa de ping lento (1 a 2) por minuto para monitorar a resposta ao ponto final. Se um ou mais interruptores estão ficando congestionados, eles mostram pings caídos ou respostas lentas. Isso pode ser resultado de problemas de duplex.

Em algumas condições, vi roteadores da Cisco parecerem executar half-duplex em links codificados em full-duplex. Problemas duplex podem ser testados por meio da transferência de um arquivo grande nos dois sentidos. Será muito mais lento em uma direção do que na outra. Isso impossibilitou a instalação de pacotes na rede.

Dumping error counters em todas as interfaces (host e roteador) ao longo do caminho pode ser útil. Os contadores de erros devem ser 0 ou valores baixos e não aumentar a uma taxa visível.

    

Answer 3

Não tenho certeza se o seu um Windows House, mas o seguinte blog vai ser útil também obter o analisador tcp da pesquisa MS é muito legal.

link

link

    

Answer 4

Se você está enfrentando lentidão de transmissões TCP com uso intensivo de dados, você PODE estar sofrendo de "sincronização global", onde todos os falantes TCP na linha acabam com aumentos síncronos no tamanho da janela TCP (a quantidade de pendentes bytes permitidos antes que um ACK seja recebido).

Quanto maior a janela de transmissão TCP, mais rápido é o dado bombeado entre A e B. Quando você tem múltiplos hosts enviando TCP (na mesma direção) através de um único link, a largura de banda usada neste link irá variar dependendo do link. tamanho da janela de todos os hosts. Quando o link não estiver congestionado, o tamanho da janela TCP aumentará, até que os pacotes comecem a cair (geralmente para todas as sessões TCP ao mesmo tempo) eo tamanho da janela TCP será definido para o menor tamanho possível, descongestionando o link. Então, sem lugar de congestionamento, todos os remetentes aumentarão o tamanho da janela em sincronia.

Se você olhar em um gráfico de utilização de curto intervalo, isso deve ser óbvio a partir de um "dente de serra" aumentando e diminuindo acentuadamente, uma vez que a capacidade de link completo é usada. Você provavelmente vai querer algo que aponte seu uso do link WAN com mais frequência do que a cada cinco minutos, mas eu diria que as estatísticas por minuto podem ser suficientes, mas você pode ter que descer para cada 5-10 segundos. / p> A melhor maneira que eu conheço para eliminar isso é permitir o descarte antecipado aleatório ponderado, essencialmente jogando pacotes para fora antes que o link WAN esteja congestionado, de modo a tornar as janelas TCP para todos os hosts na LAN desacoplados uns dos outros. / p>