A switch that won't register on the controller, and a switch that's online but rejects every config push, are two different problems with two different diagnostic paths — but both usually end at the same command. This note decodes the real onboarding failures and the four config-push errors that account for most tickets, plus the database comparison that resolves the majority of them.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
A device that never registers and a device that registers and then fights every push are almost opposite problems, even though both show up as the same red status on the same dashboard.
Onboarding a switch to a controller runs through a fairly mechanical sequence: reachability to the controller's southbound address, a TCP connection, SSH algorithm negotiation on top of that connection, certificate trust, then a NETCONF hello that finally registers the device. Once a device is registered, a second and completely different failure mode takes over — the controller pushes configuration, and the device's own reply says no, for reasons that are almost always a mismatch between the device's real configuration and the device's own internal record of it.
What follows is organized the same way this note's SSH companion is: by the literal report. The onboarding four — SSH/host-key algorithm, ESN, certificate, PnP+LLDP — the config-push four — Service process failed, Unrecognized information, port has other configurations, Config is not permitted — plus the one command that resolves most of the second group, and five FAQ answers from the field.
Onboarding faults and config-push faults split cleanly — and the tree tells you which half of this note actually applies.
A device stuck at "never online" needs the left branch; a device that's clearly online but rejecting pushes needs the right — there's very little overlap between the two.
Diagram labels are kept in English for engineering clarity.
One command narrows down an onboarding fault, one narrows down a config-push fault — reach for the right one before opening any specific case below.
<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 configThe onboarding four, the config-push four, and a handful of cases around PnP that come up constantly alongside both.
SYMPTOMUser log records Error code=7, Reason=Failed to create TCP link to controller. Diagnostic log shows sshd reporting Unable to negotiate with the controller's address on port 10020: no matching host key type found, listing the algorithms it offered.
CAUSETCP itself connects fine — the failure sits one layer up, in SSH algorithm negotiation between the switch and the controller's southbound interface. Without a matching host-key algorithm, the session never completes, so NETCONF has nothing to build on and the device can't register.
FIXOn the controller, go to System > Security Management > Security Configuration > Configuration Check, search for the Southbound Protocol - NETCONF Client Protocol Algorithm and Southbound Protocol - SSH Server Protocol Algorithm entries, and tick every host-key algorithm option so the two sides always have one in common.
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 entriesSYMPTOMdisplay netconf register-fail-record (or the controller's channel log) reports Error code=10, Reason=Controller ESN check failed, or Device type and ESN does not match.
CAUSEThe ESN entered for this device — or, for a stack, specifically the stacking master's ESN — on the controller doesn't match the device's real ESN, or the stack membership, slot numbers, and priorities configured on the controller don't match the physical stack.
FIXCorrect the ESN on the controller side first; for a stack, add every physical member to the device group and make sure slot numbers and priorities match exactly — a mismatch here can also trigger an unwanted reload on a non-master stack member.
SYMPTOMError code=7, Reason=Failed to create TCP link to controller again, but this time CMREG/4/LINK_STATE_CHANGED logs show the TCP link connecting and disconnecting repeatedly rather than failing outright once.
CAUSEThe device's local or CA certificate is missing or invalid. Very often the certificate itself is fine, but the device's own clock has drifted outside its validity window, so every validation attempt fails and the link never stabilizes.
FIXCheck for a certificate with display pki certificate local/ca realm default, validate it with pki validate-certificate, and if it's invalid purely because of the clock, correct the device time with clock datetime before touching the certificate itself.
[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-23SYMPTOMA new switch with empty configuration never comes up through PnP. display pnp run-info on the downstream device shows Startup-vlan receive blank, even though the upstream device's own PnP configuration looks complete.
CAUSEPnP VLAN information travels inside LLDP frames. If the upstream device's downlink physical port has LLDP disabled — undo lldp enable — none of that information ever reaches the new device, regardless of how correctly everything else is configured.
FIXRe-enable LLDP on the upstream physical port, then confirm with display pnp run-info on both sides that the downstream device is actually receiving the 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 enableSYMPTOMA new switch's uplink physical port can't auto-negotiate into Eth-Trunk0. Diagnostic debugging shows CMPNP_PROC NeighborFlag_Trunk, but is now trunk1 member.
CAUSEPnP only ever auto-builds Eth-Trunk0 specifically. If the physical port was already manually placed into a non-zero Eth-Trunk before the device came up, it's structurally unable to become part of the dynamically negotiated Eth-Trunk0.
FIXRemove the physical port from its existing Eth-Trunk before it's connected for PnP onboarding — physical ports auto-joining Eth-Trunk0 may only carry trust dscp, port link-type trunk, and description beforehand; anything else blocks the auto-join too.
SYMPTOMThe controller's interface management page repeatedly shows a site deploying with no obvious trigger, unsettling whoever's watching the dashboard.
CAUSEEth-Trunk membership is reported by the device, not set by the controller. A single member port going down and rejoining dynamically changes the reported Eth-Trunk membership, and that change gets pushed up as a notification, which the controller renders as an in-progress deployment.
FIXNothing to fix for a one-off flap — confirm both ends show the same Eth-Trunk member count once the port stabilizes. If it repeats constantly, chase the physical-layer flap itself rather than the controller's display.
SYMPTOMConfig push fails with error-message Service process failed, and error-info points at a specific node, for example /ietf-interfaces:interfaces/interface[name="Vlanif4000"]/ietf-ip:ipv4.
CAUSEThe device's own configuration database still has an entry — Vlanif4000, in this field case — that was removed from the actual running configuration, typically by a manual CLI change, or a reload that happened before a save.
FIXExport the actual database with copy netconf db-configuration, compare it against the live configuration, recreate the missing piece on the device to match the database, then retry the push from the controller.
<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 pushSYMPTOMConfig push fails with error-message Unrecognized information, and diagnostic log shows CMNG: Failed to execute command in view [...], cmd [undo port trunk pvid vlan], err_msg [Unrecognized information.]
CAUSESomeone changed the port's link-type directly on the CLI — trunk to access, in the field case behind this report — while the controller still believes, and pushes based on, the previous trunk configuration. That's a straightforward multi-source configuration conflict.
FIXCompare the live CLI configuration against the exported database file node by node, bring the device's actual configuration and the controller's understanding of it back to one source of truth, then retry the push.
SYMPTOMConfig push fails with The port XGigabitEthernet0/0/1 has other configurations. Please clear configuration first. The error port is XGigabitEthernet0/0/1 — even though neither the CLI nor the device's own database shows anything unusual on that port.
CAUSEResidual fabric-side configuration on the controller causes a single push to both assign the physical port into an Eth-Trunk and set a port-link-type on that same physical port in the same batch — two operations the device won't accept together in one request.
FIXClear the residual fabric-side configuration for that interface on the controller, then retry the failed push — the device side has nothing to fix here.
SYMPTOMConfig push fails with error-message Config is not permitted, error-info pointing at a node such as /huawei-savi:savi/dhcp-snooping/snooping-global-enable/ipv4-enable.
CAUSEdhcp snooping enable depends on global dhcp enable already being present. A reset saved-configuration (or an equivalent reset) wiped the device's actual configuration while the database still recorded dhcp enable as present, leaving the controller's follow-on push with no working dependency to attach to.
FIXCompare the database against the live configuration, manually restore the missing dependency — dhcp enable, in this case — on the device, then retry the push.
SYMPTOMAny config-push failure that doesn't fit neatly into the four categories above — including one genuinely strange case, where a controller's own consistency check misreported an OSPF area ID of 255.255.255.255 because its decimal value, 4294967295, overflowed a signed integer parser on the controller side.
CAUSEThe overwhelming majority of real-world config-push failures come down to the device's live configuration and its own internal database disagreeing with each other — a manual CLI edit, a reload before save, or occasionally a reporting bug on the controller's own side.
FIXStart every config-push investigation with copy netconf db-configuration to pull the device's database to flash, export it, and diff it node by node against the live configuration before assuming anything else is wrong.
[HUAWEI-diagnose] copy netconf db-configuration
// database file copied to the flash path -- diff running.xml against display current-configuration node by nodePulled straight from the field — the ones worth having an answer ready for.
There's a 180-second heartbeat timeout — 15 seconds times 12 tries — sent by the switch to the controller. If the controller doesn't receive one within that window, or 10 consecutive heartbeats come back missing or malformed, it actively disconnects the device rather than waiting indefinitely.
display netconf connect-status. For a device onboarded through callhome, the Connected field next to the callhome entry should read Y. For a device onboarded through a management VLAN, Controller IP address, Management VLAN, and both Register phase and Register status showing registered are what confirm a healthy connection.
Upstream: pnp startup-vlan to define the VLAN, pnp startup-vlan send enable to pass it downstream, and — if the downlink is an Eth-Trunk — pnp startup-link-aggregation enable as well. Downstream: either a genuinely empty configuration at first boot, or NETCONF enabled with management-vlan 1 configured manually. Either way, the physical uplink port can only carry trust dscp, port link-type trunk, and description before it's connected — any other configuration blocks the automatic Eth-Trunk0 join.
From highest to lowest priority: callhome, redirection, DHCP option 148, a controller address configured directly on the CLI, and finally the registration-center method. A device that seems to be onboarding "the wrong way" is usually just following this order rather than the method you assumed was active.
copy netconf db-configuration in diagnostic view copies the database file from its hidden path out to the flash filesystem, where it can be pulled off and diffed node by node against display current-configuration — the single most useful step across nearly every config-push failure in this note.
This note is built around Huawei S-series switches onboarding to iMaster NCE-Campus over NETCONF, and the field cases behind the register-fail-record and config-push error codes it documents. Controller UI paths (menu names, checkbox locations) can shift slightly between controller software versions. It doesn't cover multi-controller failover scenarios in depth, or third-party NETCONF orchestration stacks built against the same YANG models.
Send us the display netconf register-fail-record output, or the exact error-message from the failed push, and we'll help you place it in the right branch.