Uma câmera que aparece como dispositivo desconhecido, um telefone que nunca recebe categoria alguma, uma impressão digital que funcionava e de repente para — a identificação de terminais em um switch de campus depende de três mecanismos separados, e cada um falha à sua maneira. Esta é a ordem que encontra qual deles está realmente quebrado, os comandos exatos na visão diagnose a executar, e as cinco razões que respondem pela maioria desses chamados.
Por Yuwen Zhang (Atlas), fundador da AtlasCommTech — 13 anos de implantações de redes de operadoras e empresariais · Atualizado em julho de 2026
Os três mecanismos não compartilham um único modo de falha — exatamente por isso tratar a «identificação de terminais» como um único recurso quebrado desperdiça tanto tempo.
Um switch de campus Huawei série S identifica os terminais conectados por meio de três mecanismos realmente separados: a sondagem ativa — uma varredura imediata, disparada online, ou periódica que envia pacotes de sondagem e lê o que retorna, com uma varredura de portas e uma análise de protocolo mais profunda sobrepostas; a coleta de fluxo profundo, que captura e inspeciona o tráfego real de cinco tuplas do terminal; e a impressão digital passiva, que lê discretamente campos DHCP, mDNS e HTTP do tráfego que o terminal já ia enviar de qualquer forma. Cada um tem seu próprio gatilho, seus próprios contadores, e sua própria forma de ficar em silêncio.
A seguir está a árvore de falhas em que se apoiam esses três mecanismos, os comandos na visão diagnose que indicam qual está realmente falhando, as cinco causas-raiz que explicam a maioria dos chamados de identificação incorreta e sem resultado, e cinco respostas de perguntas frequentes tiradas de casos reais de campo. Se o terminal que você está rastreando também precisa passar por autenticação 802.1X ou baseada em MAC depois de identificado, essa é uma negociação separada com seus próprios modos de falha — veja dot1x-nac-authentication-troubleshooting.html para essa parte.
Antes de comparar algoritmos ou listas de fabricantes, coloque o sintoma em um dos dois ramos — só isso já indica quais comandos abaixo realmente se aplicam.
Nenhum resultado com qualquer método geralmente significa que o próprio caminho de relato está quebrado, antes mesmo que qualquer um dos três mecanismos tenha chance de rodar.
Os rótulos do diagrama permanecem em inglês para clareza técnica.
Uma vez que o sintoma está no ramo certo, os contadores de display terminal-identify statistics e display terminal-identify running-status fazem quase todo o trabalho restante — eles dizem se os pacotes saíram do switch, se o terminal respondeu, e se o próprio serviço estava rodando naquele momento.
Quatro mecanismos, quatro contadores diferentes — e a sequência que indica qual deles está realmente travado.
Se display terminal-identify probe result voltar vazio, não presuma ainda que o terminal não é suportado — confirme primeiro se a sondagem realmente o alcançou.
<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 backA varredura profunda executa sua própria varredura de portas e análise de protocolo nos serviços abertos do terminal — três coisas distintas podem impedi-la antes mesmo de chegar lá.
[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 yetA coleta de fluxo tem sua própria isenção de lista de confiança que exclui silenciosamente uma porta do escopo — vale a pena verificar isso antes de qualquer outra coisa.
[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 hardwareA impressão digital passiva apenas lê o tráfego que o terminal já ia enviar de qualquer forma — nada para varrer, nada para disparar, o que torna as falhas silenciosas fáceis de passar despercebidas.
<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 serviceDepois que os quatro mecanismos acima indicarem onde está o problema, essas cinco causas explicam a maior parte do que realmente está errado.
SINTOMAdisplay terminal-identify probe result ou display terminal-identify feature volta vazio para um terminal específico, não importa qual método de varredura seja tentado.
CAUSAO reconhecimento ativo cobre apenas três categorias de dispositivos — câmeras IP, telefones IP e impressoras — de uma lista específica de fabricantes, e mesmo dentro dessa lista alguns modelos só respondem a protocolos específicos, como uma câmera IP sem ONVIF habilitado, que não responderá à sondagem de jeito nenhum. A impressão digital passiva é ainda mais restrita: PCs, telefones e tablets, lidos do tráfego DHCP, mDNS e HTTP. Um terminal fora de ambas as listas nunca produziria um resultado, não importa quantos métodos de varredura sejam tentados.
SOLUÇÃOConfirme a compatibilidade do fabricante e do protocolo do terminal com a lista suportada antes de gastar mais tempo na configuração da varredura; se o modelo realmente precisar de suporte, capture seu tráfego após reiniciar e sua resposta à sondagem, e escale isso como uma solicitação de recurso em vez de uma falha.
SINTOMAA varredura profunda ou a impressão digital passiva funcionavam bem antes e simplesmente pararam, sem mudança de configuração e sem erro óbvio em lugar nenhum.
CAUSAAmbos os serviços verificam a carga de CPU do próprio switch antes de rodar. display terminal-identify running-status reporta um módulo como interrupted em vez de failed quando a CPU ultrapassa seu limite — a varredura profunda pausa acima de 80%, e a impressão digital passiva não retoma até a CPU cair novamente abaixo de cerca de 70%. Nada na configuração está errado; o switch está simplesmente se protegendo.
SOLUÇÃOVerifique display terminal-identify running-status antes de mexer em qualquer configuração. Se a CPU realmente estiver acima do limite, encontre e reduza o que quer que esteja sobrecarregando-a — outros recursos, outras varreduras, uma rajada de tráfego não relacionado — em vez de reconfigurar a identificação de terminais em si.
SINTOMATodos os outros terminais no switch são coletados; um terminal específico nunca aparece em display terminal-identify deep-collect statistics, não importa quanto tempo se espere.
CAUSAdisplay terminal-identify configuration-status em Module:flow lista um conjunto trusted-interfaces — qualquer terminal atrás de uma dessas portas é deliberadamente excluído da coleta de fluxo por design, não por acidente. É fácil esquecer que essa lista existe depois que foi configurada por um motivo completamente diferente.
SOLUÇÃOVerifique a lista trusted-interfaces antes de presumir que a coleta está quebrada. Se o terminal realmente precisar ser coletado, remova sua porta da lista de confiança; se a porta foi confiada de propósito, esse é o comportamento esperado, não uma falha.
SINTOMAdisplay terminal-identify statistics mostra dcp-rx, ou deep-scan-rx, ou deep-collect-rx travado em 0, mesmo que o terminal definitivamente esteja online e responda a um ping normal.
CAUSACada mecanismo de identificação depende do mesmo caminho subjacente: uma ACL precisa ser programada no hardware, e a entrada de microcódigo resultante precisa realmente entregar o pacote de resposta até o serviço de identificação. Se a ACL nunca foi programada, ou o pacote é descartado pelo componente HOST antes de chegar ao serviço, cada mecanismo parece idêntico por fora — silencioso, sem nada para mostrar.
SOLUÇÃOVerifique o campo Status das entradas ntid em display cpu-defend configuration all, depois o contador de cause-ID de microcódigo correspondente em display forward information no slot e chip relevantes. Se esse contador não estiver incrementando, é um problema de entrega abaixo do próprio serviço de identificação, que vale a pena escalar com uma captura de pacotes do lado HOST em vez de reconfigurar o recurso.
SINTOMAdisplay terminal-identify port-scan result ou deep-scan record mostra exatamente o que se esperaria ali no switch, mas a visão de terminais do controlador não mostra nada para aquele dispositivo.
CAUSAReportar os dados de impressão digital adiante é uma etapa separada de coletá-los — depende de uma assinatura telemetry com o sensor-path correto configurado para impressões digitais deep-scan e status de porta. Se essa assinatura nunca foi configurada, ou o endereço de destino está errado, o switch continua coletando dados perfeitamente bons que nunca ninguém recolhe.
SOLUÇÃOVerifique o contador telemetry-tx em display terminal-identify statistics. Se Total-num permanecer em 0 enquanto os comandos do lado do switch mostram dados reais, revise a configuração de sensor-group e destination-group na visão telemetry em vez da configuração terminal-identify em si.
Tiradas diretamente do campo — aquelas para as quais vale a pena ter uma resposta pronta.
Execute display terminal-identify probe result em qualquer visão — ele lista os resultados de reconhecimento ativo em cache, incluindo IP, MAC, categoria, fabricante e modelo, para cada terminal que o switch escaneou.
O endereço IP e o endereço MAC de um terminal, mais os atributos que realmente importam para a política: categoria do dispositivo, fabricante e modelo. Os resultados de impressão digital passiva são lidos da mesma forma via display terminal-identify feature, embora esse comando cubra apenas impressões DHCP, mDNS e HTTP — impressões digitais baseadas em LLDP são uma função separada do serviço LLDP, lida via display lldp neighbor.
De longe, o motivo mais comum é que o terminal simplesmente não está dentro do alcance de reconhecimento suportado — o reconhecimento ativo cobre apenas câmeras IP, telefones IP e impressoras, e o reconhecimento passivo cobre apenas PCs, telefones e tablets. Além disso, os terminais dentro do alcance suportado não respondem todos da mesma forma às sondagens, então se um método voltar vazio, vale a pena tentar varredura disparada online, periódica, imediata e de portas antes de concluir que o terminal é inalcançável.
A sondagem ativa envia uma sondagem leve e lê a resposta direta — a mais rápida, mas limitada às três categorias de dispositivos suportadas. A varredura profunda adiciona uma varredura completa de portas e análise de protocolo pelos serviços abertos do terminal para uma imagem mais completa. A coleta de fluxo profundo captura o tráfego real de cinco tuplas do terminal em vez de sondá-lo, o que funciona mesmo em terminais que nunca respondem a nada. A impressão digital passiva não envia nada — apenas lê campos DHCP, mDNS e HTTP do tráfego que o terminal já estava enviando, o que a torna a opção mais silenciosa, mas também a mais dependente de o terminal gerar esse tráfego em primeiro lugar.
Verifique primeiro display terminal-identify running-status. A impressão digital passiva, como a varredura profunda, é condicionada pela CPU — uma vez que a carga de CPU do próprio switch cruza cerca de 80%, o módulo passive reporta interrupted e pausa até a carga cair novamente abaixo de cerca de 70%. Este é um mecanismo de autoproteção, não uma falha de configuração, então a solução é encontrar o que está realmente sobrecarregando a CPU em vez de mexer na configuração terminal-identify.
Esta nota é construída em torno da orientação de localização de falhas do recurso terminal-identify e dos casos de campo do manual de manutenção dos switches de campus Huawei da série S — S1720, S5700, S6700, S6730, S7700 e modelos relacionados. Ela não cobre em profundidade a própria interface de perfilamento de terminais do controlador de campus gerenciado na nuvem, nem mecanismos de impressão digital de terminais de terceiros integrados por outros meios — apenas os mecanismos de varredura, coleta e impressão digital do lado do switch e os comandos na visão diagnose por trás deles.
Diga-nos qual mecanismo você tentou — sondagem ativa, varredura profunda, coleta de fluxo profundo ou impressão digital passiva — mais a saída de display terminal-identify statistics e running-status, e ajudaremos você a interpretá-la.