Um switch que não se registra no controlador, e um switch que está online mas rejeita todo envio de configuração, são dois problemas diferentes com dois caminhos de diagnóstico diferentes — mas ambos geralmente terminam no mesmo comando. Esta nota decodifica as falhas reais de integração e os quatro erros de envio de configuração que respondem pela maioria dos chamados, além da comparação de banco de dados que resolve a maioria deles.
Por Yuwen Zhang (Atlas), fundador da AtlasCommTech — 13 anos de implantações de redes de operadoras e empresariais · Atualizado em julho de 2026
Um dispositivo que nunca se registra e um dispositivo que se registra e depois resiste a cada envio são problemas quase opostos, mesmo que ambos apareçam com o mesmo status vermelho no mesmo painel.
Integrar um switch a um controlador segue uma sequência bastante mecânica: alcançabilidade até o endereço sul do controlador, uma conexão TCP, uma negociação de algoritmo SSH sobre essa conexão, confiança de certificado, e então um hello NETCONF que finalmente registra o dispositivo. Uma vez que o dispositivo está registrado, um segundo modo de falha completamente diferente entra em ação — o controlador envia configuração, e a própria resposta do dispositivo diz não, por razões que quase sempre são uma incompatibilidade entre a configuração real do dispositivo e seu próprio registro interno dela.
O que segue está organizado da mesma forma que a nota complementar de SSH: pelo relato literal. O quarteto de integração — algoritmo SSH/chave de host, ESN, certificado, PnP+LLDP — o quarteto de envio de configuração — Service process failed, Unrecognized information, porta com outras configurações, Config is not permitted — além do único comando que resolve a maioria do segundo grupo, e cinco respostas de perguntas frequentes do campo.
As falhas de integração e as falhas de envio de configuração se dividem claramente — e a árvore indica qual metade desta nota realmente se aplica.
Um dispositivo travado em "nunca online" precisa do ramo esquerdo; um dispositivo claramente online mas rejeitando envios precisa do direito — há muito pouca sobreposição entre os dois.
Os rótulos do diagrama permanecem em inglês para clareza técnica.
Um comando restringe uma falha de integração, outro restringe uma falha de envio de configuração — use o certo antes de abrir qualquer caso específico abaixo.
<HUAWEI> system-view
[HUAWEI] diagnose
[HUAWEI-diagnose] display netconf register-fail-record
// maps directly onto the onboarding cases below
<HUAWEI> telnet -a 192.168.10.1 120.51.48.240 10020
Trying 120.51.48.240 ...
Connected to 120.51.48.240 ...
SSH-2.0---
// path and port are open -- if this fails instead, look upstream, not at SSH algorithms yet
[HUAWEI-diagnose] display netconf execution-fail-record
[HUAWEI-diagnose] copy netconf db-configuration
// pulls the device's own database to flash for a node-by-node diff against the live configO quarteto de integração, o quarteto de envio de configuração, e alguns casos em torno do PnP que aparecem constantemente ao lado de ambos.
SINTOMAO log de usuário registra Error code=7, Reason=Failed to create TCP link to controller. O log de diagnóstico mostra o sshd reportando Unable to negotiate with o endereço do controlador na porta 10020: no matching host key type found, listando os algoritmos que ofereceu.
CAUSAA própria conexão TCP funciona bem — a falha está uma camada acima, na negociação de algoritmo SSH entre o switch e a interface sul do controlador. Sem um algoritmo de chave de host correspondente, a sessão nunca se completa, então o NETCONF não tem nada sobre o que se construir e o dispositivo não consegue se registrar.
CORREÇÃONo controlador, vá em Sistema > Gerenciamento de segurança > Configuração de segurança > Verificação de configuração, procure as entradas Protocolo sul - Algoritmo de protocolo do cliente NETCONF e Protocolo sul - Algoritmo de protocolo do servidor SSH, e marque todas as opções de algoritmo de chave de host para que os dois lados sempre tenham uma em comum.
sshd[13032]: Unable to negotiate with 120.97.10.41 port 10020: no matching host key type found.
Their offer: x509v3-rsa2048-sha256,x509v3-ecdsa-sha2-nistp521,x509v3-ecdsa-sha2-nistp384,x509v3-ecdsa-sha2-nistp256
// on the controller: Configuration Check -> tick every host-key algorithm under both protocol-algorithm entriesSINTOMAdisplay netconf register-fail-record (ou o log de canal do controlador) reporta Error code=10, Reason=Controller ESN check failed, ou Device type and ESN does not match.
CAUSAO ESN inserido para este dispositivo — ou, para uma pilha, especificamente o ESN do mestre de empilhamento — no controlador não corresponde ao ESN real do dispositivo, ou a associação da pilha, números de slot e prioridades configurados no controlador não correspondem à pilha física.
CORREÇÃOCorrija primeiro o ESN no lado do controlador; para uma pilha, adicione cada membro físico ao grupo de dispositivos e certifique-se de que os números de slot e as prioridades correspondam exatamente — uma incompatibilidade aqui também pode disparar uma reinicialização indesejada em um membro de pilha que não é o mestre.
SINTOMANovamente Error code=7, Reason=Failed to create TCP link to controller, mas desta vez os logs CMREG/4/LINK_STATE_CHANGED mostram o link TCP conectando e desconectando repetidamente em vez de falhar de uma vez.
CAUSAO certificado local ou de CA do dispositivo está ausente ou inválido. Com muita frequência o próprio certificado está correto, mas o relógio do próprio dispositivo se desviou para fora da janela de validade, então toda tentativa de validação falha e o link nunca se estabiliza.
CORREÇÃOVerifique um certificado com display pki certificate local/ca realm default, valide-o com pki validate-certificate, e se for inválido puramente por causa do relógio, corrija a hora do dispositivo com clock datetime antes de mexer no próprio certificado.
[HUAWEI] display pki certificate local realm default
[HUAWEI] pki validate-certificate local realm default
// if invalid and the certificate itself looks fine, check display clock against the certificate's validity window first
[HUAWEI] clock datetime 10:00:00 2026-07-23SINTOMAUm switch novo com configuração vazia nunca sobe via PnP. O display pnp run-info no dispositivo downstream mostra Startup-vlan receive em branco, mesmo que a própria configuração PnP do dispositivo upstream pareça completa.
CAUSAAs informações do VLAN PnP viajam dentro de quadros LLDP. Se a porta física de downlink do dispositivo upstream tiver o LLDP desabilitado — undo lldp enable — nenhuma dessas informações chega ao novo dispositivo, não importa quão corretamente tudo o mais esteja configurado.
CORREÇÃOReabilite o LLDP na porta física upstream, depois confirme com display pnp run-info nos dois lados que o dispositivo downstream realmente está recebendo o VLAN.
[Huawei-XGigabitEthernet0/0/24] display this
#
interface XGigabitEthernet0/0/24
eth-trunk 10
undo lldp enable // this line blocks PnP VLAN delivery entirely
#
[Huawei-XGigabitEthernet0/0/24] lldp enableSINTOMAA porta física de uplink de um switch novo não consegue se auto-negociar no Eth-Trunk0. O debugging de diagnóstico mostra CMPNP_PROC NeighborFlag_Trunk, but is now trunk1 member.
CAUSAO PnP só constrói automaticamente o Eth-Trunk0 especificamente. Se a porta física já foi colocada manualmente em um Eth-Trunk diferente de zero antes do dispositivo subir, ela é estruturalmente incapaz de fazer parte do Eth-Trunk0 negociado dinamicamente.
CORREÇÃORemova a porta física de seu Eth-Trunk existente antes de conectá-la para a integração PnP — portas físicas que se juntam automaticamente ao Eth-Trunk0 só podem ter previamente trust dscp, port link-type trunk e description; qualquer outra coisa também bloqueia a auto-adesão.
SINTOMAA página de gerenciamento de interfaces do controlador mostra repetidamente um site sendo implantado sem gatilho óbvio, deixando quem está olhando o painel inquieto.
CAUSAA associação do Eth-Trunk é reportada pelo dispositivo, não definida pelo controlador. Uma única porta membro caindo e se reincorporando muda dinamicamente a associação Eth-Trunk reportada, e essa mudança é enviada como uma notificação, que o controlador exibe como uma implantação em andamento.
CORREÇÃONada a corrigir para uma oscilação pontual — confirme que ambas as pontas mostram a mesma contagem de membros Eth-Trunk assim que a porta estabilizar. Se isso se repetir constantemente, persiga a oscilação da camada física em si, não a exibição do controlador.
SINTOMAO envio de configuração falha com error-message Service process failed, e error-info aponta para um nó específico, por exemplo /ietf-interfaces:interfaces/interface[name="Vlanif4000"]/ietf-ip:ipv4.
CAUSAO próprio banco de dados de configuração do dispositivo ainda tem uma entrada — Vlanif4000, neste caso de campo — que foi removida da configuração real em execução, tipicamente por uma alteração manual via CLI, ou uma reinicialização que ocorreu antes de um save.
CORREÇÃOExporte o banco de dados real com copy netconf db-configuration, compare-o com a configuração ativa, recrie a parte ausente no dispositivo para corresponder ao banco de dados, depois tente novamente o envio a partir do controlador.
<rpc-error>
<error-message>Service process failed.</error-message>
<error-info>Error on node /ietf-interfaces:interfaces/interface[name="Vlanif4000"]/ietf-ip:ipv4</error-info>
</rpc-error>
CLOUD-MNG-CFG/7/ERROR: Failed to get ifnet by interface name(Interface Vlanif4000).
// device has no Vlanif4000, but the database does -- recreate it, then retry the pushSINTOMAO envio de configuração falha com error-message Unrecognized information, e o log de diagnóstico mostra CMNG: Failed to execute command in view [...], cmd [undo port trunk pvid vlan], err_msg [Unrecognized information.]
CAUSAAlguém mudou o link-type da porta diretamente na CLI — de trunk para access, no caso de campo por trás deste relato — enquanto o controlador ainda acredita, e envia com base, na configuração trunk anterior. Isso é um conflito de configuração multi-fonte direto.
CORREÇÃOCompare a configuração CLI ativa com o arquivo de banco de dados exportado nó a nó, traga a configuração real do dispositivo e o entendimento do controlador sobre ela de volta a uma única fonte de verdade, depois tente novamente o envio.
SINTOMAO envio de configuração falha com The port XGigabitEthernet0/0/1 has other configurations. Please clear configuration first. The error port is XGigabitEthernet0/0/1 — mesmo que nem a CLI nem o próprio banco de dados do dispositivo mostrem nada incomum nessa porta.
CAUSAUma configuração residual do lado do fabric no controlador faz com que um único envio tanto atribua a porta física a um Eth-Trunk quanto defina um port-link-type nessa mesma porta física no mesmo lote — duas operações que o dispositivo não aceita juntas em uma única solicitação.
CORREÇÃOLimpe a configuração residual do lado do fabric para essa interface no controlador, depois tente novamente o envio que falhou — o lado do dispositivo não tem nada a corrigir aqui.
SINTOMAO envio de configuração falha com error-message Config is not permitted, error-info apontando para um nó como /huawei-savi:savi/dhcp-snooping/snooping-global-enable/ipv4-enable.
CAUSAdhcp snooping enable depende de que o dhcp enable global já esteja presente. Um reset saved-configuration (ou um reset equivalente) apagou a configuração real do dispositivo enquanto o banco de dados ainda registrava dhcp enable como presente, deixando o envio seguinte do controlador sem uma dependência funcional à qual se anexar.
CORREÇÃOCompare o banco de dados com a configuração ativa, restaure manualmente a dependência ausente — dhcp enable, neste caso — no dispositivo, depois tente novamente o envio.
SINTOMAQualquer falha de envio de configuração que não se encaixe perfeitamente nas quatro categorias acima — incluindo um caso genuinamente estranho, em que a própria verificação de consistência de um controlador reportou incorretamente um ID de área OSPF de 255.255.255.255 porque seu valor decimal, 4294967295, transbordou um analisador de inteiro com sinal do lado do controlador.
CAUSAA grande maioria das falhas de envio de configuração no mundo real se resume à configuração ativa do dispositivo e seu próprio banco de dados interno discordando entre si — uma edição manual via CLI, uma reinicialização antes de salvar, ou ocasionalmente um bug de relato do próprio lado do controlador.
CORREÇÃOComece cada investigação de envio de configuração com copy netconf db-configuration para extrair o banco de dados do dispositivo para a flash, exportá-lo, e compará-lo nó a nó com a configuração ativa antes de presumir que outra coisa está errada.
[HUAWEI-diagnose] copy netconf db-configuration
// database file copied to the flash path -- diff running.xml against display current-configuration node by nodeTiradas diretamente do campo — as que vale a pena ter uma resposta pronta.
Há um tempo limite de heartbeat de 180 segundos — 15 segundos vezes 12 tentativas — enviado pelo switch ao controlador. Se o controlador não receber um dentro dessa janela, ou se 10 heartbeats consecutivos voltarem ausentes ou malformados, ele desconecta ativamente o dispositivo em vez de esperar indefinidamente.
display netconf connect-status. Para um dispositivo integrado via callhome, o campo Connected ao lado da entrada callhome deve mostrar Y. Para um dispositivo integrado via VLAN de gerenciamento, Controller IP address, Management VLAN, e tanto Register phase quanto Register status mostrando registered são o que confirma uma conexão saudável.
Upstream: pnp startup-vlan para definir o VLAN, pnp startup-vlan send enable para passá-lo downstream, e — se o downlink for um Eth-Trunk — também pnp startup-link-aggregation enable. Downstream: ou uma configuração genuinamente vazia no primeiro boot, ou NETCONF habilitado com management-vlan 1 configurado manualmente. De qualquer forma, a porta física de uplink só pode ter trust dscp, port link-type trunk e description antes de ser conectada — qualquer outra configuração também bloqueia a adesão automática ao Eth-Trunk0.
Da maior para a menor prioridade: callhome, redirecionamento, DHCP option 148, um endereço de controlador configurado diretamente na CLI, e por fim o método de centro de registro. Um dispositivo que parece estar se integrando "da forma errada" geralmente está apenas seguindo essa ordem em vez do método que você presumia estar ativo.
copy netconf db-configuration na visão de diagnóstico copia o arquivo de banco de dados de seu caminho oculto para o sistema de arquivos flash, de onde pode ser extraído e comparado nó a nó com display current-configuration — a etapa mais útil de longe em quase todas as falhas de envio de configuração desta nota.
Esta nota se baseia em switches Huawei série S se integrando ao iMaster NCE-Campus via NETCONF, e nos casos de campo por trás dos códigos de erro de register-fail-record e de envio de configuração que documenta. Os caminhos da interface do controlador (nomes de menu, localizações de caixas de seleção) podem variar ligeiramente entre versões de software do controlador. Não cobre em profundidade cenários de failover multi-controlador, nem pilhas de orquestração NETCONF de terceiros construídas sobre os mesmos modelos YANG.
Envie-nos a saída de display netconf register-fail-record, ou a error-message exata do envio que falhou, e ajudamos você a posicioná-lo no ramo certo.