Une caméra qui apparaît comme un appareil inconnu, un téléphone qui n'obtient jamais de catégorie, une empreinte qui fonctionnait et s'arrête soudainement — l'identification des terminaux sur un commutateur de campus repose sur trois mécanismes distincts, et chacun tombe en panne à sa manière. Voici l'ordre qui permet de trouver lequel est réellement défaillant, les commandes exactes en vue diagnose à exécuter, et les cinq raisons qui expliquent la plupart de ces tickets.
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
Les trois mécanismes ne partagent pas un seul mode de défaillance — c'est exactement pourquoi traiter « l'identification des terminaux » comme une seule fonction en panne fait perdre tant de temps.
Un commutateur de campus Huawei série S identifie les terminaux connectés via trois mécanismes réellement distincts : le sondage actif — une analyse immédiate, déclenchée en ligne, ou périodique qui envoie des paquets de sonde et lit ce qui revient, avec en plus un balayage de ports et une analyse de protocole plus poussée ; la collecte de flux approfondie, qui capture et inspecte le trafic réel à cinq éléments du terminal ; et l'empreinte passive, qui lit discrètement les champs DHCP, mDNS et HTTP dans le trafic que le terminal allait de toute façon envoyer. Chacun a son propre déclencheur, ses propres compteurs, et sa propre façon de devenir silencieux.
Voici l'arbre de panne sur lequel reposent ces trois mécanismes, les commandes en vue diagnose qui indiquent lequel est réellement en cause, les cinq causes profondes qui expliquent la plupart des tickets de mauvaise identification et d'absence de résultat, et cinq réponses de FAQ tirées de cas de terrain réels. Si le terminal que vous traquez doit aussi passer une authentification 802.1X ou basée sur l'adresse MAC une fois identifié, il s'agit d'une négociation distincte avec ses propres modes de défaillance — voir dot1x-nac-authentication-troubleshooting.html pour cet aspect.
Avant de comparer les algorithmes ou les listes de fournisseurs, placez le symptôme sur l'une des deux branches — cela seul indique quelles commandes ci-dessous s'appliquent réellement.
Aucun résultat du tout, quelle que soit la méthode, signifie généralement que le chemin de remontée lui-même est en panne, avant même que l'un des trois mécanismes ait eu la chance de s'exécuter.
Les légendes du schéma restent en anglais pour la clarté technique.
Une fois le symptôme sur la bonne branche, les compteurs de display terminal-identify statistics et display terminal-identify running-status font presque tout le reste du travail — ils indiquent si des paquets ont quitté le commutateur, si le terminal a répondu, et si le service lui-même fonctionnait à ce moment-là.
Quatre mécanismes, quatre compteurs différents — et la séquence qui indique lequel est réellement bloqué.
Si display terminal-identify probe result revient vide, ne présumez pas encore que le terminal n'est pas pris en charge — confirmez d'abord que la sonde l'a réellement atteint.
<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 backL'analyse approfondie effectue son propre balayage de ports et analyse de protocole sur les services ouverts du terminal — trois choses distinctes peuvent l'arrêter avant même qu'elle n'y arrive.
[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 yetLa collecte de flux a sa propre exemption de liste de confiance qui exclut silencieusement un port de la portée — à vérifier avant tout le reste.
[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 hardwareL'empreinte passive ne fait que lire le trafic que le terminal allait de toute façon envoyer — rien à scanner, rien à déclencher, ce qui rend les pannes silencieuses faciles à manquer.
<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 serviceUne fois que les quatre mécanismes ci-dessus ont indiqué où se situe le problème, ces cinq causes expliquent l'essentiel de ce qui ne va vraiment pas.
SYMPTÔMEdisplay terminal-identify probe result ou display terminal-identify feature revient vide pour un terminal spécifique, quelle que soit la méthode d'analyse essayée.
CAUSELa reconnaissance active ne couvre que trois catégories d'appareils — caméras IP, téléphones IP et imprimantes — issues d'une liste précise de fournisseurs, et même dans cette liste, certains modèles ne répondent qu'à des protocoles particuliers, comme une caméra IP sans ONVIF activé, qui ne répondra pas du tout à la sonde. L'empreinte passive est plus restreinte encore : PC, téléphones et tablettes, lue à partir du trafic DHCP, mDNS et HTTP. Un terminal hors de ces deux listes n'allait jamais produire de résultat, quel que soit le nombre de méthodes d'analyse essayées.
SOLUTIONConfirmez la prise en charge du fournisseur et du protocole du terminal par rapport à la liste prise en charge avant de passer plus de temps sur la configuration de l'analyse ; si le modèle a réellement besoin d'un support, capturez son trafic après redémarrage et sa réponse à la sonde, et faites-en une demande de fonctionnalité plutôt qu'une panne.
SYMPTÔMEL'analyse approfondie ou l'empreinte passive fonctionnait bien auparavant et s'est simplement arrêtée, sans changement de configuration et sans erreur évidente nulle part.
CAUSELes deux services vérifient la charge CPU du commutateur avant de s'exécuter du tout. display terminal-identify running-status signale un module comme interrupted plutôt que failed une fois que le CPU dépasse son seuil — l'analyse approfondie se met en pause au-delà de 80 %, et l'empreinte passive ne reprend pas tant que le CPU n'est pas redescendu sous environ 70 %. Rien n'est faux dans la configuration ; le commutateur se protège simplement.
SOLUTIONVérifiez display terminal-identify running-status avant de toucher à la moindre configuration. Si le CPU dépasse réellement le seuil, trouvez et réduisez ce qui le charge — d'autres fonctions, d'autres analyses, une rafale de trafic sans rapport — plutôt que de reconfigurer l'identification des terminaux elle-même.
SYMPTÔMETous les autres terminaux du commutateur sont collectés ; un terminal spécifique n'apparaît jamais dans display terminal-identify deep-collect statistics, peu importe le temps d'attente.
CAUSEdisplay terminal-identify configuration-status sous Module:flow répertorie un ensemble trusted-interfaces — tout terminal derrière l'un de ces ports est délibérément exclu de la collecte de flux par conception, pas par accident. Il est facile d'oublier que cette liste existe une fois qu'elle a été configurée pour une raison totalement différente.
SOLUTIONVérifiez la liste trusted-interfaces avant de supposer que la collecte est en panne. Si le terminal doit vraiment être collecté, retirez son port de la liste de confiance ; si le port a été mis en confiance intentionnellement, c'est un comportement attendu, pas une panne.
SYMPTÔMEdisplay terminal-identify statistics montre dcp-rx, ou deep-scan-rx, ou deep-collect-rx bloqué à 0, alors que le terminal est définitivement en ligne et répond à un ping normal.
CAUSEChaque mécanisme d'identification repose sur le même chemin sous-jacent : une ACL doit être programmée dans le matériel, et l'entrée de microcode résultante doit effectivement livrer le paquet de réponse jusqu'au service d'identification. Si l'ACL n'a jamais été programmée, ou si le paquet est rejeté par le composant HOST avant d'atteindre le service, chaque mécanisme paraît identique de l'extérieur — silencieux, sans rien à montrer.
SOLUTIONVérifiez le champ Status des entrées ntid dans display cpu-defend configuration all, puis le compteur de cause-ID de microcode correspondant sous display forward information sur le slot et le chip concernés. Si ce compteur n'augmente pas, il s'agit d'un problème de livraison en dessous du service d'identification lui-même, qui mérite une escalade avec une capture de paquets côté HOST plutôt qu'une reconfiguration de la fonction.
SYMPTÔMEdisplay terminal-identify port-scan result ou deep-scan record montre exactement ce à quoi on s'attendrait directement sur le commutateur, mais la vue des terminaux du contrôleur ne montre rien pour cet appareil.
CAUSERemonter les données d'empreinte est une étape distincte de leur collecte — cela dépend d'un abonnement telemetry avec le bon sensor-path configuré pour les empreintes deep-scan et les statuts de port. Si cet abonnement n'a jamais été configuré, ou si l'adresse de destination est erronée, le commutateur continue de collecter des données parfaitement valides que rien ne récupère jamais.
SOLUTIONVérifiez le compteur telemetry-tx dans display terminal-identify statistics. Si Total-num reste à 0 alors que les commandes côté commutateur montrent des données réelles, revoyez la configuration sensor-group et destination-group en vue telemetry plutôt que la configuration terminal-identify elle-même.
Tirées directement du terrain — celles pour lesquelles il vaut la peine d'avoir une réponse prête.
Exécutez display terminal-identify probe result dans n'importe quelle vue — elle liste les résultats de reconnaissance active mis en cache, y compris IP, MAC, catégorie, fournisseur et modèle, pour chaque terminal analysé par le commutateur.
L'adresse IP et l'adresse MAC d'un terminal, plus les attributs qui comptent réellement pour la politique : catégorie d'appareil, fournisseur et modèle. Les résultats de l'empreinte passive se lisent de la même façon via display terminal-identify feature, bien que cette commande ne couvre que les empreintes DHCP, mDNS et HTTP — les empreintes basées sur LLDP sont une fonction distincte du service LLDP, à lire via display lldp neighbor.
De loin, la raison la plus courante est que le terminal n'est tout simplement pas dans la plage de reconnaissance prise en charge — la reconnaissance active ne couvre que les caméras IP, téléphones IP et imprimantes, et la reconnaissance passive ne couvre que les PC, téléphones et tablettes. Au-delà de cela, les terminaux dans la plage prise en charge ne répondent pas tous de la même manière aux sondes, donc si une méthode revient vide, il vaut la peine d'essayer l'analyse déclenchée en ligne, périodique, immédiate et le balayage de ports avant de conclure que le terminal est inaccessible.
Le sondage actif envoie une sonde légère et lit la réponse directe — le plus rapide, mais limité aux trois catégories d'appareils prises en charge. L'analyse approfondie ajoute un balayage de ports complet et une analyse de protocole sur les services ouverts du terminal pour une image plus complète. La collecte de flux approfondie capture le trafic réel à cinq éléments du terminal au lieu de le sonder, ce qui fonctionne même sur les terminaux qui ne répondent jamais à rien. L'empreinte passive n'envoie rien du tout — elle lit simplement les champs DHCP, mDNS et HTTP du trafic que le terminal envoyait déjà, ce qui en fait l'option la plus discrète, mais aussi celle la plus dépendante du fait que le terminal génère effectivement ce trafic.
Vérifiez d'abord display terminal-identify running-status. L'empreinte passive, comme l'analyse approfondie, est conditionnée au CPU — une fois que la charge CPU du commutateur dépasse environ 80 %, le module passive signale interrupted et se met en pause jusqu'à ce que la charge redescende sous environ 70 %. C'est un mécanisme d'autoprotection, pas une panne de configuration, donc la solution consiste à trouver ce qui charge réellement le CPU plutôt que de toucher à la configuration terminal-identify.
Cette note s'appuie sur les indications de localisation des pannes de la fonction terminal-identify et sur les cas de terrain du manuel de maintenance des commutateurs de campus Huawei série S — S1720, S5700, S6700, S6730, S7700 et modèles apparentés. Elle ne couvre pas en profondeur l'interface de profilage des terminaux du contrôleur de campus géré dans le cloud, ni les moteurs d'empreinte de terminaux tiers intégrés par d'autres moyens — uniquement les mécanismes de balayage, de collecte et d'empreinte côté commutateur et les commandes en vue diagnose qui les sous-tendent.
Dites-nous quel mécanisme vous avez essayé — sondage actif, analyse approfondie, collecte de flux approfondie ou empreinte passive — plus la sortie de display terminal-identify statistics et running-status, et nous vous aiderons à l'interpréter.