Un switch que no se registra en el controlador, y un switch que está en línea pero rechaza cada envío de configuración, son dos problemas distintos con dos rutas de diagnóstico distintas — pero ambos suelen terminar en el mismo comando. Esta nota decodifica las fallas reales de incorporación y los cuatro errores de envío de configuración que explican la mayoría de los casos, además de la comparación de base de datos que resuelve la mayoría de ellos.
Por Yuwen Zhang (Atlas), fundador de AtlasCommTech — 13 años de despliegues de redes de operadores y empresariales · Actualizado en julio de 2026
Un dispositivo que nunca se registra y un dispositivo que se registra y luego se resiste a cada envío son problemas casi opuestos, aunque ambos aparezcan con el mismo estado rojo en el mismo panel.
Incorporar un switch a un controlador sigue una secuencia bastante mecánica: alcanzabilidad hacia la dirección sur del controlador, una conexión TCP, una negociación de algoritmo SSH sobre esa conexión, confianza de certificado, y luego un hello NETCONF que finalmente registra el dispositivo. Una vez que el dispositivo está registrado, entra en juego un segundo modo de falla completamente distinto — el controlador envía configuración, y la propia respuesta del dispositivo dice que no, por razones que casi siempre son una discrepancia entre la configuración real del dispositivo y su propio registro interno de ella.
Lo que sigue está organizado igual que la nota complementaria de SSH: por el reporte literal. El cuarteto de incorporación — algoritmo SSH/clave de host, ESN, certificado, PnP+LLDP — el cuarteto de envío de configuración — Service process failed, Unrecognized information, puerto con otras configuraciones, Config is not permitted — más el único comando que resuelve la mayoría del segundo grupo, y cinco respuestas de preguntas frecuentes del campo.
Las fallas de incorporación y las fallas de envío de configuración se dividen claramente — y el árbol indica qué mitad de esta nota aplica realmente.
Un dispositivo atascado en "nunca en línea" necesita la rama izquierda; un dispositivo claramente en línea pero que rechaza los envíos necesita la derecha — hay muy poco solapamiento entre ambas.
Las etiquetas del diagrama se mantienen en inglés por claridad técnica.
Un comando acota una falla de incorporación, otro acota una falla de envío de configuración — use el correcto antes de abrir cualquier caso específico a continuación.
<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 configEl cuarteto de incorporación, el cuarteto de envío de configuración, y algunos casos alrededor de PnP que aparecen constantemente junto a ambos.
SÍNTOMAEl registro de usuario anota Error code=7, Reason=Failed to create TCP link to controller. El registro de diagnóstico muestra sshd reportando Unable to negotiate with la dirección del controlador en el puerto 10020: no matching host key type found, listando los algoritmos que ofreció.
CAUSALa propia conexión TCP funciona bien — la falla está una capa por encima, en la negociación de algoritmo SSH entre el switch y la interfaz sur del controlador. Sin un algoritmo de clave de host coincidente, la sesión nunca se completa, por lo que NETCONF no tiene nada sobre lo cual construirse y el dispositivo no puede registrarse.
SOLUCIÓNEn el controlador, vaya a Sistema > Gestión de seguridad > Configuración de seguridad > Verificación de configuración, busque las entradas Protocolo sur - Algoritmo de protocolo de cliente NETCONF y Protocolo sur - Algoritmo de protocolo de servidor SSH, y marque todas las opciones de algoritmo de clave de host para que ambos lados siempre tengan uno en común.
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 entriesSÍNTOMAdisplay netconf register-fail-record (o el registro de canal del controlador) reporta Error code=10, Reason=Controller ESN check failed, o Device type and ESN does not match.
CAUSAEl ESN ingresado para este dispositivo — o, para un stack, específicamente el ESN del maestro de apilamiento — en el controlador no coincide con el ESN real del dispositivo, o la membresía del stack, los números de slot y las prioridades configuradas en el controlador no coinciden con el stack físico.
SOLUCIÓNCorrija primero el ESN en el lado del controlador; para un stack, agregue cada miembro físico al grupo de dispositivos y asegúrese de que los números de slot y las prioridades coincidan exactamente — una discrepancia aquí también puede provocar un reinicio no deseado en un miembro del stack que no es maestro.
SÍNTOMADe nuevo Error code=7, Reason=Failed to create TCP link to controller, pero esta vez los registros CMREG/4/LINK_STATE_CHANGED muestran el enlace TCP conectándose y desconectándose repetidamente en lugar de fallar de una vez por todas.
CAUSAEl certificado local o de CA del dispositivo falta o es inválido. Con mucha frecuencia el certificado en sí está bien, pero el reloj propio del dispositivo se ha desviado fuera de su ventana de validez, por lo que cada intento de validación falla y el enlace nunca se estabiliza.
SOLUCIÓNVerifique un certificado con display pki certificate local/ca realm default, valídelo con pki validate-certificate, y si es inválido puramente por el reloj, corrija la hora del dispositivo con clock datetime antes de tocar el certificado en sí.
[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-23SÍNTOMAUn switch nuevo con configuración vacía nunca sube mediante PnP. display pnp run-info en el dispositivo downstream muestra Startup-vlan receive en blanco, aunque la propia configuración PnP del dispositivo upstream parece completa.
CAUSALa información del VLAN PnP viaja dentro de tramas LLDP. Si el puerto físico de enlace descendente del dispositivo upstream tiene LLDP deshabilitado — undo lldp enable — ninguna de esa información llega jamás al nuevo dispositivo, sin importar cuán correctamente esté configurado todo lo demás.
SOLUCIÓNVuelva a habilitar LLDP en el puerto físico upstream, luego confirme con display pnp run-info en ambos lados que el dispositivo downstream realmente está recibiendo el 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 enableSÍNTOMAEl puerto físico de enlace ascendente de un switch nuevo no puede auto-negociarse en Eth-Trunk0. El debugging de diagnóstico muestra CMPNP_PROC NeighborFlag_Trunk, but is now trunk1 member.
CAUSAPnP solo construye automáticamente Eth-Trunk0 específicamente. Si el puerto físico ya fue colocado manualmente en un Eth-Trunk distinto de cero antes de que el dispositivo subiera, estructuralmente no puede formar parte del Eth-Trunk0 negociado dinámicamente.
SOLUCIÓNRetire el puerto físico de su Eth-Trunk existente antes de conectarlo para la incorporación PnP — los puertos físicos que se unen automáticamente a Eth-Trunk0 solo pueden llevar de antemano trust dscp, port link-type trunk y description; cualquier otra cosa también bloquea la auto-unión.
SÍNTOMALa página de gestión de interfaces del controlador muestra repetidamente un sitio implementándose sin un disparador evidente, inquietando a quien esté observando el panel.
CAUSALa membresía del Eth-Trunk la reporta el dispositivo, no la establece el controlador. Un solo puerto miembro que cae y se reincorpora cambia dinámicamente la membresía Eth-Trunk reportada, y ese cambio se envía como una notificación, que el controlador muestra como una implementación en curso.
SOLUCIÓNNada que corregir para una inestabilidad puntual — confirme que ambos extremos muestran el mismo conteo de miembros Eth-Trunk una vez que el puerto se estabiliza. Si se repite constantemente, persiga la inestabilidad de capa física en sí, no la pantalla del controlador.
SÍNTOMAEl envío de configuración falla con error-message Service process failed, y error-info apunta a un nodo específico, por ejemplo /ietf-interfaces:interfaces/interface[name="Vlanif4000"]/ietf-ip:ipv4.
CAUSALa propia base de datos de configuración del dispositivo todavía tiene una entrada — Vlanif4000, en este caso de campo — que fue eliminada de la configuración real en ejecución, típicamente por un cambio manual de CLI, o un reinicio ocurrido antes de un guardado.
SOLUCIÓNExporte la base de datos real con copy netconf db-configuration, compárela con la configuración en vivo, recree la parte faltante en el dispositivo para que coincida con la base de datos, luego reintente el envío desde el 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 pushSÍNTOMAEl envío de configuración falla con error-message Unrecognized information, y el registro de diagnóstico muestra CMNG: Failed to execute command in view [...], cmd [undo port trunk pvid vlan], err_msg [Unrecognized information.]
CAUSAAlguien cambió el link-type del puerto directamente en la CLI — de trunk a access, en el caso de campo detrás de este reporte — mientras el controlador todavía cree, y envía basándose en, la configuración trunk anterior. Eso es un conflicto de configuración multi-fuente sencillo.
SOLUCIÓNCompare la configuración CLI en vivo con el archivo de base de datos exportado nodo por nodo, haga que la configuración real del dispositivo y el entendimiento del controlador sobre ella vuelvan a una sola fuente de verdad, luego reintente el envío.
SÍNTOMAEl envío de configuración falla con The port XGigabitEthernet0/0/1 has other configurations. Please clear configuration first. The error port is XGigabitEthernet0/0/1 — aunque ni la CLI ni la propia base de datos del dispositivo muestran nada inusual en ese puerto.
CAUSAUna configuración residual del lado del fabric en el controlador hace que un solo envío tanto asigne el puerto físico a un Eth-Trunk como establezca un port-link-type en ese mismo puerto físico en el mismo lote — dos operaciones que el dispositivo no acepta juntas en una sola solicitud.
SOLUCIÓNElimine la configuración residual del lado del fabric para esa interfaz en el controlador, luego reintente el envío fallido — el lado del dispositivo no tiene nada que corregir aquí.
SÍNTOMAEl envío de configuración falla con error-message Config is not permitted, error-info apuntando a un nodo como /huawei-savi:savi/dhcp-snooping/snooping-global-enable/ipv4-enable.
CAUSAdhcp snooping enable depende de que global dhcp enable ya esté presente. Un reset saved-configuration (o un reinicio equivalente) borró la configuración real del dispositivo mientras la base de datos seguía registrando dhcp enable como presente, dejando el envío posterior del controlador sin una dependencia funcional a la cual adjuntarse.
SOLUCIÓNCompare la base de datos con la configuración en vivo, restaure manualmente la dependencia faltante — dhcp enable, en este caso — en el dispositivo, luego reintente el envío.
SÍNTOMACualquier falla de envío de configuración que no encaje claramente en las cuatro categorías anteriores — incluyendo un caso genuinamente extraño, donde la propia verificación de consistencia de un controlador reportó erróneamente un ID de área OSPF de 255.255.255.255 porque su valor decimal, 4294967295, desbordó un analizador de entero con signo del lado del controlador.
CAUSALa abrumadora mayoría de las fallas de envío de configuración en el mundo real se reducen a que la configuración en vivo del dispositivo y su propia base de datos interna no coinciden entre sí — una edición manual de CLI, un reinicio antes de guardar, u ocasionalmente un error de reporte del propio lado del controlador.
SOLUCIÓNComience cada investigación de envío de configuración con copy netconf db-configuration para extraer la base de datos del dispositivo a la flash, exportarla, y compararla nodo por nodo con la configuración en vivo antes de asumir que algo más está mal.
[HUAWEI-diagnose] copy netconf db-configuration
// database file copied to the flash path -- diff running.xml against display current-configuration node by nodeSacadas directamente del campo — las que vale la pena tener respuesta lista.
Hay un tiempo de espera de latido de 180 segundos — 15 segundos por 12 intentos — enviado por el switch al controlador. Si el controlador no recibe uno dentro de esa ventana, o si 10 latidos consecutivos vuelven faltantes o mal formados, desconecta activamente el dispositivo en lugar de esperar indefinidamente.
display netconf connect-status. Para un dispositivo incorporado mediante callhome, el campo Connected junto a la entrada callhome debe mostrar Y. Para un dispositivo incorporado mediante un VLAN de gestión, Controller IP address, Management VLAN, y tanto Register phase como Register status mostrando registered son lo que confirma una conexión saludable.
Upstream: pnp startup-vlan para definir el VLAN, pnp startup-vlan send enable para pasarlo downstream, y — si el enlace descendente es un Eth-Trunk — también pnp startup-link-aggregation enable. Downstream: ya sea una configuración genuinamente vacía en el primer arranque, o NETCONF habilitado con management-vlan 1 configurado manualmente. De cualquier forma, el puerto físico de enlace ascendente solo puede llevar trust dscp, port link-type trunk y description antes de conectarse — cualquier otra configuración también bloquea la unión automática a Eth-Trunk0.
De mayor a menor prioridad: callhome, redirección, DHCP option 148, una dirección de controlador configurada directamente en la CLI, y finalmente el método de centro de registro. Un dispositivo que parece incorporarse "de la forma equivocada" generalmente solo está siguiendo este orden en lugar del método que usted asumía activo.
copy netconf db-configuration en vista de diagnóstico copia el archivo de base de datos desde su ruta oculta al sistema de archivos flash, donde puede extraerse y compararse nodo por nodo contra display current-configuration — el paso más útil, con diferencia, en casi todas las fallas de envío de configuración de esta nota.
Esta nota se basa en switches Huawei serie S incorporándose a iMaster NCE-Campus mediante NETCONF, y en los casos de campo detrás de los códigos de error de register-fail-record y de envío de configuración que documenta. Las rutas de la interfaz del controlador (nombres de menú, ubicaciones de casillas) pueden variar ligeramente entre versiones de software del controlador. No cubre en profundidad escenarios de conmutación por error multi-controlador, ni pilas de orquestación NETCONF de terceros construidas sobre los mismos modelos YANG.
Envíenos la salida de display netconf register-fail-record, o el error-message exacto del envío fallido, y le ayudaremos a ubicarlo en la rama correcta.