Troubleshooting Datacom gpon

Causas: ONU com defeito de hardware transmitindo fora de janela,Mau contato óptico em uma ONU específica do ramo,Condição climática afetando a última milha de uma ONU

Diagnóstico: Técnica oficial de isolamento (Anti-Rogue): em vez de deslocar técnico a cada cliente do ramo (até 128 ONUs por pon-link), isole ONUs individualmente e teste por eliminação. Isole metade das ONUs suspeitas, confirme se o problema cessou; se sim, a ofensora está no grupo isolado — libere uma a uma até o problema reaparecer. Comandos: DM4615# config DM4615(config)# interface gpon 1/1/1 DM4615(config-gpon-1/1/1)# anti-rogue onu-isolate 1 DM4615(config-gpon-1/1/1)# anti-rogue onu-isolate 2 DM4615(config-gpon-1/1/1)# commit Verificar isolamento ativo: DM4615(config-gpon-1/1/1)# do show running-config interface gpon 1/1/1

Solução: A última ONU liberada antes do problema voltar é a defeituosa. Após identificado e corrigido o defeito físico, sempre remover o isolamento com "no anti-rogue onu-isolate <n>" — ele não é temporário automaticamente. Documentar qual ONU foi isolada e por quanto tempo.

Causas: Emenda mal feita, conector sujo ou dobrado,Splitter fora de especificação,Fibra com micro-curvatura,Projeto subdimensionado (splitter demais, distância demais)

Diagnóstico: Metodologia oficial de orçamento de potência (Power Budget): OP (orçamento) = Ptx mínimo do módulo óptico – Srx (sensibilidade de recepção da ONU) MP (margem) = OP – LL (soma de todas as perdas do enlace) Link só é viável se MP > 0. Exemplo oficial (laser C+, OLT DM4615, ONU DM984-100B, enlace 15km, splitters 1/2 + 1/16): Ptx mín. C+: 4 dBm · Srx da ONU: -30 dBm → OP = 34 dB Perdas: fibra 15km (3,75dB) + splitter 1/2 (3,7dB) + splitter 1/16 (13,7dB) + 8 emendas (0,8dB) + 4 conectores (2dB) + margem de segurança (3dB) = LL = 26,95 dB MP = 34 - 26,95 = 7,05 dB → link viável

Solução: Se a leitura real de potência estiver muito pior que o cálculo, o problema é físico (verificar emenda, conector, splitter, curvatura) — não adianta mexer em configuração da OLT. Se a leitura bate com o cálculo mas está fora da faixa de operação do laser, o projeto está subdimensionado e precisa de redesenho. A maioria dos chamados de "ONU instável" tem causa em infraestrutura óptica mal planejada, não em configuração ou defeito de hardware.

Causas: Variação de implementação OMCI (ITU-T G.988) entre fabricantes, mesmo com conformidade GPON (ITU-T G.984)

Diagnóstico: ONU registra na OLT (nível óptico/GPON ok) mas não autentica PPPoE, tanto em bridge quanto router — problema conhecido de mercado, não específico de uma marca. Relato de campo em fórum público (não é posição oficial Datacom).

Solução: Consultar guia de compatibilidade ONU×OLT específico antes de comprar em volume; testar amostra pequena antes de padronizar; considerar que a Datacom garante interoperabilidade apenas dentro de sua própria linha (ONUs DM98x).

Causas: Falha de energia na casa do cliente/ONU,ONU desligada manualmente,Fonte da ONU com defeito

Diagnóstico: Alarme GPON_DGi (trap gPonDGiAlarm), severidade Critical. A ONU avisa a OLT que perdeu a alimentação AC (ou está abaixo do limite mínimo) no último instante antes de desligar — não é degradação gradual de sinal, é queda abrupta. Diferencial: se várias ONUs da mesma região derem dying gasp ao mesmo tempo, é queda de energia elétrica na área (concessionária), não defeito de equipamento — não é chamado de suporte técnico, é operacional.

Solução: Verificar se a ONU está desligada ou foi resetada — não é problema de fibra/óptica, é energia. Se o cliente confirma energia normal e o alarme persiste, suspeitar de fonte da ONU com defeito.

Causas: Fibra ou cabeamento mal conectado,Configuração física incorreta (ex: dois pontos da rede ligados um ao outro por engano),Switch de cliente com uplink duplicado sem STP

Diagnóstico: Alarme LOOPBACK_DETECTED (trap loopbackDetectedAlarmTrap), severidade Major, gerado pelo protocolo LBD (Loopback Detection) do DmOS. A porta onde o loop foi detectado para de encaminhar tráfego automaticamente até parar de receber o tráfego de controle do loop, pelo tempo configurado. Comando: loopback-detection interface <porta> timer <tempo> Nota: o documento oficial não detalha STP/RSTP tradicional neste guia — só o LBD, mecanismo próprio da Datacom. Se a rede usa STP/RSTP como proteção primária, a config está no Guia de Configuração Rápida, não neste documento. Relacionado — EAPS (anel Metro Ethernet): alarme correspondente é EAPS_RING_FAILED (Major) — domínio EAPS em estado de falha, geralmente por falha de link no anel ou VLAN de controle mal configurada.

Solução: Inspecionar conexões físicas e configurações nos dispositivos de rede — é sempre problema de topologia física/lógica, não tem correção só por CLI além de identificar e desconectar o loop.

Causas: Native-vlan configurado errado na porta (cliente untagged cai na VLAN errada), Interface não é membro untagged da VLAN antes de virar native-vlan dela, Aprendizado de MAC desabilitado manualmente na porta (learning disabled), Limite de MAC por porta ou VLAN atingido (limit maximum 0 = descarta tudo), Aging-time reduzido demais, entradas expiram rápido e parecem "não aprender"

Diagnóstico: show vlan brief show vlan membership detail show mac-address-table show mac-address-table interface gigabit-ethernet-1/1/1 show mac-address-table vlan 100 "membership detail" mostra PORT STATE (Forwarding/Blocked/Learning/Disabled) por VLAN×porta — se uma porta que deveria estar forwarding aparece blocked, o problema pode ser STP/ERPS/EAPS bloqueando ali, não a config de VLAN em si. Regra oficial de limite de MAC: quando limite de porta E de VLAN estão configurados ao mesmo tempo, vale o mais restritivo.

Solução: Pra native-vlan errada: confirmar que a interface é membro untagged da VLAN antes de configurar native-vlan (dot1q vlan X → interface → untagged, só depois switchport ... native-vlan vlan-id X). Pra MAC não aprendendo: checar e reverter learning disabled, remover limite restritivo (no mac-address-table interface X limit maximum), ou aumentar aging-time se estiver curto demais.

Artigo editado.

10/07/2026 · Thiago Gomes Rodrigues

Artigo editado.

09/07/2026 · Thiago Gomes Rodrigues

Artigo criado.

08/07/2026 · Thiago Gomes Rodrigues