Quando o sistema ERP apresenta lentidão ou as ligações VoIP picotam no meio da tarde, a primeira reação da equipe de suporte costuma ser abrir um chamado genérico na operadora de telecomunicações.
- Testes simples de ping mascaram anomalias porque roteadores intermediários frequentemente descartam pacotes ICMP por política de CPU, sem que haja perda de dados real.
- O comando MTR (My Traceroute) executado de forma bidirecional por 100 ciclos revela o salto exato onde o tráfego é interrompido ou degradado.
- Erros de CRC (Cyclic Redundancy Check) nas interfaces do switch ou firewall denunciam falhas físicas em cordões ópticos e transceivers, e não instabilidade de trânsito IP.
- Links com 100% de ocupação descartam tráfego na fila de saída do roteador da borda por saturação local, problema corrigível via engenharia de QoS (Quality of Service).
Por que o comando ping tradicional esconde a origem da falha
O teste de ping simples envia pacotes do protocolo ICMP (Internet Control Message Protocol) para um destino e aguarda a resposta. Na rotina de um departamento de TI, 5 disparos consecutivos de ping não representam uma amostra estatística confiável. Roteadores de operadoras e switches de núcleo tratam requisições ICMP como tráfego de baixa prioridade em seu plano de controle. Isso significa que um salto intermediário pode responder com 10% de perda sem que nenhum pacote de dados real (TCP ou UDP) tenha sido descartado.
Outro problema clássico reside no tamanho dos pacotes de teste. O ping padrão envia datagramas minúsculos de 32 ou 64 bytes. Em redes corporativas, o tráfego produtivo trafega com pacotes completos de até 1500 bytes. Testar a integridade de uma rota com pacotes pequenos esconde problemas de MTU (Maximum Transmission Unit, ou Unidade Máxima de Transmissão), além de não sobrecarregar adequadamente a interface óptica para identificar falhas intermitentes.
O método em três etapas para isolar a camada do problema
Em um cenário corporativo típico em Campinas, com 200 colaboradores acessando sistemas em nuvem, 2% de descarte contínuo de pacotes basta para degradar sessões SSL e derrubar túneis IPsec. Antes de desviar o foco da equipe para ligações de suporte, aplique um isolamento metódico em camadas.
1. Validação física e contadores de interface
O primeiro ponto de inspeção deve ser o switch ou roteador de borda conectado ao equipamento da operadora. Acesse a linha de comando do equipamento e verifique os contadores de erro na porta física:
- Erros de CRC e Input Errors: Indicam atenuação no cordão óptico, sujeira no conector LC ou degradação no módulo transceptor SFP (Small Form-factor Pluggable). Se esses contadores sobem a cada minuto, a falha é física na ponta local.
- Output Drops: Apontam que a interface tentou transmitir mais pacotes do que a capacidade contratada suporta naquele milissegundo. O descarte ocorre na sua memória interna de fila, não no circuito externo.
Identificar essa diferença poupa horas de discussões contratuais. Como mostramos no guia sobre Auditoria de Rede e Infraestrutura de Telecom: Diagnóstico Preventivo para Negócios de Missão Crítica, a manutenção preditiva da infraestrutura passiva elimina grande parte dos falsos incidentes de telecom.
2. Verificação de MTU e fragmentação
Túneis VPN mal configurados reduzem o tamanho útil dos pacotes. Se o pacote exceder a capacidade da rede e a flag DF (Don't Fragment) estiver ativa, o descarte será silencioso. Execute um ping com tamanho de buffer fixo em 1472 bytes (que somados aos 28 bytes de cabeçalho completam os 1500 bytes de MTU padrão):
No Windows: ping 1.1.1.1 -f -l 1472
No Linux: ping -M do -s 1472 1.1.1.1
Se o teste retornar "o pacote precisa ser fragmentado mas a desfragmentação foi bloqueada", sua borda precisa de ajuste de MSS Clamping ou readequação na interface virtual.
3. Análise salto a salto com MTR bidirecional
O MTR combina a rota traçada pelo traceroute com a repetição de pacotes do ping. O segredo está em rodá-lo por pelo menos 100 ciclos contínuos durante o momento exato da instabilidade. A perda só é real se ela se propagar consecutivamente do salto onde começou até o destino final.
Se o salto 4 acusa 20% de perda, mas os saltos 5, 6 e o destino final exibem 0% de perda, não há degradação no circuito: o roteador do salto 4 apenas limitou o envio de respostas ICMP ao seu plano de gerenciamento.
Contudo, se a perda surge no salto 3 e continua em 15% em todos os saltos subsequentes, você encontrou a interface exata com degradação ou congestionamento de trânsito.
Saturação de buffer local versus falha no fornecedor
Muitas quedas aparentes são geradas pelo fenômeno de bufferbloat: quando backups agendados ou sincronizações massivas preenchem 100% da banda, os pacotes que chegam são colocados em buffers profundos. O tempo de resposta salta de 10ms para 400ms, seguido por descarte em rajada. O usuário percebe a conexão caindo, mas a operadora vê o circuito operando na taxa máxima acordada.
Para empresas com operações críticas, um link dedicado corporativo com garantia integral de banda (CIR 100%) resolve o gargalo de trânsito externo, mas ainda requer políticas internas de marcação DSCP (Differentiated Services Code Point) para proteger tráfego de voz e ERP contra uploads descontrolados.
Quando a perda persistir após descartar saturação interna e falhas físicas, documente o teste MTR bidirecional (origem para destino e destino para origem) e os gráficos de tráfego. Essa postura técnica viabiliza o acompanhamento rigoroso do contrato, alinhando as medições às fórmulas expostas em nosso artigo sobre Cálculo de SLA e Glosas em Telecom: Guia Técnico para TI.
Como estruturar a evidência para acionamento direto do suporte
Ao abrir um protocolo já munido de evidências sólidas, o atendimento de nível 1 é ultrapassado rapidamente. Entregue um dossiê enxuto contendo:
- Relatório de MTR em modo texto com 100 pacotes disparados (incluindo IP de origem, destino e carimbo de data e hora).
- Evidência de que o consumo de banda na interface WAN durante o teste estava abaixo de 80% do throughput contratado.
- Status da interface óptica local demonstrando zeramento de contadores de erro físico (CRC e Input Drops).
Essa precisão transforma uma reclamação genérica em uma instrução técnica direta para a equipe de engenharia do provedor, reduzindo o MTTR (Mean Time to Repair, ou Tempo Médio de Reparo) de horas para minutos.
Perguntas frequentes
Qual é a porcentagem aceitável de perda de pacotes em conexões corporativas?
Em circuitos dedicados corporativos, a taxa aceitável de perda de pacotes deve ser inferior a 0,1% em trajetos nacionais. Valores acima de 1% já causam retransmissões severas em sessões TCP e distorções perceptíveis em aplicações de voz e vídeo em tempo real.
Qual a diferença técnica entre jitter e perda de pacotes?
Perda de pacotes ocorre quando datagramas são descartados e nunca chegam ao destino, enquanto jitter mede a variação no tempo de chegada sucessivo desses pacotes (latência variável). Jitter alto geralmente antecede a perda de pacotes quando os buffers de rede transbordam.
Por que o MTR mostra perda apenas em um salto intermediário e não no final?
Roteadores intermediários usam mecanismos de ICMP Rate Limiting para proteger suas CPUs contra ataques de negação de serviço. Se os saltos posteriores e o destino final exibem 0% de perda, a anomalia é um descarte de controle do nó local, e o tráfego de dados está fluindo normalmente.
Como identificar se a perda de pacotes ocorre no cordão óptico?
Verifique os contadores de erro na porta do roteador com comandos de diagnóstico da interface. Níveis crescentes de FCS (Frame Check Sequence) e erros de CRC indicam falha física no sinal luminoso, conector sujo ou atenuação excessiva na fibra óptica conectada ao switch.
A Lepitel Telecom entrega link dedicado com monitoramento contínuo de latência, jitter e perda de pacotes, garantindo transparência técnica total para a sua operação. Para desenhar uma topologia de conexão corporativa de alta confiabilidade para sua empresa, fale com nossa equipe de contato.
