NETCONF em OLT Huawei: ativar, ler e escrever sem virar refém do SSH

Se você trabalha com OLT Huawei no dia a dia, SSH ainda é o caminho mais comum: entra, sobe de privilégio, manda comando e torce para ninguém estar ocupando o VTY. Funciona. O problema começa quando a gente tenta automatizar isso: paginação (--More--), prompt que muda, saída em texto puro e aquele VTY Busy clássico.

NETCONF não é mágica e não substitui o SSH da noite para o dia. É outro jeito de falar com a caixa: em vez de digitar comando de CLI e ler a tela, você manda um pedido em XML (chamado RPC) e a OLT responde com XML. Deu certo? Volta <ok/>. Deu errado? Volta <rpc-error> com tag e mensagem. Os dados seguem modelos YANG. Pense nisso como um “contrato” do que existe na caixa (hostname, interfaces, hardware…), parecido com a ideia de OID no SNMP, só que em árvore XML.

Importante: muita documentação Huawei de NETCONF é de switch CloudEngine / NE. OLT é outra família. O comando que circular por aí (snetconf server enable) não é o que liga NETCONF na OLT. No lab em MA5800, o caminho foi outro; mostro abaixo.

Em qual OLT isso vale

Eu testei em equipamento da linha MA5800, onde o serviço NETCONF existe. Em outras OLTs Huawei mais novas o fluxo costuma ser parecido; o limiar é o netconf aparecer no sysman service.

Em várias MA5600T / MA5680T mais antigas, ao digitar sysman service ? o netconf não lista. Nessas caixas o resto deste post não se aplica: não é falta de senha, é a imagem/produto mesmo.

Como checar rápido na sua OLT: entre no SSH de sempre, enable, config, e rode sysman service ?. Se netconf aparecer na ajuda, você está no caminho. Se não aparecer, para por aqui.

Ligando o NETCONF na OLT

Ainda na CLI (SSH normal):

enable
config
sysman service ?
sysman service netconf enable
  User Name(length<6,15>): <user_netconf>
  User Password(length<12,128>): ********
  Confirm Password(length<12,128>): ********
sysman service netconf port 830

O enable pede um usuário novo só para NETCONF (6 a 15 caracteres). Se você tentar reaproveitar o user do SSH (o de sempre), a OLT costuma recusar com “This user has existed”. Senha com 12+ caracteres, e maiúscula/minúscula importa de verdade.

A operação demora uns segundos (“Please wait…”). Porta: a CLI aceita algo entre 22 e 830; no lab deixei 830, que é o porto clássico de NETCONF.

Só configurar netconf idle-timeout não liga o serviço: precisa do sysman service netconf enable.

Se você erra a senha várias vezes seguidas, a OLT pode colocar o IP do NMS em sysman ip-refuse. Sintoma estranho: a porta TCP abre, mas a autenticação quebra. Vale olhar display sysman ip-refuse e limpar o IP se for o caso. Depois, save se a rede exigir config persistente.

O que é uma “sessão” NETCONF (e por que não é o SSH de VTY)

Você ainda usa SSH por baixo, mas não abre um canal de CLI. O cliente pede o subsystem netconf na porta que você configurou. Na prática: host + porta 830 + user/senha do NETCONF.

Na primeira troca, os dois lados mandam um hello: a OLT lista o que ela “sabe fazer” (capabilities). No lab vieram mais de 270 entradas: IETF, BBF (XPON) e Huawei. É a partir daí que você descobre, por exemplo, que existe módulo de interfaces, de hardware, de sistema, etc.

Um detalhe chato de lab: com cliente em NETCONF 1.1 (ncclient no default, por exemplo), o hello às vezes sobe e o get não volta. Com 1.0 e o delimitador ]]>]]> no fim de cada mensagem, estabilizou. Se estiver nessa situação, teste 1.0 antes de achar que a OLT “não responde”.

Outra coisa que medi nesta imagem: com uma sessão aberta, a segunda sessão em paralelo falhou na autenticação. Fechar e abrir de novo, em sequência, funcionou. Para automação, pense em uma conexão reutilizada mandando vários RPCs, não em abrir dez connects juntos.

A lógica do RPC (para quem nunca mexeu)

Todo pedido segue o mesmo envelope. O que muda é o miolo: a operação.

<?xml version="1.0" encoding="UTF-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
  <!-- aqui entra get, edit-config, etc. -->
</rpc>
]]>]]>

• get: “me devolve o estado/config que bater com este filtro”
• edit-config: “aplica esta mudança no datastore” (no lab, no running)
• filter type="subtree": você não baixa a OLT inteira; aponta a árvore (ex.: só hostname, só uma interface)

O xmlns="..." não é enfeite: é o namespace do módulo YANG. Sem o namespace certo, a caixa não entende o XML. Por isso os exemplos abaixo repetem esses URNs.

Ordem que eu uso no lab: (1) provar que a sessão fala, (2) ler uma ONT conhecida, (3) só então escrever algo inofensivo.

1) Primeiro RPC: “a sessão está viva?”: hostname

No SSH você faria algo como display sysname / olhar o prompt. Em NETCONF, o módulo padrão da IETF para isso é o ietf-system. Pedir só o hostname é o smoke test: leve, fácil de ler na resposta, e se falhar o problema é connect/auth/framing, não o modelo da ONT.

<get>
  <filter type="subtree">
    <system xmlns="urn:ietf:params:xml:ns:yang:ietf-system">
      <hostname/>
    </system>
  </filter>
</get>

