No universo das telecomunicações, a pressa é a maior inimiga da perfeição. Na correria do dia a dia de um provedor de internet (ISP), pequenas desatenções podem causar problemas devastadores e difíceis de rastrear. Hoje, quero compartilhar com vocês um dos casos mais intrigantes que enfrentamos: uma falha física simples, mas que assombrou a nossa infraestrutura por semanas.
Tudo começou com reclamações pontuais de intermitência na velocidade vindas de apenas três clientes. Enviamos um técnico ao local, que realizou todos os testes padrão e não identificou nenhuma anormalidade. Mesmo assim, para garantir, ele substituiu toda a infraestrutura física dos assinantes: trocou a queda de fibra desde a caixa de atendimento (CTO) até o modem, refez a crimpagem dos cabos de rede que ligavam a ONU ao roteador e substituiu os conectores dos nós da rede Mesh.
Tudo ficou novo, com sinais ópticos perfeitos e testes de velocidade batendo o teto do plano. Naquele momento, o problema parecia resolvido.
O Mistério Continuava: Roteamento BGP e o Comando Torch
Nos dias seguintes, os mesmos clientes voltaram a reclamar de oscilações. Logo depois, um novo assinante entrou em contato relatando perdas de pacotes e travamentos em jogos online.
Subimos o nível da análise. Começamos investigando o coração da rede: checamos as rotas do protocolo BGP no roteador de borda em busca de alguma falha de trânsito ou instabilidade de rotas, mas estava tudo limpo. Instalamos uma RouterBoard da MikroTik na casa do cliente e utilizamos a ferramenta torch para monitorar o fluxo de pacotes em tempo real, mas também não havia registros de erros aparentes ali.
Se o BGP estava normal, o MikroTik não acusava erros no cliente e a fibra do assinante era nova, onde estava a falha?
A Descoberta: Uma Atenuação Oculta de 8 dB no Datacenter
Decidimos auditar a comunicação interna do nosso Datacenter, especificamente o enlace entre o roteador de borda e o switch de agregação. Foi aí que o problema começou a aparecer.
Identificamos uma atenuação de mais de 8 dB em uma das interfaces SFP+ de 10 Gbps. Essa interface fazia parte de um grupo de agregação de portas (Link Aggregation) composto por 4 portas de 10 Gbps, totalizando um throughput de 40 Gbps de interconexão técnica. Como o consumo do provedor na época era baixo (cerca de 3 Gbps), teoricamente tínhamos 37 Gbps de sobra de banda. Além disso, contávamos com uma segunda interface de 40 Gbps ligada direto ao nosso fornecedor de trânsito.
Por haver tanta sobra de banda na agregação, o tráfego fluía, mas os pacotes que caíam especificamente na porta atenuada sofriam degradação.
O Erro Físico
Ao inspecionarmos visualmente o rack do Datacenter, encontramos a causa: haviam conectado um cordão óptico monomodo (SM) em um módulo SFP multimodo (MM).
Essa incompatibilidade de diâmetro de núcleo da fibra gerava uma perda de inserção massiva (os 8 dB de atenuação), gerando erros de transmissão e descartes invisíveis de pacotes.
[Módulo SFP Multimodo] <--- CORDÃO ERRADO (Monomodo) ---> [Módulo SFP Multimodo]
(Gera perda de 8 dB)
Solução e Aprendizado Prático
Mantivemos os mesmos módulos SFP e apenas substituímos o cordão óptico pelo modelo multimodo correto. Após a troca, as reclamações de intermitência zeraram imediatamente.
Ao puxarmos o histórico do PRTG, vimos que o monitoramento já vinha acusando uma perda de pacotes mínima há dias. No entanto, como o protocolo ICMP (ping) é naturalmente descartado pelos roteadores em momentos de priorização de tráfego, nós havíamos ignorado o alerta por achar que era um comportamento aceitável.
Esse episódio nos ensinou que, em redes de alta performance, uma perda de pacotes muito inferior a 0,00001% causa, sim, problemas perceptíveis para o usuário final, principalmente em aplicações de tempo real como jogos e chamadas de voz.
A partir desse dia, adotamos o monitoramento de ping rigoroso como prioridade absoluta e realizamos um check-up completo em todos os cordões e interfaces de fibra do nosso Datacenter para garantir que nenhuma outra SFP estivesse operando com o cabo trocado.
