Causas Comuns para a Perda de Pacotes

A identificação da origem da perda de pacotes exige uma distinção clara entre problemas de infraestrutura de rede e limitações dos hossts (servidores).

Fatores Relacionados à Infraestrutura de Rede

• Sobrecarga em Ativos: Switches e roteadores com processamento (CPU) ou memória RAM operando em níveis críticos.
• Falhas de Camada Física: Problemas em cabos, transceivers (SFP) ou instabilidade em links de fibra óptica.
• Erros de CRC: Falhas de redundância cíclica que resultam no descarte de frames corrompidos.
• Congestionamento de Link: Quando o tráfego excede a largura de banda disponível, causando o preenchimento total dos buffers (bufferbloat).
• Bloqueios em Operadoras: IPs que entram em "Blackhole" (buraco negro) por decisão administrativa de provedores ou trânsitos IP.
• Desbalanceamento de Carga: Configurações inadequadas de LACP ou ECMP que sobrecarregam apenas uma das rotas disponíveis.

Fatores Relacionados ao Host

• Exaustão de Recursos do Sistema: Alta carga de CPU no servidor, impedindo o processamento tempestivo das interrupções de rede (SoftIRQs).
• Defeitos de Hardware: Falhas na Placa de Interface de Rede (NIC).
• Camada de Virtualização: Sobrecarga no Hypervisor ou configuração incorreta de vSwitches e bridges em ambientes de nuvem.

Ferramentas de Diagnóstico e Metodologia

1. Utilização do utilitário Ping

O ping utiliza o protocolo ICMP para verificar a conectividade básica. É importante notar que muitos firewalls bloqueiam mensagens ICMP Echo Request, o que pode gerar falsos positivos de queda.

• Linux: O comando envia pacotes continuamente por padrão.
• Windows: Envia apenas 4 pacotes, a menos que o parâmetro -t seja utilizado.

2. Rastreamento de Rota com Traceroute

Esta ferramenta identifica o caminho percorrido pelo pacote até o destino. Por padrão, o traceroute utiliza pacotes UDP ou ICMP. Em muitos casos, firewalls descartam esses pacotes, resultando em asteriscos (* * *) no log. O uso de flags para protocolo TCP pode contornar essa limitação.

# Traceroute padrão (UDP/ICMP)
traceroute servicos.exemplo.com.br

# Traceroute utilizando TCP (porta 80) para bypass de firewalls
traceroute -T -p 80 servicos.exemplo.com.br

3. Análise Dinâmica com MTR (My Traceroute)

O mtr é a ferramenta mais completa, pois combina as funcionalidades do ping e do traceroute em uma interface que atualiza os dados em tempo real, facilitando a visualização de perda de pacotes em saltos (hops) específicos.

# Executando um relatório estático com 15 ciclos de verificação
mtr --report --report-cycles 15 203.0.113.42

Exemplo Prático de Diagnóstico

Considere um cenário onde um servidor não consegue alcançar um destino externo. Ao rodar o diagnóstico, observamos o seguinte comportamento:

# mtr -rw 1.1.1.1
Start: 2023-10-27T10:00:00
HOST: srv-producao                Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- gateway-local              0.0%    10    0.4   0.5   0.3   0.8   0.1
  2.|-- 192.168.100.1              0.0%    10    1.1   1.2   1.0   1.5   0.2
  3.|-- edge-router-isp            0.0%    10    5.2   5.5   5.1   6.2   0.3
  4.|-- core-transit-sp           40.0%    10   12.1  12.4  11.9  13.1   0.4
  5.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
  6.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0

**Análise do log:**No exemplo acima, o tráfego flui normalmente até o terceiro salto (roteador da operadora). No quarto salto, começa uma perda significativa (40%), e a partir do quinto salto, o tráfego é totalmente interrompido. Isso indica que a falha não é interna, mas reside na infraestrutura de trânsito IP da operadora ou em um bloqueio (blackhole) configurado logo após o ponto de presença de São Paulo.

Para mitigar esse problema em ambientes Cloud, uma solução rápida seria a alteração do endereço IP público da instância, forçando o tráfego por uma rota que não esteja sob bloquieo administrativo.