Una cámara que aparece como dispositivo desconocido, un teléfono que nunca obtiene categoría alguna, una huella que funcionaba y de pronto deja de hacerlo — la identificación de terminales en un switch de campus se basa en tres mecanismos independientes, y cada uno falla a su manera. Este es el orden que permite encontrar cuál está realmente averiado, los comandos exactos en vista diagnose que hay que ejecutar, y las cinco razones que explican la mayoría de estos casos.
Por Yuwen Zhang (Atlas), fundador de AtlasCommTech — 13 años de despliegues de redes de operadores y empresariales · Actualizado en julio de 2026
Los tres mecanismos no comparten un único modo de falla — precisamente por eso tratar la «identificación de terminales» como una sola función averiada hace perder tanto tiempo.
Un switch de campus Huawei serie S identifica los terminales conectados mediante tres mecanismos realmente independientes: el sondeo activo — un escaneo inmediato, disparado en línea, o periódico que envía paquetes de sondeo y lee lo que regresa, con un escaneo de puertos y un análisis de protocolo más profundo superpuestos; la recopilación de flujo profundo, que captura e inspecta el tráfico real de cinco tuplas del terminal; y la huella pasiva, que lee discretamente los campos DHCP, mDNS y HTTP del tráfico que el terminal ya iba a enviar. Cada uno tiene su propio disparador, sus propios contadores, y su propia forma de quedarse en silencio.
A continuación, el árbol de fallas en el que se apoyan estos tres mecanismos, los comandos en vista diagnose que indican cuál está realmente fallando, las cinco causas raíz que explican la mayoría de los casos de identificación errónea y sin resultado, y cinco respuestas de preguntas frecuentes extraídas de casos reales de campo. Si el terminal que persigue también necesita pasar autenticación 802.1X o basada en MAC una vez identificado, esa es una negociación aparte con sus propios modos de falla — vea dot1x-nac-authentication-troubleshooting.html para esa parte.
Antes de comparar algoritmos o listas de fabricantes, ubique el síntoma en una de dos ramas — solo eso ya indica cuáles comandos siguientes aplican realmente.
Ningún resultado en absoluto con ningún método suele significar que la ruta de reporte en sí está rota, antes de que cualquiera de los tres mecanismos siquiera tenga oportunidad de ejecutarse.
Las etiquetas del diagrama se mantienen en inglés por claridad técnica.
Una vez que el síntoma está en la rama correcta, los contadores de display terminal-identify statistics y display terminal-identify running-status hacen casi todo el trabajo restante — indican si los paquetes salieron del switch, si el terminal respondió, y si el servicio en sí estaba en ejecución en ese momento.
Cuatro mecanismos, cuatro contadores distintos — y la secuencia que indica cuál está realmente atascado.
Si display terminal-identify probe result vuelve vacío, no asuma todavía que el terminal no es compatible — confirme primero que el sondeo realmente lo alcanzó.
<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 backEl escaneo profundo ejecuta su propio escaneo de puertos y análisis de protocolo sobre los servicios abiertos del terminal — tres cosas distintas pueden detenerlo antes de que llegue siquiera.
[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 recopilación de flujo tiene su propia exención de lista de confianza que excluye silenciosamente un puerto del alcance — vale la pena revisarlo antes que nada.
[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 hardwareLa huella pasiva solo lee el tráfico que el terminal ya iba a enviar — nada que escanear, nada que disparar, lo que hace que las fallas silenciosas sean fáciles de pasar por alto.
<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 serviceUna vez que los cuatro mecanismos anteriores han indicado dónde está el problema, estas cinco causas explican la mayor parte de lo que realmente falla.
SÍNTOMAdisplay terminal-identify probe result o display terminal-identify feature vuelve vacío para un terminal específico, sin importar qué método de escaneo se intente.
CAUSAEl reconocimiento activo solo cubre tres categorías de dispositivos — cámaras IP, teléfonos IP e impresoras — de una lista específica de fabricantes, e incluso dentro de esa lista algunos modelos solo responden a protocolos particulares, como una cámara IP sin ONVIF habilitado, que no responderá al sondeo en absoluto. La huella pasiva es aún más limitada: PC, teléfonos y tabletas, leídos del tráfico DHCP, mDNS y HTTP. Un terminal fuera de ambas listas nunca iba a producir un resultado, sin importar cuántos métodos de escaneo se intenten.
SOLUCIÓNConfirme la compatibilidad del fabricante y el protocolo del terminal con la lista compatible antes de dedicar más tiempo a la configuración del escaneo; si el modelo realmente necesita soporte, capture su tráfico tras reiniciar y su respuesta al sondeo, y escálelo como una solicitud de función en lugar de una falla.
SÍNTOMAEl escaneo profundo o la huella pasiva funcionaban bien antes y simplemente dejaron de hacerlo, sin cambio de configuración y sin error evidente en ninguna parte.
CAUSAAmbos servicios verifican la carga de CPU del propio switch antes de ejecutarse. display terminal-identify running-status reporta un módulo como interrupted en lugar de failed una vez que la CPU cruza su umbral — el escaneo profundo se pausa por encima del 80%, y la huella pasiva no se reanuda hasta que la CPU baja de nuevo por debajo de aproximadamente el 70%. Nada en la configuración está mal; el switch simplemente se está protegiendo a sí mismo.
SOLUCIÓNVerifique display terminal-identify running-status antes de tocar cualquier configuración. Si la CPU realmente está por encima del umbral, encuentre y reduzca lo que sea que la esté cargando — otras funciones, otros escaneos, una ráfaga de tráfico no relacionado — en lugar de reconfigurar la identificación de terminales en sí.
SÍNTOMATodos los demás terminales del switch se recopilan; un terminal específico nunca aparece en display terminal-identify deep-collect statistics, sin importar cuánto se espere.
CAUSAdisplay terminal-identify configuration-status bajo Module:flow enumera un conjunto trusted-interfaces — cualquier terminal detrás de uno de esos puertos queda deliberadamente excluido de la recopilación de flujo por diseño, no por accidente. Es fácil olvidar que esa lista existe una vez que se configuró por una razón completamente distinta.
SOLUCIÓNVerifique la lista trusted-interfaces antes de asumir que la recopilación está rota. Si el terminal realmente necesita ser recopilado, elimine su puerto de la lista de confianza; si el puerto se confió a propósito, este es el comportamiento esperado, no una falla.
SÍNTOMAdisplay terminal-identify statistics muestra dcp-rx, o deep-scan-rx, o deep-collect-rx atascado en 0, aunque el terminal definitivamente está en línea y responde a un ping normal.
CAUSACada mecanismo de identificación depende de la misma ruta subyacente: una ACL debe programarse en el hardware, y la entrada de microcódigo resultante debe realmente entregar el paquete de respuesta hasta el servicio de identificación. Si la ACL nunca se programó, o el paquete es descartado por el componente HOST antes de llegar al servicio, cada mecanismo se ve idéntico desde afuera — silencioso, sin nada que mostrar.
SOLUCIÓNVerifique el campo Status de las entradas ntid en display cpu-defend configuration all, luego el contador de cause-ID de microcódigo correspondiente bajo display forward information en el slot y chip relevantes. Si ese contador no se incrementa, es un problema de entrega por debajo del propio servicio de identificación, que merece escalarse con una captura de paquetes del lado HOST en lugar de reconfigurar la función.
SÍNTOMAdisplay terminal-identify port-scan result o deep-scan record muestra exactamente lo esperado ahí mismo en el switch, pero la vista de terminales del controlador no muestra nada para ese dispositivo.
CAUSAReportar los datos de huella hacia arriba es un paso separado de recopilarlos — depende de una suscripción telemetry con el sensor-path correcto configurado para huellas de deep-scan y estados de puerto. Si esa suscripción nunca se configuró, o la dirección de destino es incorrecta, el switch sigue recopilando datos perfectamente válidos que nadie recoge jamás.
SOLUCIÓNVerifique el contador telemetry-tx en display terminal-identify statistics. Si Total-num permanece en 0 mientras los comandos del lado del switch muestran datos reales, revise la configuración de sensor-group y destination-group bajo la vista telemetry en lugar de la configuración terminal-identify en sí.
Sacadas directamente del campo — las que vale la pena tener respuesta lista.
Ejecute display terminal-identify probe result en cualquier vista — enumera los resultados de reconocimiento activo en caché, incluyendo IP, MAC, categoría, fabricante y modelo, para cada terminal que el switch haya escaneado.
La dirección IP y la dirección MAC de un terminal, más los atributos que realmente importan para la política: categoría del dispositivo, fabricante y modelo. Los resultados de huella pasiva se leen de la misma manera mediante display terminal-identify feature, aunque ese comando solo cubre huellas DHCP, mDNS y HTTP — las huellas basadas en LLDP son una función separada del servicio LLDP, leída mediante display lldp neighbor.
Con diferencia, la razón más común es que el terminal simplemente no está dentro del rango de reconocimiento compatible — el reconocimiento activo solo cubre cámaras IP, teléfonos IP e impresoras, y el reconocimiento pasivo solo cubre PC, teléfonos y tabletas. Más allá de eso, los terminales dentro del rango compatible no responden todos igual a los sondeos, así que si un método vuelve vacío, vale la pena probar escaneo disparado en línea, periódico, inmediato y de puertos antes de concluir que el terminal es inalcanzable.
El sondeo activo envía un sondeo ligero y lee la respuesta directa — el más rápido, pero limitado a las tres categorías de dispositivos compatibles. El escaneo profundo añade un escaneo de puertos completo y un análisis de protocolo sobre los servicios abiertos del terminal para una imagen más completa. La recopilación de flujo profundo captura el tráfico real de cinco tuplas del terminal en lugar de sondearlo, lo que funciona incluso en terminales que nunca responden a nada. La huella pasiva no envía nada en absoluto — solo lee campos DHCP, mDNS y HTTP del tráfico que el terminal ya estaba enviando, lo que la convierte en la opción más silenciosa, pero también en la más dependiente de que el terminal genere ese tráfico en primer lugar.
Verifique primero display terminal-identify running-status. La huella pasiva, como el escaneo profundo, está condicionada por la CPU — una vez que la carga de CPU del switch cruza aproximadamente el 80%, el módulo passive reporta interrupted y se pausa hasta que la carga baja de nuevo por debajo de aproximadamente el 70%. Este es un mecanismo de autoprotección, no una falla de configuración, así que la solución es encontrar qué está realmente cargando la CPU en lugar de tocar la configuración de terminal-identify.
Esta nota se basa en la guía de localización de fallos de la función terminal-identify y en los casos de campo del manual de mantenimiento de switches de campus Huawei serie S — S1720, S5700, S6700, S6730, S7700 y modelos relacionados. No cubre en profundidad la propia interfaz de perfilado de terminales del controlador de campus gestionado en la nube, ni los motores de huella de terminales de terceros integrados por otros medios — solo los mecanismos de escaneo, recopilación y huella del lado del switch y los comandos en vista diagnose que los respaldan.
Cuéntenos qué mecanismo ha probado — sondeo activo, escaneo profundo, recopilación de flujo profundo o huella pasiva — más la salida de display terminal-identify statistics y running-status, y le ayudaremos a interpretarla.