Un hub non autorisé, un routeur non autorisé, ou quelqu'un qui partage le Wi-Fi de son téléphone depuis une prise murale — chacun de ces cas devrait déclencher une alerte sur un commutateur d'accès correctement configuré, et la plupart du temps ce n'est pas le cas parce qu'un élément précis de la chaîne de détection manque. Voici la logique de détection derrière chacun des trois types de connexion non autorisée, les commandes exactes en vue diagnose à exécuter, et les cinq raisons pour lesquelles la détection revient vide même quand l'appareil non autorisé est bel et bien là.
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
Un hub se trahit par la répétition, un routeur ou un point d'accès partagé se trahit par la contradiction — traiter les trois comme un seul problème de détection est la raison pour laquelle tant de ces tickets s'enlisent.
La détection de connexion non autorisée de Huawei couvre trois appareils non autorisés distincts derrière un seul port d'accès : un hub non autorisé, partageant un port entre plusieurs adresses MAC ; un routeur non autorisé, traduisant une adresse légitime en plusieurs appareils derrière lui ; et le partage Wi-Fi, un téléphone ou un ordinateur portable reliant son propre point d'accès au réseau filaire. Chacun des trois est sa propre fonction — détection unauthorized-hub, unauthorized-router et wi-fi-sharing — avec son propre mécanisme de détection, et sa propre raison de revenir vide même quand l'appareil non autorisé est réellement présent.
Voici la logique de détection derrière chaque type, l'arbre de panne pour placer un symptôme d'« absence de résultat » sur la bonne branche, les commandes en vue diagnose pour chaque étape, les cinq causes profondes qui expliquent la plupart de ces tickets, et cinq réponses de FAQ tirées de cas de terrain réels. Confirmer qu'un appareil atteint même le pipeline d'identification du commutateur est une question connexe mais distincte — voir terminal-identification-troubleshooting.html si le port lui-même semble ne rien signaler du tout.
Avant d'exécuter la moindre commande, déterminez laquelle des trois questions vous posez réellement — le schéma ci-dessous est le moyen le plus rapide d'y parvenir.
unauthorized-hub demande si la même adresse MAC continue de réapparaître derrière un port ; unauthorized-router et wi-fi-sharing demandent si le trafic d'un port contient des empreintes d'appareils contradictoires ; la sonde active ARP pose une question de confirmation plus étroite, une fois qu'un hub est déjà suspecté.
Les légendes du schéma restent en anglais pour la clarté technique.
Aucun des trois types de détection ne doit être activé ensemble — chacun est activé indépendamment avec sa propre commande uap enable uap-type, et une « absence de résultat » sur l'un ne dit rien sur l'état des deux autres.
Trois types de détection, trois commandes différentes à lire en premier — et la vérification du chemin de remontée qui s'applique à tous.
unauthorized-hub, unauthorized-router et wi-fi-sharing sont des fonctions indépendantes — confirmez que les trois sont réellement activées avant de supposer que l'une d'elles est en panne.
[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 twoUn hub n'est signalé qu'une fois que la même adresse MAC apparaît deux fois derrière le même port — une seule apparition ne prouve rien.
<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 questionCe n'est pas une correspondance de signature — c'est une vérification logique portant sur deux choses qui ne devraient pas être vraies simultanément derrière le même port.
[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 aboveCette sonde ne s'exécute que sur les terminaux qui se sont connectés après l'activation d'arp snooping — et elle ne compte comme un hub que selon un ratio précis, pas simplement n'importe quelle réponse supplémentaire.
[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 allUne fois que les vérifications 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 uap detection-results revient vide pour un type d'appareil que vous pouvez voir branché juste devant vous.
CAUSEunauthorized-hub, unauthorized-router et wi-fi-sharing sont trois fonctions indépendantes, chacune activée par sa propre commande uap enable uap-type. Activer l'une ne dit rien sur l'état des deux autres, et il est facile de supposer que les trois sont activées parce que l'une d'elles l'est clairement.
SOLUTIONConfirmez que les trois types sont réellement activés avec display current-configuration avant de poursuivre le dépannage — ne supposez pas que la détection est en panne alors qu'elle n'a simplement jamais été activée pour ce type d'appareil spécifique.
SYMPTÔMEdisplay uap arp-detection montre un Recv-Count non nul, mais Is-HubUa affiche toujours false.
CAUSELa sonde ARP ne classe un port comme hub qu'une fois que Recv-Count atteint au moins le double de Send-Count sur un cycle de détection. Une seule réponse légitime par sonde — le cas normal, sans hub — ne franchit jamais ce ratio, quel que soit le nombre de cycles exécutés.
SOLUTIONLisez Recv-Count par rapport à Send-Count comme un ratio, pas comme une simple vérification de présence oui/non — un schéma de 1:1 ou 2:2 est exactement à quoi ressemble un seul appareil honnête derrière le port.
SYMPTÔMEUn hub présent derrière un port depuis des semaines n'apparaît jamais dans display uap arp-detection, alors qu'un nouveau connecté aujourd'hui est repéré presque immédiatement.
CAUSELa sonde active ARP est déclenchée par arp snooping, et seuls les terminaux connectés après l'activation d'arp snooping sont enregistrés pour être sondés. Un appareil déjà en fonctionnement avant l'activation de la fonction est invisible pour cette vérification spécifique, même si le hub lui-même n'a absolument pas changé.
SOLUTIONVérifiez display arp snooping all pour l'entrée du terminal avant de supposer que la sonde devrait le détecter. Si elle est absente, le terminal s'est connecté trop tôt pour cette fonction — un flap de port, ou une nouvelle vérification planifiée, le ramène dans le périmètre.
SYMPTÔMEdisplay uap profiling mac montre un TTL qui semble un peu inhabituel, mais le port n'est jamais signalé comme routeur non autorisé ou point d'accès partagé.
CAUSELa logique n'est pas de savoir si un TTL semble faux — c'est spécifiquement deux valeurs de TTL différentes derrière le même port, ou une valeur se répétant à un nombre illégal, 63 ou 127. Un TTL unique et cohérent en interne, même inhabituel, décrit un seul appareil derrière ce port, exactement le cas que la détection est conçue pour laisser tranquille.
SOLUTIONLisez le champ TTL en cherchant la variété, pas l'anomalie. Si chaque paquet provenant de ce port montre le même TTL, ce n'est pas une détection partielle — c'est le mécanisme qui décide correctement qu'il n'y a rien à signaler.
SYMPTÔMEToutes les commandes de profilage et de sonde ci-dessus renvoient vide ou zéro, pour tous les types de détection, sur un port dont vous êtes certain qu'il a du trafic.
CAUSELa détection unauthorized-hub, unauthorized-router et wi-fi-sharing dépend toutes du même chemin de livraison sous-jacent — une ACL programmée dans le matériel, et une entrée de microcode qui achemine réellement le paquet correspondant jusqu'au service UAP. Lorsque ce chemin se rompt, généralement une ACL qui n'a pas été programmée, chaque type de détection paraît identique de l'extérieur — silencieux, sans rien à montrer, quel que soit ce qui est réellement branché.
SOLUTIONVérifiez Total Passed dans display cpu-defend statistics packet-type ntid-http all, et les compteurs NTID cause-ID correspondants sous display forward information. Si aucun d'eux n'augmente, il s'agit d'un problème de livraison sous la détection elle-même, qui mérite une capture de débogage côté HOST et une escalade plutôt que davantage de commandes de profilage.
Tirées directement du terrain — celles pour lesquelles il vaut la peine d'avoir une réponse prête.
Exécutez display uap detection-results dans n'importe quelle vue. Elle liste chaque interface signalée, adresse MAC, adresse IP, le type précis non autorisé — hub, routeur, ou partage Wi-Fi — et quand il a été détecté.
display uap profiling mac montre les preuves réelles : le champ TTL indique s'il s'agit d'une répétition pure de type hub, tandis que les colonnes Dns-feature, Http-feature et Tcp-feature montrent quelles empreintes de système d'exploitation ont été observées — deux signatures d'OS différentes, ou deux versions d'une même, derrière le même port pointent vers un routeur ou un point d'accès partagé plutôt qu'un simple hub.
Elles sont totalement indépendantes — activez uniquement unauthorized-hub, uniquement unauthorized-router, uniquement wi-fi-sharing, ou toute combinaison, avec des commandes uap enable uap-type séparées. Il n'y a aucune dépendance entre elles, et aucun seuil partagé qui change selon celles qui sont activées.
Confirmez d'abord que la même adresse MAC s'est réellement répétée derrière ce port — une seule apparition ne suffit pas. Si elle s'est répétée et que la détection est toujours vide, vérifiez si les commandes de profilage et de cache de fonctionnalité montrent des données pour ce port ; si les deux sont également vides, le problème se situe généralement entièrement en dessous de la détection, dans le fait que les paquets concernés atteignent ou non le service en premier lieu.
Le profilage est passif — il lit ce que le trafic normal d'un appareil révèle déjà à son sujet : TTL, et empreintes d'OS issues de DNS, HTTP et TCP. La sonde ARP est active — le commutateur envoie délibérément des requêtes ARP et compte combien de réponses reviennent, ce qui est précisément la façon dont un hub suspecté est confirmé, puisqu'un hub fait qu'une seule sonde atteint plusieurs appareils réels et génère plus de réponses qu'un seul appareil ne le ferait jamais.
Cette note s'appuie sur les indications de localisation des pannes de la détection de connexion non autorisée 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 couvre la logique de détection propre au commutateur et les commandes en vue diagnose ; elle ne couvre pas l'alerte côté contrôleur de campus géré dans le cloud ni la politique automatisée de désactivation de port, et n'aborde pas la détection de point d'accès non autorisé côté sans fil, qui est une fonction WLAN distincte avec son propre mécanisme de détection.
Dites-nous quel type vous traquez — hub, routeur, ou partage Wi-Fi — plus la sortie de display uap profiling et display uap detection-results, et nous vous aiderons à l'interpréter.