PPPoE caindo em horário de pico: como achar a causa de verdade

O padrão é sempre parecido. Entre 19h e 22h começam as reclamações de queda rápida, o cliente reinicia a ONT, volta a funcionar, e no dia seguinte o gráfico do link mostra tudo normal. O suporte troca a ONT, troca o cabo, e o problema reaparece na semana seguinte em outro cliente.

Quando o sintoma tem horário, a causa está na sua rede, não no equipamento do assinante. Esta é a ordem em que vale procurar.

1. CPU do concentrador, medida por core

É o primeiro lugar, e o mais frequentemente mal medido. Muita gente olha a CPU média e vê 40%, conclui que está tranquilo e vai procurar em outro lugar.

O problema é que encerramento de PPPoE, criptografia e encaminhamento raramente distribuem carga de forma uniforme. Um core em 100% enquanto os outros sete estão em 20% dá uma média confortável e uma rede que descarta pacote.

O que medir:

• CPU por core, não a média.
• Interrupções por segundo, que indicam pressão no plano de dados.
• Sessões ativas comparadas ao número que o fabricante realmente sustenta, não ao número da folha de dados.
• Fila de descarte nas interfaces de entrada e saída.

Um concentrador no limite não cai: ele passa a responder devagar. E PPPoE responde a lentidão derrubando sessão.

2. Tempo de resposta do RADIUS

Toda sessão que sobe consulta o RADIUS. Se o servidor demora além do timeout configurado, o cliente não autentica, tenta de novo, e você tem um efeito de avalanche: quanto mais gente tenta reconectar, mais lento fica o RADIUS, e mais gente cai.

Dois números importam aqui:

• Latência média de autenticação. Acima de 200 ms já merece atenção; acima de 1 s é problema.
• Latência de accounting. Frequentemente ignorada, e é ela que sobrecarrega o banco quando o ERP grava cada atualização de forma síncrona.

Em operação com ERP integrado, o gargalo raramente é o RADIUS em si: é o banco de dados por trás dele. Um índice faltando na tabela de sessões consegue derrubar um provedor inteiro no horário de pico.

3. CGNAT sem porta disponível

Esse é o mais traiçoeiro, porque não derruba a sessão PPPoE. Ele quebra serviços de forma seletiva, e o cliente descreve como “a internet cai”.

Se o pool de portas por assinante está apertado, um celular com muitos aplicativos abertos esgota a alocação sozinho. O resultado é jogo que desconecta, videoconferência que congela e VPN que não fecha, enquanto navegação e vídeo continuam funcionando.

O que conferir: portas alocadas por assinante, taxa de reutilização e se o log exigido pelo Marco Civil está sendo gravado sem travar o encaminhamento. Se o número de portas por assinante estiver abaixo de algumas centenas, esse é o seu problema.

A saída estrutural é IPv6. Com IPv6 nativo funcionando, boa parte do tráfego moderno sai do CGNAT e o esgotamento deixa de existir.

4. Queue e burst mal dimensionados

Quando o controle de banda é feito por queue tree ou HTB, o custo de processamento cresce com o número de sessões. Uma configuração que funciona com 800 clientes pode consumir CPU demais com 2000.

Além disso, burst mal configurado gera um efeito colateral desagradável: o cliente mede velocidade acima do plano nos primeiros segundos e depois cai bruscamente, o que gera reclamação mesmo com a rede entregando o contratado.

5. A rede de acesso, por último

Só depois de descartar os quatro itens acima vale olhar a planta óptica. E, mesmo aqui, o sintoma com horário aponta para causa específica: variação térmica em caixa exposta ao sol, que desalinha conector ao longo do dia, ou PON com potência no limite que degrada quando todos os equipamentos estão ligados.

O teste é comparar a potência óptica das ONTs da mesma PON em dois momentos do dia. Se a diferença for grande, o problema é físico.

O erro de método que mais custa caro

Investigar tudo isso às 10h da manhã. Com a rede vazia, todos os indicadores parecem saudáveis, e a conclusão é sempre “está tudo normal”.

O diagnóstico precisa acontecer durante a janela do problema, com coleta ativa: captura de pacote no concentrador, medição de latência do RADIUS e contadores de interface amostrados a cada poucos segundos. Uma hora de dado bom no horário certo vale mais que uma semana de gráfico agregado.

Se o seu monitoramento não guarda essa granularidade, o primeiro passo não é achar a causa: é conseguir enxergá-la. É o que a implantação de monitoramento resolve, e o que a frente de PPPoE e autenticação ataca quando o concentrador já está no limite.

Para o caso em que o sintoma não tem hora marcada e ninguém consegue reproduzir, o caminho é outro: suporte nível 3, com captura de pacote e laudo com evidência.