A camera that shows up as an unknown device, a phone that never gets a category at all, a fingerprint that used to work and suddenly stops — terminal identification on a campus switch runs on three separate mechanisms, and each one fails in its own way. This is the order that finds which one is actually broken, the exact diagnose-view commands to run, and the five reasons that account for most of these tickets.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
The three mechanisms don't share a single failure mode — which is exactly why treating "terminal identification" as one broken feature wastes so much time.
A Huawei S-series campus switch identifies connected terminals through three genuinely separate mechanisms: active probing — an immediate, online-triggered, or periodic scan that sends probe packets and reads what comes back, plus a port scan and a deeper protocol scan layered on top of it; deep-flow collection, which captures and inspects a terminal's actual five-tuple traffic; and passive fingerprinting, which quietly reads DHCP, mDNS and HTTP fields out of traffic the terminal was going to send anyway. Each one has its own trigger, its own counters, and its own way of going quiet.
What follows is the fault tree these three mechanisms sit on, the diagnose-view commands that tell you which one is actually failing, the five root causes that explain most misidentification and no-result tickets, and five FAQ answers pulled from real field cases. If the terminal you're chasing also needs to pass 802.1X or MAC-based access control once it's identified, that's a separate negotiation with its own failure modes — see dot1x-nac-authentication-troubleshooting.html for that side of it.
Before comparing algorithms or vendor lists, place the symptom on one of two branches — that alone tells you which commands below actually apply.
No result at all across every method usually means the report path itself is broken, before any of the three mechanisms even gets a chance to run.
Diagram labels are kept in English for engineering clarity.
Once the symptom is on the right branch, the counters in display terminal-identify statistics and display terminal-identify running-status do almost all of the remaining work — they tell you whether packets left the switch, whether the terminal replied, and whether the service itself was even running at the time.
Four mechanisms, four different counters — and the sequence that tells you which one is actually stuck.
If display terminal-identify probe result comes back empty, don't assume the terminal is unsupported yet — confirm the probe actually reached it first.
<HUAWEI> display terminal-identify probe result
No records found.
<HUAWEI> diagnose
[HUAWEI-diagnose] display terminal-identify return-packet
MAC IP SrcPort DstPort AppProtocol Count LastReceivedTime
00e0-fc11-3456 10.2.1.1 37810 49153 onvif 1 2026-01-10T10:58:13+00:00
// LastReceivedTime falls inside the test window -> reply was received, check rule-matching next
[HUAWEI-diagnose] display cpu-defend configuration packet-type ntid-probe-reply all
PacketType Status Current(pps) Default(pps)
ntid-probe-reply Enabled 150 150
// Status must read Enabled with a non-zero rate, or the receive policy is dropping the reply itself
[HUAWEI-diagnose] display terminal-identify statistics
Type Total-num Error-num Dropped-num
dcp-tx 252 0 0
dcp-rx 0 0 0
// dcp-rx stuck at 0 -> switch is sending probes but never receiving anything backDeep scan runs its own port scan and protocol scan across the terminal's open services — three separate things can stop it before it ever gets there.
[HUAWEI-diagnose] display terminal-identify configuration-status
Module:deep-scan
Item Value
monitoring-deep-scan Vlan1
Vlan2403, src-ip is invalid
Bd1, subnet not created
// an invalid src-ip or "subnet not created" means there is no valid source to scan from
[HUAWEI-diagnose] display terminal-identify running-status
CPU status:normal
Module Status
deep-scan running
passive disabled
// "interrupted" here means CPU load is over threshold -- not a configuration fault
[HUAWEI-diagnose] display terminal-identify port-scan scope
IP MAC Vlan Scanned LastTriggeringTime
10.1.0.95 00e0-6daa-1d5b 1 false -
// Scanned = false just means the scan for this terminal hasn't finished yetFlow collection has its own trust-list exemption that silently drops a port out of scope — worth checking before anything else.
[HUAWEI-diagnose] display terminal-identify configuration-status
Module:flow
Item Value
trusted-interfaces GE1/0/1
deep-collect-global-cfg speedLimit(pps): 600, durationTime(min): 60
// a terminal sitting behind a trusted interface is deliberately excluded from flow collection
[HUAWEI-diagnose] display system tcam service brief
Chip GroupID Stage ServiceName Count
0 282 Ingress NTID-FLOW 48
// NTID-FLOW count should track roughly 2x the number of terminals currently being collected
[HUAWEI-diagnose] display terminal-identify statistics
Type Total-num Error-num Dropped-num
deep-collect-rx 545 0 2
// deep-collect-rx stuck at 0 means the ACL for that terminal's flow was never programmed into hardwarePassive fingerprinting only reads traffic the terminal was already going to send — nothing to scan, nothing to trigger, which makes silent failures easy to miss.
<HUAWEI> display current-configuration | include terminal-identify feature
terminal-identify feature scope { all | vlan-id | bd-id }
// confirm the terminal's own VLAN/BD is actually inside this scope, not just assumed under "all"
[HUAWEI-diagnose] display terminal-identify running-status
CPU status:normal
Module Status
passive running
// "interrupted" here means CPU crossed 80% and the feature is paused until it drops back under 70%
[HUAWEI-diagnose] debugging ntid all
NTID_DEBUG(d):Service=lsrv0;[DEBUG] option60 = huawei S380-H8T3ST.
NTID_DEBUG(d):Service=lsrv0;[DEBUG] SrcMac=58be-72a2-000E,ethType=0x800,vlan=1
// if nothing prints at all after re-triggering traffic, the packet never reached the serviceOnce the four mechanisms above have told you where the problem sits, these five explain most of what's actually wrong.
SYMPTOMdisplay terminal-identify probe result or display terminal-identify feature comes back empty for one specific terminal, no matter which scan method is tried.
CAUSEActive recognition only covers three device categories — IP cameras, IP phones and printers — from a specific list of vendors, and even within that list some models only reply to particular protocols, such as an IP camera without ONVIF enabled, which won't reply to the probe at all. Passive fingerprinting is narrower still: PCs, phones and tablets, read from DHCP, mDNS and HTTP traffic. A terminal outside both lists was never going to produce a result, regardless of how many scan methods get tried.
FIXConfirm the terminal's vendor and protocol support against the supported list before spending more time on scan configuration; if the model genuinely needs support, capture its post-reboot traffic and its response to the probe and escalate it as a feature request rather than a fault.
SYMPTOMDeep scan or passive fingerprinting worked fine before and simply stopped, with no configuration change and no obvious error anywhere.
CAUSEBoth services check the switch's own CPU load before running at all. display terminal-identify running-status reports a module as interrupted rather than failed once CPU crosses its threshold — deep scan pauses above 80%, and passive fingerprinting won't resume until CPU drops back under about 70%. Nothing in the configuration is wrong; the switch is simply protecting itself.
FIXCheck display terminal-identify running-status before touching any configuration. If CPU is genuinely over threshold, find and reduce whatever else is loading it — other features, other scans, a burst of unrelated traffic — rather than reconfiguring terminal identification itself.
SYMPTOMEvery other terminal on the switch gets collected; one specific terminal never shows up in display terminal-identify deep-collect statistics, no matter how long you wait.
CAUSEdisplay terminal-identify configuration-status under Module:flow lists a trusted-interfaces set — any terminal behind one of those ports is deliberately excluded from flow collection by design, not by accident. It's easy to forget that list exists once it was configured for an entirely different reason.
FIXCheck the trusted-interfaces list before assuming collection is broken. If the terminal genuinely needs to be collected, remove its port from the trust list; if the port was trusted on purpose, this is expected behavior, not a fault.
SYMPTOMdisplay terminal-identify statistics shows dcp-rx, or deep-scan-rx, or deep-collect-rx stuck at 0, even though the terminal is definitely online and answers a normal ping.
CAUSEEvery identification mechanism relies on the same underlying path: an ACL has to be programmed into hardware, and the resulting microcode entry has to actually deliver the reply packet up to the identification service. If the ACL never got programmed, or the packet is dropped by the HOST component before it reaches the service, every mechanism looks identical from the outside — quiet, with nothing to show for it.
FIXCheck display cpu-defend configuration all for the ntid entries' Status field, then the matching microcode cause-ID counter under display forward information on the relevant slot and chip. If that counter isn't incrementing, this is a delivery problem below the identification service itself, worth escalating with a HOST-side packet capture rather than reconfiguring the feature.
SYMPTOMdisplay terminal-identify port-scan result or deep-scan record shows exactly what you'd expect right there on the switch, but the controller's terminal view shows nothing for that device.
CAUSEReporting fingerprint data upstream is a separate step from collecting it — it depends on a telemetry subscription with the right sensor-path configured for deep-scan fingerprints and port statuses. If that subscription was never configured, or the destination address is wrong, the switch keeps collecting perfectly good data that nothing ever picks up.
FIXCheck display terminal-identify statistics for the telemetry-tx counter. If Total-num stays at 0 while the switch-side commands show real data, review the telemetry sensor-group and destination-group configuration under the telemetry view rather than the terminal-identify configuration itself.
Pulled straight from the field — the ones worth having an answer ready for.
Run display terminal-identify probe result in any view — it lists the cached active-recognition results, including IP, MAC, category, vendor and model, for every terminal the switch has scanned.
A terminal's IP address and MAC address, plus the attributes that actually matter for policy: device category, vendor, and model. Passive fingerprinting results are read the same way through display terminal-identify feature, though that command only covers DHCP, mDNS and HTTP fingerprints — LLDP-based fingerprints are a separate LLDP-service function, read through display lldp neighbor instead.
By far the most common reason is that the terminal simply isn't in the supported recognition range — active recognition only covers IP cameras, IP phones and printers, and passive recognition only covers PCs, phones and tablets. Beyond that, terminals inside the supported range don't all respond to probes the same way, so if one method comes back empty, it's worth trying online-triggered scan, periodic scan, immediate scan and port scan before concluding the terminal is unreachable.
Active probing sends a lightweight probe and reads the direct reply — fastest, but limited to the three supported device categories. Deep scan adds a full port scan and protocol scan across the terminal's open services for a fuller picture. Deep-flow collection captures the terminal's actual five-tuple traffic instead of probing it, which works even on terminals that never reply to anything. Passive fingerprinting doesn't send anything at all — it just reads DHCP, mDNS and HTTP fields out of traffic the terminal was already sending, which makes it the quietest option, but also the one most dependent on the terminal happening to generate that traffic in the first place.
Check display terminal-identify running-status first. Passive fingerprinting, like deep scan, is CPU-gated — once the switch's own CPU load crosses roughly 80%, the passive module reports interrupted and pauses until load drops back under about 70%. This is a self-protection mechanism, not a configuration fault, so the fix is to find what's actually loading the CPU rather than touching the terminal-identify configuration.
This note is built around the terminal-identify feature's fault-locating guidance and field cases in Huawei's S-series campus switch maintenance manual — S1720, S5700, S6700, S6730, S7700 and related models. It doesn't cover the cloud-managed campus controller's own terminal-profiling interface in depth, or third-party endpoint-fingerprinting engines integrated through other means — only the switch-side scanning, collection and fingerprinting mechanisms and the diagnose-view commands behind them.
Tell us which mechanism you've tried — active probe, deep scan, deep-flow collection or passive fingerprint — plus the display terminal-identify statistics and running-status output, and we'll help you read it.