Na resposta você procura uma tag <hostname>...</hostname> dentro de <data>. Se vier <rpc-error>, leia error-tag e error-message: é bem mais limpo que caçar “Failure:” no meio de um More.

2) Como a ONT aparece no YANG (o “F/S/P/ONT” que você já conhece)

Na CLI Huawei você pensa em 0/1/0 e ont-id 0. No modelo BBF/Huawei que a OLT expõe via NETCONF, isso vira nome de interface:

• v-ani.0.1.0.0: lado de configuração da ONT (virtual ANI): alias, serial esperado, profiles…
• ani.0.1.0.0: lado de estado (ANI operacional): online/offline, serial real, distância, temperatura…

A regra do nome: v-ani.<frame>.<slot>.<porta>.<ontid> (e o mesmo para ani). Se no CLI a ONU é frame 0, slot 1, porta 0, ont 5 → v-ani.0.1.0.5 / ani.0.1.0.5.

Por que dois nomes? No YANG moderno (e no BBF), config e estado muitas vezes ficam separados. No NETCONF da OLT isso aparece como dois “objetos” de interface. Mentalmente: v-ani = o que está provisionado · ani = o que a OLT está enxergando agora.

3) Ler config da ONT: alias e serial esperado

Equivalente grosseiro ao que você olha em display ont info no pedaço de descrição / SN de autenticação. Aqui o filtro aponta para ietf-interfaces e o nome v-ani...:

<get>
  <filter type="subtree">
    <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
      <interface>
        <name>v-ani.0.1.0.0</name>
      </interface>
    </interfaces>
  </filter>
</get>

Na XML de volta, procure:

• description: o alias / descrição da ONU
• enabled
• expected-serial-number: SN que a OLT espera na autenticação (formato tipo vendor+serial, ex. HWTC...)

Se <data> vier vazio, ou o nome está errado (F/S/P/ONT), ou aquela ONU não existe nesse índice.

4) Ler estado da ONT: online, SN real, distância…

Aqui o datastore de estado usa o container interfaces-state (repare: não é o mesmo que interfaces) e o nome ani...:

<get>
  <filter type="subtree">
    <interfaces-state xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
      <interface>
        <name>ani.0.1.0.0</name>
      </interface>
    </interfaces-state>
  </filter>
</get>

No lab, dentro do bloco da interface (augment Huawei), apareceram coisas como:

• run-state: se está up / etc.
• actual-serial-number: SN que a ONU de fato apresentou
• distância (metros), tempo online, último motivo de queda
• temperatura, CPU, descrição de produto / versão

Ou seja: se o seu objetivo é “essa ONU está online e qual o SN real?”, o caminho é ani + interfaces-state, não o v-ani.

5) E a óptica? (porta da OLT × potência da ONU)

Aqui é fácil se perder.

Óptica do SFP da porta PON na OLT (o módulo físico plugado no slot/porta) mora em ietf-hardware, componente com nome transceiver.<frame>.<slot>.<porta>: exemplo transceiver.0.1.0. Lá você vê coisas de módulo: TX da porta, thresholds, vendor do SFP… Isso não é o Rx de cada ONU.

<get>
  <filter type="subtree">
    <hardware xmlns="urn:ietf:params:xml:ns:yang:ietf-hardware">
      <component>
        <name>transceiver.0.1.0</name>
      </component>
    </hardware>
  </filter>
</get>

Óptica por ONU (Rx/Tx daquele cliente) é o que a gente costuma ver no display ont optical-info. No hello da OLT existem módulos de PM/transceiver de ONT, mas no lab o get nesses containers voltou <data/> vazio. Parece dado de telemetria/KPI, não o mesmo tipo de leitura “na hora” do datastore. Resumo sincero: status e alias via NETCONF ok; Rx da ONU eu ainda não tirei limpo por esse caminho nessa imagem: SNMP/CLI continuam no radar para isso.

Dica prática: nunca faça get de ietf-interfaces ou ietf-hardware sem filtrar por name. No lab isso cuspiu megabytes. Sempre aponte o objeto.

6) Escrita: mudar o alias com edit-config

Leitura usa get. Escrita usa edit-config: você manda o pedaço de config que quer gravar. No lab a capability writable-running estava ativa, então o alvo foi o running.

Exemplo didático (só em ONU de teste): alterar a description do v-ani: o mesmo campo de alias que você leu acima.

<edit-config>
  <target><running/></target>
  <config>
    <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
      <interface>
        <name>v-ani.0.1.0.1</name>
        <description>cliente_lab_01</description>
      </interface>
    </interfaces>
  </config>
</edit-config>

Sucesso típico: resposta só com <ok/>. Depois você pode dar de novo o get do v-ani e conferir a description. Provisionar, deletar ou rebootar ONT via YANG é outro nível, não misture com o primeiro contato.

Resumo do fluxo

1) Na CLI, veja se sysman service ? tem netconf → enable + user novo + porta.
2) Conecte no subsystem NETCONF (lab estável em 1.0).
3) get do hostname → sessão ok.
4) Monte o nome v-ani.F.S.P.O / ani.F.S.P.O a partir do F/S/P/ONT que você já usa no SSH.
5) Config e alias no v-ani; estado no ani; SFP da porta no transceiver.F.S.P.
6) Escrita leve com edit-config só em lab.

NETCONF, nessa linha, deixa leitura/escrita estruturada bem mais confortável que scrap de tela. SSH não some, ainda é o caminho quando a caixa é antiga, quando o YANG não expõe o que você precisa, ou quando você só quer um display rápido na mão.