# PPPoE - Diagnóstico de Desconexões por Keepalive Timeout ## Objetivo Orientar o diagnóstico de clientes que apresentam desconexões frequentes da sessão PPPoE, mesmo sem perda aparente de sinal óptico, reinicialização do concentrador ou indisponibilidade geral do serviço. O objetivo deste documento é ajudar a identificar em qual ponto do caminho entre o cliente e o concentrador PPPoE ocorre a interrupção de comunicação. --- ## Entendendo o Keepalive PPPoE Após o estabelecimento de uma sessão PPPoE, o cliente e o concentrador permanecem trocando mensagens periódicas de controle. Essas mensagens permitem verificar se a comunicação lógica entre as duas extremidades continua ativa. Quando o concentrador deixa de receber resposta dentro do tempo esperado, considera que a sessão foi interrompida e realiza a desconexão. Em ambientes MikroTik, isso normalmente aparece nos logs por mensagens semelhantes a: ```text terminating... - peer is not responding ``` ```text LCP missed too many echo requests ``` ```text disconnected ``` Em seguida, o cliente pode autenticar novamente poucos segundos depois. --- ## O que o log realmente significa Uma desconexão por Keepalive Timeout não significa, por si só, que o servidor PPPoE esteja com defeito. Ela indica apenas que o concentrador deixou de receber resposta do cliente durante determinado período. Essa interrupção pode ocorrer em qualquer ponto do caminho: ```text Cliente │ Roteador ou CPE │ Cabo Ethernet │ ONU │ Rede óptica │ OLT │ Rede de transporte │ Concentrador PPPoE ``` O diagnóstico deve localizar em qual ponto ocorreu a perda de comunicação. --- ## Primeira análise Antes de iniciar testes, é necessário identificar o alcance do problema. Verificar: - Apenas um cliente apresenta a falha? - Alguns clientes apresentam a falha? - Todos os clientes apresentam a falha? - Os clientes afetados pertencem à mesma OLT? - Estão na mesma PON? - Utilizam o mesmo splitter? - Passam pela mesma VLAN? - Utilizam o mesmo enlace de transporte? - Estão no mesmo concentrador PPPoE? - As desconexões ocorrem no mesmo horário? - As reconexões são simultâneas ou aleatórias? Essas respostas ajudam a determinar se a causa está no cliente, na rede de acesso, na rede de transporte ou no concentrador. --- ## Cenário 1 - Apenas um cliente Quando somente um cliente apresenta desconexões, a investigação deve começar no acesso individual. Possíveis causas: - reinicialização do roteador; - reinicialização da ONU; - fonte de alimentação instável; - defeito no roteador; - defeito na ONU; - cabo Ethernet danificado; - conector RJ45 oxidado ou mal crimpado; - porta Ethernet instável; - potência óptica próxima ao limite; - perda momentânea de comunicação entre ONU e roteador; - travamento ou sobrecarga do equipamento do cliente. Verificar: - uptime da ONU; - uptime do roteador; - histórico de registro da ONU; - histórico de reinicialização; - níveis ópticos de RX e TX; - erros na porta Ethernet da ONU; - negociação de velocidade e duplex; - qualidade da fonte de alimentação; - estado do cabeamento entre ONU e roteador. Uma ONU pode permanecer registrada na OLT e, ainda assim, perder momentaneamente a comunicação Ethernet com o roteador. --- ## Cenário 2 - Alguns clientes Quando apenas alguns clientes apresentam a falha, deve-se procurar um ponto em comum entre eles. Verificar se os clientes afetados compartilham: - a mesma OLT; - a mesma PON; - o mesmo splitter; - a mesma caixa de atendimento; - o mesmo enlace; - a mesma VLAN; - o mesmo switch; - o mesmo rádio; - o mesmo caminho até o concentrador. Possíveis causas: - instabilidade em uma PON; - falha em splitter ou caixa óptica; - perda de pacotes em enlace compartilhado; - interface com erros CRC; - porta de switch instável; - loop de camada 2; - flapping de interface; - VLAN com problema; - saturação de enlace; - enlace rádio instável; - falha intermediária entre OLT e concentrador. A correlação geográfica e lógica entre os clientes afetados é fundamental para localizar o ponto comum. --- ## Cenário 3 - Todos os clientes de um concentrador Quando todos os clientes de um concentrador desconectam aproximadamente no mesmo horário, verificar: - reinicialização do concentrador; - CPU elevada; - falta de memória; - travamento do serviço PPPoE; - perda de comunicação com as OLTs; - falha no enlace principal; - falha de energia; - interface de uplink instável; - loop de camada 2; - alteração de rota; - indisponibilidade de VLAN; - saturação do equipamento; - falha em switch ou roteador intermediário. Nesse cenário, a causa tende a estar na infraestrutura compartilhada e não nas ONUs individuais. --- ## Verificações na ONU Mesmo quando não existe LOS ou perda de registro, verificar: - potência óptica recebida; - potência óptica transmitida; - quantidade de desregistros; - tempo online; - histórico de reinicialização; - erros FEC; - erros Ethernet; - velocidade negociada; - duplex; - flapping da interface Ethernet; - temperatura do equipamento; - qualidade da alimentação. A ausência de LOS não comprova que a comunicação Ethernet ou lógica permaneceu estável. --- ## Verificações na OLT Na OLT, verificar: - histórico de registro e desregistro da ONU; - eventos de dying gasp; - alarmes da PON; - erros FEC; - perda de pacotes; - utilização da PON; - erros de uplink; - flapping de interfaces; - VLAN associada ao cliente; - alterações de configuração; - eventos ocorridos no mesmo horário das desconexões. Também é importante comparar os horários registrados na OLT com os horários do log PPPoE. --- ## Verificações no concentrador PPPoE No concentrador, verificar: - uso de CPU; - uso de memória; - quantidade de sessões ativas; - consumo de recursos; - interface de entrada das conexões PPPoE; - erros de interface; - perda de pacotes; - saturação; - filas; - logs de reinicialização; - flapping de interfaces; - mensagens de LCP; - horários exatos das desconexões. Quando possível, verificar se os clientes afetados entram pela mesma interface, VLAN ou bridge. --- ## Verificações na rede de transporte Entre a OLT e o concentrador, verificar: - perda de pacotes; - aumento de latência; - jitter; - erros CRC; - drops; - interfaces saturadas; - velocidade negociada incorretamente; - duplex incompatível; - flapping; - loops; - STP; - RSTP; - VLAN incorreta; - trunks inconsistentes; - enlaces rádio instáveis; - mudanças de rota; - indisponibilidade momentânea de equipamentos intermediários. A sessão PPPoE depende da continuidade da comunicação de camada 2 entre o cliente e o concentrador. --- ## Possíveis causas Uma perda de Keepalive pode ser causada por: - reinicialização do equipamento do cliente; - fonte de alimentação instável; - defeito no roteador; - defeito na ONU; - defeito na porta Ethernet; - cabo Ethernet danificado; - conector mal crimpado ou oxidado; - potência óptica próxima ao limite; - ONU instável; - OLT apresentando perda momentânea; - erro em VLAN; - interface com CRC; - loop de camada 2; - flapping de interface; - saturação de CPU; - saturação de memória; - saturação de enlace; - perda de comunicação entre OLT e concentrador; - switch intermediário instável; - enlace rádio instável; - falha de energia; - alteração de rota; - problema físico na rede. A mensagem de Keepalive Timeout não identifica qual dessas causas ocorreu. A causa raiz só pode ser determinada pela correlação entre sintomas, horários e evidências coletadas. --- ## Evidências a coletar Antes de concluir o diagnóstico, registrar: - login PPPoE; - nome do cliente; - horário exato das desconexões; - quantidade de reconexões; - concentrador PPPoE; - interface ou VLAN utilizada; - OLT; - PON; - ONU; - splitter ou caixa de atendimento; - níveis ópticos de RX e TX; - uptime da ONU; - uptime do roteador; - histórico de registro da ONU; - eventos de dying gasp; - log do concentrador; - log da OLT; - CPU do concentrador; - memória do concentrador; - erros de interface; - perda de pacotes; - latência entre OLT e concentrador; - equipamentos intermediários no caminho. Essas informações permitem identificar padrões e correlacionar ocorrências entre clientes distintos. --- ## Fluxo recomendado de diagnóstico 1. Confirmar a quantidade de clientes afetados. 2. Identificar se existe ponto comum entre eles. 3. Registrar o horário exato das desconexões. 4. Verificar o log do concentrador PPPoE. 5. Confirmar se a ONU permaneceu registrada. 6. Verificar o uptime da ONU. 7. Verificar o uptime do roteador. 8. Conferir níveis ópticos de RX e TX. 9. Verificar erros Ethernet na ONU. 10. Verificar eventos na OLT. 11. Verificar perda de pacotes entre OLT e concentrador. 12. Verificar interfaces, VLANs e enlaces compartilhados. 13. Conferir CPU e memória do concentrador. 14. Correlacionar todos os horários. 15. Somente após essa análise definir a causa provável. --- ## Erros comuns no diagnóstico Evitar conclusões imediatas como: - “é problema do servidor PPPoE”; - “é problema da OLT”; - “é sinal óptico”; - “é o roteador do cliente”; - “é problema de energia”. A mensagem de Keepalive apenas informa que houve perda temporária de comunicação. Ela não identifica automaticamente onde ocorreu a falha. --- ## Exemplo de interpretação ### Situação Um cliente apresenta várias reconexões PPPoE durante o dia. A ONU permanece registrada e o nível óptico está dentro do esperado. ### Interpretação correta O sinal óptico adequado e a ausência de LOS não descartam: - reinicialização do roteador; - falha no cabo Ethernet; - instabilidade na porta LAN da ONU; - perda momentânea na VLAN; - falha no transporte até o concentrador. O próximo passo é verificar uptime, erros Ethernet, horários e pontos compartilhados. --- ## Conclusão Desconexões por Keepalive Timeout representam perda temporária de comunicação entre o cliente e o concentrador PPPoE. Essa perda pode ocorrer no equipamento do cliente, na ONU, na OLT, na rede óptica, na rede de transporte ou no próprio concentrador. O diagnóstico deve ser baseado em evidências e correlação de eventos. A análise isolada do log PPPoE não é suficiente para determinar a causa raiz.