Como monitorar OLT: passo a passo para provedores

O que preparar antes de monitorar a OLT

Antes de instalar qualquer ferramenta, junte três coisas: a lista das OLTs com marca e firmware, a ordem de prioridade entre elas e o caminho de rede pelo qual o servidor de coleta vai chegar à gerência.

Quem pula essa etapa costuma descobrir no meio do caminho que metade das OLTs não responde ao servidor, que uma marca entrega o sinal das ONUs por um caminho diferente da outra ou que ninguém sabe qual OLT atende mais clientes.

A prioridade segue o número de assinantes atrás de cada equipamento. A OLT da cidade-sede, com milhares de ONUs, entra primeiro; a de um distrito com duzentos clientes entra depois, já com o modelo testado. Esse é o mesmo raciocínio do monitoramento de OLTs feito pela Táquion Tech, que começa pelo levantamento e só depois liga a coleta.

A planilha que vem antes da ferramenta

Uma linha por OLT basta, desde que tenha as colunas certas. Sem elas, cada passo seguinte vira pergunta para quem instalou o equipamento.

• Identificação: nome, cidade, POP e endereço IP de gerência de cada OLT.
• Hardware: marca, modelo, versão de firmware e número de placas e portas PON em uso.
• Carga: quantas ONUs ativas existem em cada porta e no total.
• Ligação: para qual switch ou concentrador sai cada uplink, e por qual porta.
• Responsável: quem pode autorizar mudança de configuração nessa OLT.

Por onde o servidor chega à gerência?

O servidor de coleta precisa alcançar a interface de gerência de cada OLT sem passar pela internet aberta. O caminho certo é uma VLAN ou uma rede de gerência separada, e não o IP público do equipamento.

Em redes com vários POPs, vale prever um coletor intermediário em cada um, que segue lendo a OLT quando o link até o servidor central cai. Assim a queda do transporte não apaga o histórico da OLT naquele período.

Como monitorar OLT: os nove passos

Os nove passos vão do acesso de leitura ao teste de falha, e cada um depende do anterior. Faça numa OLT de referência primeiro e só depois replique para as outras.

1. Criar o acesso de leitura: usuário SNMPv3 com autenticação e criptografia, sem permissão de escrita, e uma lista de acesso que só aceita o IP do servidor de coleta.
2. Testar a resposta de fora: do servidor, consultar a OLT com snmpwalk antes de cadastrar qualquer coisa na ferramenta.
3. Cadastrar o chassi: CPU, memória, temperatura, fontes, ventoinhas e estado de cada placa.
4. Descobrir as portas PON: estado da porta, ONUs ativas e tráfego por porta, por descoberta automática.
5. Ligar os uplinks: tráfego, erros e sinal óptico dos módulos entre a OLT e a agregação.
6. Coletar as ONUs: estado e sinal de cada ONU, com intervalo bem maior que o do chassi.
7. Carregar o mapa de portas: cada porta PON ligada às caixas e ao bairro que ela atende.
8. Criar alertas agrupados: um alerta por porta com a contagem de ONUs caídas, e dependência do uplink.
9. Provocar uma falha controlada: derrubar uma porta de teste ou um uplink redundante e anotar quando o aviso chegou.

O passo dois parece burocrático, mas resolve metade dos problemas antes que eles virem dúvida sobre a ferramenta. Se o snmpwalk do próprio servidor não responde, o erro está no acesso, na lista de acesso ou no caminho de rede, e nenhum modelo de coleta vai consertar isso.

Exemplo: testando a coleta antes de cadastrar a OLT

Os comandos abaixo usam o net-snmp, presente na maioria das distribuições Linux. Eles conferem as interfaces padrão e o inventário físico, que quase toda OLT entrega pelas MIBs públicas.

# 1. Nome e tempo ligado do equipamento (testa usuário, senha e lista de acesso)
snmpget -v3 -l authPriv -u coleta-ro -a SHA -A '<senha-auth>' -x AES -X '<senha-priv>' \
  192.0.2.20 SNMPv2-MIB::sysName.0 SNMPv2-MIB::sysUpTime.0

# 2. Estado das interfaces, incluindo portas PON e uplinks
snmpwalk -v3 -l authPriv -u coleta-ro -a SHA -A '<senha-auth>' -x AES -X '<senha-priv>' \
  192.0.2.20 IF-MIB::ifOperStatus

# 3. Descrição e contador de 64 bits de tráfego de entrada
snmpwalk -v3 -l authPriv -u coleta-ro -a SHA -A '<senha-auth>' -x AES -X '<senha-priv>' \
  192.0.2.20 IF-MIB::ifAlias
snmpwalk -v3 -l authPriv -u coleta-ro -a SHA -A '<senha-auth>' -x AES -X '<senha-priv>' \
  192.0.2.20 IF-MIB::ifHCInOctets

# 4. Placas, fontes e ventoinhas do chassi
snmpwalk -v3 -l authPriv -u coleta-ro -a SHA -A '<senha-auth>' -x AES -X '<senha-priv>' \
  192.0.2.20 ENTITY-MIB::entPhysicalDescr

