Como você diagnostica a perda de pacotes?

Sei que isso é muito subjetivo e depende de várias variáveis, mas estou me perguntando que etapas a maioria das pessoas executa quando precisam diagnosticar a perda de pacotes em um determinado sistema?

Eu sou engenheiro de rede, então descreverei isso da minha perspectiva.

Para mim, o diagnóstico da perda de pacotes geralmente começa com "não está funcionando muito bem". A partir daí, geralmente tento encontrar o kit o mais próximo possível das duas extremidades da comunicação (normalmente, uma estação de trabalho em um escritório e um servidor em algum lugar) e executar ping o mais próximo possível da outra extremidade (idealmente, o "ponto de extremidade remoto", mas, às vezes, existem firewalls pelos quais não consigo enviar pings, portanto, é necessário aceitar uma interface de rede local em um roteador) e ver se vejo alguma perda.

Se eu vejo perda, geralmente é um caso de "largura de banda insuficiente" ou "vínculo com problemas" em algum lugar intermediário; portanto, encontre a rota pela rede e comece do meio, que geralmente oferece uma extremidade ou outra.

Se eu não conseguir ver a perda, os próximos dois passos tendem a ser "enviar mais pings" ou "enviar pings maiores". Se isso não der uma indicação do problema, é hora de começar a examinar as políticas de QoS e as estatísticas da interface por todo o caminho entre os pontos finais.

Se isso não encontrar nada, é hora de começar a questionar suas suposições, você está realmente sofrendo de perda de pacotes. A única maneira segura de descobrir isso é fazer capturas simultâneas nas duas extremidades, usando o WireShark (ou equivalente) nos hosts ou conectando máquinas sniffer (provavelmente usando o WireShark ou similar) através de torneiras de rede. Depois, vem a diversão de comparar as duas capturas de pacotes ...

Às vezes, o que é atribuído como "perda de pacotes" é simplesmente algo do lado do servidor sendo notavelmente mais lento (como, por exemplo, mover o banco de dados de "na mesma LAN" para "20 ms de distância" e usar consultas que exigem uma quantidade enorme de recursos. alternância entre o front-end e o banco de dados).

Da perspectiva de um sistema Linux, procurarei primeiro a perda de pacotes na interface de rede ethtool -S ethX.

Na maioria das vezes, aumentar o buffer do anel ethtool -G ethX rx VALUEresolve isso.

Às vezes, as interrupções não estão equilibrando porque o sistema está faltando o serviço irqbalance, então procure em chkconfig(EL) ou update-rc(Debuntu) para ver se esse serviço está em execução. Você pode saber se as interrupções não estão equilibrando porque /proc/interruptsmostrará apenas o Core 0 atendendo a todos os canais de IRQ.

Caso contrário, talvez seja necessário aumentar net.core.netdev_max_backlogse o sistema estiver passando mais do que alguns gigabit de tráfego e talvez net.core.netdev_budget.

Se isso não funcionar, você pode ajustar os valores de interrupção da coalescência com ethtool -C.

Se não houver quedas de pacotes na interface de rede, netstat -sverifique e veja se há quedas nos buffers de soquete, elas serão relatadas com estatísticas como " pruned from receive queue" e " dropped from out-of-order queue".

Você pode tentar aumentar os buffers padrão e máximo de soquete para o protocolo apropriado (por exemplo: net.ipv4.tcp_rmempara TCP).

Se o aplicativo definir seu próprio tamanho de buffer de soquete, ele poderá precisar de alterações na configuração. Se o seu aplicativo tiver tamanhos de buffer de soquete codificados, reclame com o fornecedor do aplicativo.

Pessoalmente, não gosto de descarregar protocolos em NICs (soma de verificação, descarregamento de segmentação, descarregamento de recebimento grande), pois parece causar mais problemas do que vale a pena. Brincar com essas configurações ethtool -Kpode valer a pena.

Observe as opções do módulo para sua NIC ( modinfo <drivername>), pois pode ser necessário alterar alguns recursos. Para dar um exemplo que encontrei, o uso do Flow Director da Intel em um sistema que lida com um grande fluxo TCP provavelmente prejudicará a eficiência desse fluxo, portanto, desative o FDir.

Além disso, você está ajustando manualmente esse sistema específico para sua carga de trabalho específica, o que eu acho que está além do escopo da sua pergunta.

Começarei usando a ferramenta de captura de pacotes, como: wireshark (no Windows) e tcpdump (no terminal Linux).

Também vou verificar a configuração do firewall (firewall do host e firewall da rede).

Isole e elimine.

Encontre o menor subconjunto de caminhos com o problema. Faça isso testando diferentes combinações e / ou destilando relatórios do usuário. Não se esqueça de levar em consideração o tempo na equasão. Talvez seja apenas a perda de pacotes em todo o tráfego para uma rede específica, ou talvez apenas os clientes sem fio estejam sofrendo. Leve em consideração diferentes tipos de tráfego (limite de taxa de pings). Encontre a maneira mais confiável e fácil de repetir para testá-lo.

Em seguida, elimine possíveis causas. Reduza o tráfego nos links (temporariamente), remova fontes de interferência do espectro, desconecte determinados clientes. Eventualmente, você encontrará a fonte do problema.

Às vezes, você pode usar atalhos observando despejos de pacotes ou adivinhar (sempre é bittorrent). Além disso, diga que a falha do servidor do seu professor é incrível.

Os pings podem não mostrar perda de pacotes, a menos que você envie pings grandes! Eu tinha perda de pacotes na minha rede que estava invisível até aumentar o tamanho do meu pacote de ping.

Para Windows:

ping -n 30 -l <largevalue> <target>

Para largevalueeu usei 40960 (pacote de 40k)

Para targeteu usei os primeiros endereços IP detracert google.com

(quais eram meus roteadores e modem a cabo). Um dos dispositivos mais abaixo na cadeia teve uma perda terrível de pacotes (> 60%) para pacotes grandes, mas 0% para pequenos. Corrigi-o reiniciando-o, mas também poderia ser um cabo ou algo interno que precise ser substituído.