Um hub não autorizado, um roteador não autorizado, ou alguém compartilhando o Wi-Fi do celular por uma tomada de parede — cada um desses deveria disparar um alerta em um switch de acesso corretamente configurado, e na maioria das vezes isso não acontece porque falta uma peça específica na cadeia de detecção. Esta é a lógica de detecção por trás de cada um dos três tipos de conexão não autorizada, os comandos exatos na visão diagnose a executar, e as cinco razões pelas quais a detecção volta vazia mesmo quando o dispositivo não autorizado está bem ali.
Por Yuwen Zhang (Atlas), fundador da AtlasCommTech — 13 anos de implantações de redes de operadoras e empresariais · Atualizado em julho de 2026
Um hub se entrega por repetição, um roteador ou hotspot compartilhado se entrega por contradição — tratar os três como um único problema de detecção é o motivo pelo qual tantos desses chamados travam.
A detecção de conexão não autorizada da Huawei cobre três dispositivos não autorizados distintos atrás de uma única porta de acesso: um hub não autorizado, compartilhando uma porta entre vários endereços MAC; um roteador não autorizado, traduzindo um endereço legítimo em vários dispositivos atrás dele; e o compartilhamento de Wi-Fi, um telefone ou laptop conectando seu próprio hotspot à rede com fio. Cada um dos três é seu próprio recurso — detecção unauthorized-hub, unauthorized-router e wi-fi-sharing — com seu próprio mecanismo de detecção, e sua própria razão para voltar vazio mesmo quando o dispositivo não autorizado realmente está lá.
A seguir está a lógica de detecção por trás de cada tipo, a árvore de falhas para colocar um sintoma de «sem resultado» no ramo certo, os comandos na visão diagnose para cada etapa, as cinco causas-raiz que explicam a maioria desses chamados, e cinco respostas de perguntas frequentes tiradas de casos reais de campo. Confirmar se um dispositivo sequer chega ao pipeline de identificação do switch é uma questão relacionada, mas separada — veja terminal-identification-troubleshooting.html se a própria porta parecer não relatar nada.
Antes de executar um único comando, decida qual das três perguntas você está realmente fazendo — o diagrama abaixo é a forma mais rápida de fazer isso.
unauthorized-hub pergunta se o mesmo MAC continua reaparecendo atrás de uma porta; unauthorized-router e wi-fi-sharing perguntam se o tráfego de uma porta contém impressões digitais de dispositivo contraditórias; a sondagem ativa ARP faz uma pergunta de confirmação mais restrita, uma vez que um hub já é suspeito.
Os rótulos do diagrama permanecem em inglês para clareza técnica.
Nenhum dos três tipos de detecção precisa ser habilitado junto — cada um é ativado independentemente com seu próprio comando uap enable uap-type, e um «sem resultado» em um não diz nada sobre o estado dos outros dois.
Três tipos de detecção, três comandos diferentes para ler primeiro — e a verificação do caminho de relato que se aplica a todos eles.
unauthorized-hub, unauthorized-router e wi-fi-sharing são recursos independentes — confirme que os três estão realmente ativados antes de presumir que algum deles está quebrado.
[HUAWEI] uap enable uap-type unauthorized-hub
[HUAWEI] uap enable uap-type unauthorized-router
[HUAWEI] uap enable uap-type wi-fi-sharing
// each type is independent -- enabling one says nothing about the other twoUm hub só é sinalizado depois que o mesmo endereço MAC aparece duas vezes atrás da mesma porta — uma única aparição não prova nada.
<HUAWEI> diagnose
[HUAWEI-diagnose] display uap profiling interface
Interface Ip-address MAC Vlan Online-time
10GE1/0/1 192.168.137.3 607d-095a-ee83 4094 2024-01-25T06:29:59+00:00
// same MAC repeating on the same interface is what actually gets a port flagged
[HUAWEI-diagnose] display cpu-defend statistics packet-type ntid-http all
PacketType Total Passed Total Dropped
ntid-http 658 0
// Total Passed = 0 means the switch never received a reply packet at all
[HUAWEI-diagnose] debugging host packet 0a010101 slot 1 number 10
// capture by source-IP hex if the report path itself is in questionIsso não é uma correspondência de assinatura — é uma verificação lógica de duas coisas que não deveriam ser verdadeiras ao mesmo tempo atrás da mesma porta.
[HUAWEI-diagnose] display uap profiling mac
MAC Ip-address Interface TTL Dns-feature Http-feature Tcp-feature
fe51-6735-3c5f 192.168.137.130 10GE1/0/1 64/0_1_0 - - ios
0055-c055-0102 2.2.2.205 10GE1/0/1 64/63/1_1_0 - Windows6.1 -
// two different TTLs, or an illegal repeat like 63, is what actually flags a port here
[HUAWEI-diagnose] display uap feature
Interface MAC Type Value
10GE1/0/1 0055-c055-0102 UAP_HTTP_UA 0,64,2.2.2.205,Mozilla/5.0 (Windows; U; Windows NT 6.1...)
// thin traffic in this table produces a thin, inconclusive profile aboveEssa sondagem só é executada contra terminais que ficaram online depois que o arp snooping foi habilitado — e só conta como hub em uma proporção específica, não com qualquer resposta extra.
[HUAWEI-diagnose] display arp snooping all
VLAN/CEVLAN IP ADDRESS MAC ADDRESS INTERFACE EXPIRE(S)
1/0 10.2.0.167 4ce1-7345-1fe5 GE1/0/7 866
// only terminals listed here were even eligible for the ARP probe
[HUAWEI-diagnose] display uap arp-detection
Interface Vlan IP-Address MAC-Address Send-Count Recv-Count Is-HubUa
GE1/0/7 1 10.2.0.167 4ce1-7345-1fe5 2 4 true
GE1/0/8 1 10.2.0.168 4ce1-7345-1fe6 2 0 false
// Is-HubUa only reads true once Recv-Count is at least 2x Send-Count
[HUAWEI] display cpu-defend statistics packet-type arp-reply all
PacketType Total Passed Total Dropped
arp-reply 1427 2
// Total Passed = 0 means no ARP replies are being received from that port at allDepois que as verificações acima indicarem onde está o problema, essas cinco causas explicam a maior parte do que realmente está errado.
SINTOMAdisplay uap detection-results volta vazio para um tipo de dispositivo que você pode ver conectado bem na sua frente.
CAUSAunauthorized-hub, unauthorized-router e wi-fi-sharing são três recursos independentes, cada um ativado com seu próprio comando uap enable uap-type. Habilitar um não diz nada sobre o estado dos outros dois, e é fácil presumir que os três estão ativados porque um deles claramente está.
SOLUÇÃOConfirme que os três tipos estão realmente habilitados com display current-configuration antes de continuar a solução de problemas — não presuma que a detecção está quebrada quando ela simplesmente nunca foi ativada para aquele tipo de dispositivo específico.
SINTOMAdisplay uap arp-detection mostra um Recv-Count diferente de zero, mas Is-HubUa ainda mostra false.
CAUSAA sondagem ARP só classifica uma porta como hub quando Recv-Count atinge pelo menos o dobro de Send-Count dentro de um ciclo de detecção. Uma única resposta legítima por sondagem — o caso normal, sem hub — nunca cruza essa proporção, não importa quantos ciclos rodem.
SOLUÇÃOLeia Recv-Count contra Send-Count como uma proporção, não como uma verificação de presença sim/não — um padrão de 1:1 ou 2:2 é exatamente como um único dispositivo honesto atrás da porta se parece.
SINTOMAUm hub que está atrás de uma porta há semanas nunca aparece em display uap arp-detection, enquanto um novo conectado hoje é pego quase imediatamente.
CAUSAA sondagem ativa ARP é disparada pelo arp snooping, e apenas os terminais que ficaram online depois que o arp snooping foi habilitado são registrados para sondagem. Um dispositivo que já estava em funcionamento antes de o recurso ser ativado é invisível para essa verificação específica, mesmo que o próprio hub não tenha mudado em nada.
SOLUÇÃOVerifique display arp snooping all para a entrada do terminal antes de presumir que a sondagem deveria detectá-lo. Se estiver faltando, o terminal ficou online cedo demais para esse recurso — uma oscilação de porta, ou uma nova verificação programada, o traz de volta ao escopo.
SINTOMAdisplay uap profiling mac mostra um TTL que parece um pouco incomum, mas a porta nunca é sinalizada como roteador não autorizado ou hotspot compartilhado.
CAUSAA lógica não é se um TTL parece errado — é especificamente dois valores de TTL diferentes atrás da mesma porta, ou um valor se repetindo em um número ilegal, 63 ou 127. Um único TTL internamente consistente, mesmo que incomum, descreve um dispositivo atrás daquela porta, exatamente o caso que a detecção foi projetada para deixar em paz.
SOLUÇÃOLeia o campo TTL buscando variedade, não estranheza. Se cada pacote daquela porta mostrar o mesmo TTL, isso não é uma detecção parcial — é o mecanismo decidindo corretamente que não há nada a sinalizar.
SINTOMATodos os comandos de perfilamento e sondagem acima retornam vazio ou zero, em todos os tipos de detecção, em uma porta que você tem certeza de que tem tráfego.
CAUSAA detecção unauthorized-hub, unauthorized-router e wi-fi-sharing depende toda do mesmo caminho de entrega subjacente — uma ACL programada no hardware, e uma entrada de microcódigo que realmente encaminha o pacote correspondente até o serviço UAP. Quando esse caminho quebra, comumente uma ACL que falhou ao programar, cada tipo de detecção parece idêntico por fora — silencioso, sem nada para mostrar, independentemente do que realmente está conectado.
SOLUÇÃOVerifique Total Passed em display cpu-defend statistics packet-type ntid-http all, e os contadores NTID cause-ID correspondentes em display forward information. Se nenhum deles estiver incrementando, é um problema de entrega abaixo da própria detecção, que vale a pena uma captura de depuração do lado HOST e escalonamento em vez de mais comandos de perfilamento.
Tiradas diretamente do campo — aquelas para as quais vale a pena ter uma resposta pronta.
Execute display uap detection-results em qualquer visão. Ele lista cada interface sinalizada, MAC, endereço IP, o tipo específico não autorizado — hub, roteador, ou compartilhamento de Wi-Fi — e quando foi detectado.
display uap profiling mac mostra a evidência real: o campo TTL indica se é uma repetição pura do tipo hub, enquanto as colunas Dns-feature, Http-feature e Tcp-feature mostram quais impressões digitais de sistema operacional foram vistas — duas assinaturas de SO diferentes, ou duas versões de uma, atrás da mesma porta apontam para um roteador ou hotspot compartilhado em vez de um hub simples.
Elas são totalmente independentes — habilite apenas unauthorized-hub, apenas unauthorized-router, apenas wi-fi-sharing, ou qualquer combinação, com comandos uap enable uap-type separados. Não há dependência entre elas, nem um limite compartilhado que muda com base em quais outras estão ativadas.
Confirme primeiro que o mesmo MAC realmente se repetiu atrás dessa porta — uma única aparição não é suficiente. Se ele se repetiu e a detecção ainda está vazia, verifique se os comandos de perfilamento e cache de recursos mostram algum dado para essa porta; se ambos também estiverem vazios, o problema geralmente está totalmente abaixo da detecção, em saber se os pacotes relevantes estão chegando ao serviço em primeiro lugar.
O perfilamento é passivo — ele lê o que o tráfego normal de um dispositivo já revela sobre ele: TTL, e impressões digitais de SO de DNS, HTTP e TCP. A sondagem ARP é ativa — o switch envia deliberadamente solicitações ARP e conta quantas respostas retornam, que é especificamente como um hub suspeito é confirmado, já que um hub faz com que uma sondagem alcance vários dispositivos reais e gere mais respostas do que um único dispositivo jamais geraria.
Esta nota é construída em torno da orientação de localização de falhas da detecção de conexão não autorizada 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 cobre a lógica de detecção própria do switch e os comandos na visão diagnose; não cobre o alerta do lado do controlador de campus gerenciado na nuvem nem a política automatizada de desabilitação de porta, e não aborda a detecção de AP não autorizado do lado sem fio, que é um recurso WLAN separado com seu próprio mecanismo de detecção.
Diga-nos qual tipo você está rastreando — hub, roteador, ou compartilhamento de Wi-Fi — mais a saída de display uap profiling e display uap detection-results, e ajudaremos você a interpretá-la.