tshark (wireshark) para identificar o problema de reconfiguração / retransmissão de conexão

Question

Windows server 2003.

Eu tenho o último WireShark instalado no servidor e preciso capturar pacotes no servidor para identificar um problema de redefinição / retransmissão de conexão aleatoriamente ocorrido. Quando a reinicialização da conexão acontece, ela redefine cerca de 600 conexões / seg, onde o valor normal deve estar abaixo de 100 / seg. O servidor é, na verdade, uma máquina virtual no host do Cisco UCS. A captura de pacotes tshark pode ajudar a descobrir a causa?

Outra questão é que, como vou capturar todos os tráfegos (não sei se é uma boa ideia), também faço o fatiamento de pacotes. Minha pergunta é quantos bytes devem limitar para cada pacote. Parece que o pacote que eu capturei tem 54 bytes para o cabeçalho (parece incluir Frame, EthernetII, Internet Protocol, parte TCP). Devo usar apenas

tshart -q -b "filesize:20000" -b "files:5" -s 54 -w c:\outfile.pcap

para que toda a carga útil não seja salva? Por favor, avise, obrigado!

    

Answer 1

Para ethernet normal, seu snaplen ( -s option) deve ser 1500 se você quiser o pacote inteiro. Isso lhe dará todo o pacote e permitirá decodificações completas do protocolo quando carregadas no próprio WireShark. Dependendo do que você está farejando, provavelmente também desejará aumentar seu tamanho de arquivo.

Para obter pelo menos os cabeçalhos da maioria dos pacotes, um snaplen de 200 é geralmente suficiente. Ele terá o E_II, IP, TCP / UDP e alguns dos cabeçalhos de protocolo de nível superior.

Existem alguns tipos de reconfigurações de conexão e cada um tem seu próprio significado.

Redefinindo todas as conexões existentes imediatamente

Este estilo de reset aparece em sniffs como um grande bloco de RSTs sendo enviados pelo servidor, provavelmente com muito pouco tráfego entre os pacotes. Isso pode ser causado por um aplicativo acima da própria pilha TCP / IP sendo reconfigurada, o que, por sua vez, informa a pilha TCP / IP para eliminar todas as manipulações de conexão associadas a esse módulo.

Redefinindo todas as conexões existentes quando elas têm tráfego

Isso aparece no sniff com um padrão mais sorrateiro. Depois de um certo ponto, sempre que uma conexão existente recebe tráfego de uma estação cliente, um pacote RST é emitido. O que o cliente faz depende do protocolo de nível superior, talvez uma tentativa de reconexão seja emitida. Isso geralmente é causado pela própria pilha TCP / IP perdendo silenciosamente o estado da conexão. No que diz respeito à pilha, esse pacote do cliente não está associado a nenhuma conexão aberta, por isso apenas emite um pacote RST e o ignora.

Redefinindo novas tentativas de conexão

As conexões existentes continuam a funcionar, mas os pacotes SYN são respondidos com um RST. Em operação normal, isso é feito porque não há porta aberta para a porta listada no pacote SYN. Isso geralmente é causado por uma falha no aplicativo de nível superior.

Quanto às suas retransmissões, elas são causadas por clientes que não recebem pacotes que esperam obter. Isso pode ser causado pela perda completa de pacotes, ou pode ser que o servidor simplesmente não esteja enviando esses pacotes. Se o seu sniff no servidor mostra os pacotes de retransmissão, e listar a conversa não mostra nenhum pacote sendo enviado pelo servidor, é um sinal de que algo deu errado no próprio servidor. Isso pode estar relacionado a falhas no aplicativo de nível superior, na pilha TCP / IP ou no próprio driver da NIC. Eu vi atualizações de driver da NIC corrigir isso, mas em uma VM é menos provável que seja a fonte do problema. Redefinições em massa como essa podem ser causadas pelo esgotamento de recursos por parte do servidor.