Un commutateur qui ne s'enregistre pas auprès du contrôleur, et un commutateur en ligne mais qui rejette chaque déploiement de configuration, sont deux problèmes différents avec deux chemins de diagnostic différents — mais les deux aboutissent généralement à la même commande. Cette note décode les véritables échecs de mise en ligne et les quatre erreurs de déploiement de configuration qui expliquent la plupart des tickets, ainsi que la comparaison de base de données qui en résout la majorité.
Par Yuwen Zhang (Atlas), fondateur d'AtlasCommTech — 13 ans de déploiements de réseaux opérateurs et d'entreprise · Mis à jour en juillet 2026
Un équipement qui ne s'enregistre jamais et un équipement qui s'enregistre puis résiste à chaque déploiement sont des problèmes presque opposés, même si les deux apparaissent avec le même statut rouge sur le même tableau de bord.
L'intégration d'un commutateur à un contrôleur suit une séquence assez mécanique : joignabilité vers l'adresse sud du contrôleur, une connexion TCP, une négociation d'algorithme SSH par-dessus cette connexion, la confiance du certificat, puis un hello NETCONF qui finalise l'enregistrement de l'équipement. Une fois l'équipement enregistré, un second mode de défaillance totalement différent prend le relais — le contrôleur pousse une configuration, et la réponse de l'équipement dit non, pour des raisons qui sont presque toujours une incohérence entre la configuration réelle de l'équipement et l'enregistrement interne qu'il en a lui-même.
Ce qui suit est organisé de la même façon que la note compagnon sur SSH : selon le rapport littéral. Le quatuor de mise en ligne — algorithme SSH/clé d'hôte, ESN, certificat, PnP+LLDP — le quatuor de déploiement de configuration — Service process failed, Unrecognized information, port avec d'autres configurations, Config is not permitted — plus la seule commande qui résout la majorité du second groupe, et cinq réponses de FAQ tirées du terrain.
Les pannes de mise en ligne et les pannes de déploiement de configuration se distinguent nettement — et l'arbre indique quelle moitié de cette note s'applique réellement.
Un équipement bloqué à "jamais en ligne" a besoin de la branche de gauche ; un équipement clairement en ligne mais rejetant les déploiements a besoin de la branche de droite — il y a très peu de recoupement entre les deux.
Les légendes du schéma restent en anglais pour la clarté technique.
Une commande cerne une panne de mise en ligne, une autre cerne une panne de déploiement de configuration — utilisez la bonne avant d'ouvrir un cas spécifique ci-dessous.
<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 configLe quatuor de mise en ligne, le quatuor de déploiement de configuration, et une poignée de cas autour de PnP qui reviennent constamment aux côtés des deux.
SYMPTÔMELe journal utilisateur enregistre Error code=7, Reason=Failed to create TCP link to controller. Le journal de diagnostic montre sshd rapportant Unable to negotiate with l'adresse du contrôleur sur le port 10020: no matching host key type found, listant les algorithmes proposés.
CAUSELa connexion TCP elle-même se fait bien — la panne se situe une couche au-dessus, dans la négociation d'algorithme SSH entre le commutateur et l'interface sud du contrôleur. Sans algorithme de clé d'hôte correspondant, la session ne se termine jamais, donc NETCONF n'a rien sur quoi se construire et l'équipement ne peut pas s'enregistrer.
CORRECTIONSur le contrôleur, allez dans Système > Gestion de la sécurité > Configuration de sécurité > Vérification de configuration, recherchez les entrées Protocole sud - Algorithme de protocole client NETCONF et Protocole sud - Algorithme de protocole serveur SSH, et cochez chaque option d'algorithme de clé d'hôte pour que les deux côtés aient toujours un point commun.
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 entriesSYMPTÔMEdisplay netconf register-fail-record (ou le journal de canal du contrôleur) rapporte Error code=10, Reason=Controller ESN check failed, ou Device type and ESN does not match.
CAUSEL'ESN saisi pour cet équipement — ou, pour une pile, spécifiquement l'ESN du maître de pile — sur le contrôleur ne correspond pas à l'ESN réel de l'équipement, ou l'appartenance à la pile, les numéros de slot et les priorités configurés sur le contrôleur ne correspondent pas à la pile physique.
CORRECTIONCorrigez d'abord l'ESN côté contrôleur ; pour une pile, ajoutez chaque membre physique au groupe d'équipements et assurez-vous que les numéros de slot et les priorités correspondent exactement — une incompatibilité ici peut aussi déclencher un redémarrage indésirable sur un membre de pile non maître.
SYMPTÔMEEncore Error code=7, Reason=Failed to create TCP link to controller, mais cette fois les journaux CMREG/4/LINK_STATE_CHANGED montrent le lien TCP se connectant et se déconnectant à répétition plutôt qu'échouant carrément une fois.
CAUSELe certificat local ou CA de l'équipement est manquant ou invalide. Très souvent le certificat lui-même est correct, mais l'horloge propre de l'équipement a dérivé hors de sa fenêtre de validité, donc chaque tentative de validation échoue et le lien ne se stabilise jamais.
CORRECTIONVérifiez la présence d'un certificat avec display pki certificate local/ca realm default, validez-le avec pki validate-certificate, et si l'invalidité est purement due à l'horloge, corrigez l'heure de l'équipement avec clock datetime avant de toucher au certificat lui-même.
[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-23SYMPTÔMEUn nouveau commutateur avec configuration vide ne parvient jamais à monter via PnP. display pnp run-info sur l'équipement en aval montre Startup-vlan receive vide, même si la propre configuration PnP de l'équipement en amont semble complète.
CAUSELes informations de VLAN PnP voyagent dans des trames LLDP. Si le port physique de liaison descendante de l'équipement en amont a LLDP désactivé — undo lldp enable — aucune de ces informations n'atteint jamais le nouvel équipement, quelle que soit la justesse du reste de la configuration.
CORRECTIONRéactivez LLDP sur le port physique en amont, puis confirmez avec display pnp run-info des deux côtés que l'équipement en aval reçoit bien le 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 enableSYMPTÔMELe port physique de liaison montante d'un nouveau commutateur ne peut pas s'auto-négocier dans Eth-Trunk0. Le débogage diagnostic montre CMPNP_PROC NeighborFlag_Trunk, but is now trunk1 member.
CAUSEPnP ne construit automatiquement que spécifiquement Eth-Trunk0. Si le port physique a déjà été placé manuellement dans un Eth-Trunk non nul avant que l'équipement ne démarre, il est structurellement incapable de faire partie de l'Eth-Trunk0 négocié dynamiquement.
CORRECTIONRetirez le port physique de son Eth-Trunk existant avant de le connecter pour l'intégration PnP — les ports physiques rejoignant automatiquement Eth-Trunk0 ne peuvent porter au préalable que trust dscp, port link-type trunk et description ; toute autre configuration bloque aussi l'auto-adhésion.
SYMPTÔMELa page de gestion des interfaces du contrôleur affiche à répétition un site en cours de déploiement sans déclencheur évident, inquiétant quiconque surveille le tableau de bord.
CAUSEL'appartenance à l'Eth-Trunk est rapportée par l'équipement, pas définie par le contrôleur. Un seul port membre qui tombe et rejoint dynamiquement modifie l'appartenance Eth-Trunk rapportée, et ce changement est remonté comme une notification, que le contrôleur rend comme un déploiement en cours.
CORRECTIONRien à corriger pour une instabilité ponctuelle — confirmez que les deux extrémités affichent le même nombre de membres Eth-Trunk une fois le port stabilisé. Si cela se répète constamment, traquez l'instabilité de couche physique elle-même plutôt que l'affichage du contrôleur.
SYMPTÔMELe déploiement de configuration échoue avec error-message Service process failed, et error-info pointe vers un nœud spécifique, par exemple /ietf-interfaces:interfaces/interface[name="Vlanif4000"]/ietf-ip:ipv4.
CAUSELa base de données de configuration propre de l'équipement contient encore une entrée — Vlanif4000, dans ce cas de terrain — qui a été retirée de la configuration réelle en cours d'exécution, typiquement par un changement CLI manuel, ou un redémarrage survenu avant une sauvegarde.
CORRECTIONExportez la base de données réelle avec copy netconf db-configuration, comparez-la à la configuration en direct, recréez la partie manquante sur l'équipement pour correspondre à la base de données, puis relancez le déploiement depuis le contrôleur.
<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 pushSYMPTÔMELe déploiement de configuration échoue avec error-message Unrecognized information, et le journal de diagnostic montre CMNG: Failed to execute command in view [...], cmd [undo port trunk pvid vlan], err_msg [Unrecognized information.]
CAUSEQuelqu'un a changé le link-type du port directement sur la CLI — de trunk à access, dans le cas de terrain derrière ce rapport — alors que le contrôleur croit encore, et déploie sur la base de, la configuration trunk précédente. C'est un conflit de configuration multi-source pur et simple.
CORRECTIONComparez la configuration CLI en direct au fichier de base de données exporté nœud par nœud, ramenez la configuration réelle de l'équipement et la compréhension qu'en a le contrôleur à une seule source de vérité, puis relancez le déploiement.
SYMPTÔMELe déploiement de configuration échoue avec The port XGigabitEthernet0/0/1 has other configurations. Please clear configuration first. The error port is XGigabitEthernet0/0/1 — même si ni la CLI ni la base de données propre de l'équipement ne montrent quoi que ce soit d'inhabituel sur ce port.
CAUSEUne configuration résiduelle côté fabric sur le contrôleur fait qu'un seul déploiement à la fois assigne le port physique dans un Eth-Trunk et définit un port-link-type sur ce même port physique dans le même lot — deux opérations que l'équipement n'accepte pas ensemble dans une seule requête.
CORRECTIONEffacez la configuration résiduelle côté fabric pour cette interface sur le contrôleur, puis relancez le déploiement en échec — le côté équipement n'a rien à corriger ici.
SYMPTÔMELe déploiement de configuration échoue avec error-message Config is not permitted, error-info pointant vers un nœud tel que /huawei-savi:savi/dhcp-snooping/snooping-global-enable/ipv4-enable.
CAUSEdhcp snooping enable dépend de la présence préalable de dhcp enable global. Un reset saved-configuration (ou une réinitialisation équivalente) a effacé la configuration réelle de l'équipement tandis que la base de données enregistrait toujours dhcp enable comme présent, laissant le déploiement suivant du contrôleur sans dépendance fonctionnelle à laquelle s'attacher.
CORRECTIONComparez la base de données à la configuration en direct, restaurez manuellement la dépendance manquante — dhcp enable, dans ce cas — sur l'équipement, puis relancez le déploiement.
SYMPTÔMEToute panne de déploiement de configuration qui ne rentre pas proprement dans les quatre catégories ci-dessus — y compris un cas vraiment étrange, où la propre vérification de cohérence d'un contrôleur a mal rapporté un ID de zone OSPF de 255.255.255.255 parce que sa valeur décimale, 4294967295, a débordé un analyseur d'entier signé côté contrôleur.
CAUSEL'immense majorité des pannes de déploiement de configuration en conditions réelles se ramène à un désaccord entre la configuration en direct de l'équipement et sa propre base de données interne — une modification CLI manuelle, un redémarrage avant sauvegarde, ou parfois un bug de rapport côté contrôleur.
CORRECTIONCommencez chaque investigation de déploiement de configuration par copy netconf db-configuration pour extraire la base de données de l'équipement vers la flash, l'exporter, et la comparer nœud par nœud à la configuration en direct avant de supposer autre chose de cassé.
[HUAWEI-diagnose] copy netconf db-configuration
// database file copied to the flash path -- diff running.xml against display current-configuration node by nodeTirées directement du terrain — celles pour lesquelles il vaut la peine d'avoir une réponse prête.
Il existe un délai d'expiration de battement de cœur de 180 secondes — 15 secondes fois 12 tentatives — envoyé par le commutateur au contrôleur. Si le contrôleur n'en reçoit pas dans cette fenêtre, ou si 10 battements consécutifs reviennent manquants ou mal formés, il déconnecte activement l'équipement plutôt que d'attendre indéfiniment.
display netconf connect-status. Pour un équipement intégré via callhome, le champ Connected à côté de l'entrée callhome doit afficher Y. Pour un équipement intégré via un VLAN de gestion, Controller IP address, Management VLAN, et à la fois Register phase et Register status affichant registered confirment une connexion saine.
En amont : pnp startup-vlan pour définir le VLAN, pnp startup-vlan send enable pour le transmettre en aval, et — si la liaison descendante est un Eth-Trunk — pnp startup-link-aggregation enable également. En aval : soit une configuration réellement vide au premier démarrage, soit NETCONF activé avec management-vlan 1 configuré manuellement. Dans les deux cas, le port physique de liaison montante ne peut porter que trust dscp, port link-type trunk et description avant sa connexion — toute autre configuration bloque aussi l'adhésion automatique à Eth-Trunk0.
De la priorité la plus haute à la plus basse : callhome, redirection, DHCP option 148, une adresse de contrôleur configurée directement sur la CLI, et enfin la méthode de centre d'enregistrement. Un équipement qui semble s'intégrer "de la mauvaise façon" suit généralement simplement cet ordre plutôt que la méthode que vous pensiez active.
copy netconf db-configuration en vue diagnostic copie le fichier de base de données de son chemin caché vers le système de fichiers flash, où il peut être extrait et comparé nœud par nœud à display current-configuration — l'étape la plus utile de loin pour presque toutes les pannes de déploiement de configuration de cette note.
Cette note s'appuie sur des commutateurs Huawei série S s'intégrant à iMaster NCE-Campus via NETCONF, et sur les cas de terrain derrière les codes d'erreur register-fail-record et de déploiement de configuration qu'elle documente. Les chemins d'interface du contrôleur (noms de menus, emplacements de cases à cocher) peuvent varier légèrement selon les versions logicielles du contrôleur. Elle ne couvre pas en profondeur les scénarios de basculement multi-contrôleurs, ni les piles d'orchestration NETCONF tierces construites sur les mêmes modèles YANG.
Envoyez-nous la sortie de display netconf register-fail-record, ou l'error-message exact du déploiement en échec, et nous vous aiderons à le placer dans la bonne branche.