# 5. Medir quanto tempo a OLT leva para responder uma tabela grande
time snmpwalk -v3 -l authPriv -u coleta-ro -a SHA -A '<senha-auth>' -x AES -X '<senha-priv>' \
  192.0.2.20 IF-MIB::ifTable > /dev/null

O sinal das ONUs e a temperatura costumam ficar em MIBs privadas de cada fabricante, com caminhos diferentes entre marcas e, às vezes, entre versões de firmware. O comando cinco mostra quanto a gerência sofre com uma tabela grande, e esse tempo ajuda a definir o intervalo da coleta das ONUs.

O que coletar em cada camada da OLT

Cada camada responde a uma pergunta diferente e muda em velocidade diferente, por isso tem intervalo próprio. A tabela serve de referência para o primeiro desenho da coleta.

A diferença de intervalo entre a porta e a ONU é o que permite saber de uma fibra rompida em poucos minutos sem pedir à gerência milhares de leituras por minuto. A queda em massa aparece na contagem da porta; o sinal de cada cliente pode esperar a próxima rodada.

Como monitorar OLT de várias marcas na mesma tela?

A saída é separar o que é comum do que é de cada fabricante. Estado de interface, tráfego e inventário vêm das MIBs públicas e funcionam igual em todas; sinal de ONU e temperatura pedem um modelo por marca.

Na prática, isso vira um modelo-base para todas as OLTs e um modelo complementar por fabricante, com os mesmos nomes de item. Assim o painel da OLT Huawei e o da ZTE mostram as mesmas colunas, e o operador não precisa decorar duas telas.

Quanto histórico guardar

Para chassi e portas, alguns meses de dado detalhado bastam para investigar uma queda. Para o sinal das ONUs, vale guardar pelo menos o valor do dia da ativação e uma média diária por um ano, porque a degradação lenta só aparece quando se compara com o passado. Os limites de alerta para esse sinal estão no guia sobre monitorar sinal das ONUs.

Alertas que avisam sem encher a tela

O alerta de OLT bem feito chega um por problema, com o tamanho do estrago e o lugar. Para isso ele depende do mapa de portas e da dependência entre o uplink e o que está atrás dele.

Uma fibra rompida antes do splitter derruba de uma vez todas as ONUs daquela árvore. Se cada ONU gera o seu aviso, o operador recebe dezenas de mensagens iguais e perde o que importa: qual porta, quantos clientes e que bairro. O guia sobre OLT derrubando ONU mostra como separar a queda física da queda causada por uma ONU com defeito.

Limites para começar

Comece com poucos alertas e todos acionáveis. Cada um precisa ter quem recebe e o que fazer quando dispara; os demais itens ficam só no gráfico até alguém provar que precisam acordar uma pessoa.

• Crítico: uplink fora, placa PON fora, porta com perda de muitas ONUs ao mesmo tempo, OLT sem resposta.
• Aviso: temperatura subindo, fonte redundante falhando, porta perto da ocupação máxima no pico.
• Só gráfico: CPU oscilando, ONU isolada caindo, sinal de cliente dentro da faixa.

Erros comuns ao monitorar uma OLT

Os erros mais caros não são de ferramenta, mas de desenho: coletar demais, alertar demais e nunca testar. Cada um deles transforma o monitoramento em mais uma tela que ninguém olha.

O último erro é o mais comum. Um monitoramento que nunca foi testado pode estar com o usuário bloqueado, a regra com o nome errado da porta ou o canal de aviso desligado, e tudo isso só aparece na primeira queda real. Quando a dúvida é se o defeito é da própria OLT, o roteiro de como saber se a OLT está com defeito ajuda a separar hardware de configuração.

Como saber se o monitoramento da OLT funciona?

Funciona quando um teste de falha controlada gera o aviso certo, no canal certo e antes de qualquer chamado. O checklist abaixo fecha a implantação de cada OLT.

Depois da implantação, reserve uma revisão mensal curta: alertas que dispararam sem ação, OLTs novas fora da coleta e portas que passaram a lotar no pico. Com alguns meses de histórico, dá para ir além do alerta e prever falhas, como mostra o guia de análise preditiva de falhas.

Na prática: o teste da porta de reserva

Um jeito seguro de testar é usar uma porta PON sem clientes, com uma ONU de bancada ligada a ela. Ao desligar a ONU, a porta perde a única ONU ativa e o alerta deve disparar na rodada seguinte.

Se a OLT não tem porta livre, o teste pode ser feito desligando um uplink redundante numa janela de manutenção. Nesse caso, o que se confere é se o alerta do uplink chega e se a dependência segura os avisos das portas.

Perguntas frequentes

Thiago Manoel

Responsável técnico da Táquion Tech · Registro profissional [PREENCHER]

Mais de 15 anos em operações de rede, com gestão de infraestruturas de TI, administração de data centers e condução de equipes em migrações de TI e telecomunicações, com foco em alta disponibilidade e segurança.

A Táquion Tech é uma empresa de engenharia de redes de Balneário Camboriú (SC) que projeta, opera e dá suporte a redes de provedores de internet e de empresas.

Conheça a equipe da Táquion Tech