Activer la reconnaissance d'applications — SAC classant le trafic, ECA effectuant l'analyse derrière — ajoute une table de flux et un processus en arrière-plan sur le chemin de chaque paquet. Deux choses se produisent assez souvent pour valoir d'être connues avant le déploiement : un trafic de bruit remplit discrètement la table de flux avant même que vos rapports ne démarrent, et le processus ECA lui-même peut se retrouver épinglé sur un seul cœur pour tout le travail de classification du commutateur.
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
SAC classe, ECA analyse et rapporte — les deux cas ci-dessous remontent à ce qui se passe une fois ce pipeline actif sous un trafic réel.
Activer la SA (reconnaissance de trafic) sur une interface d'entrée et déployer les analyses d'applications SAC/ECA ressemble à une fonctionnalité en lecture seule — elle est censée vous dire ce qui circule sur le fil, pas changer son comportement. En pratique, cela ajoute une table de flux avec un nombre fixe d'entrées, et un processus qui doit classer chaque nouveau flux contre un vaste ensemble de signatures. Ces deux éléments ont une capacité, et les deux se retrouvent dans des tickets lorsque cette capacité est utilisée ailleurs que prévu.
Les deux cas de cette note proviennent de déploiements réels : un commutateur de campus dont le tableau de bord d'analyse d'applications ne rapportait presque rien d'utile parce que la table de flux était pleine de DNS, et un commutateur devenu lent parce que le processus ECA effectuant le travail de classification était lié à un seul cœur CPU aux côtés d'autres tâches. Les deux ont un chemin de diagnostic clair et une solution précise.
Une défaillance se situe dans la table de flux, l'autre dans l'ordonnancement processus/cœur — des commandes display différentes permettent de trouver chacune.
Lire d'abord le symptôme face à cet arbre indique si vous poursuivez un problème de capacité de table de flux ou un problème de liaison CPU/processus.
Les légendes du schéma restent en anglais pour la clarté technique.
Aucun des deux n'indique que SAC/ECA lui-même est défaillant — ce sont des comportements de capacité et d'ordonnancement qui apparaissent de façon prévisible une fois qu'on sait où chercher.
Les deux partent d'un symptôme qu'un NOC remarquerait réellement — un tableau de bord d'applications presque vide, ou un commutateur lent à répondre — et se terminent par une lecture précise d'un compteur ou d'un processus.
La plateforme d'analyse rapporte une poignée d'applications dont personne ne se soucie, et presque aucune de celles que le déploiement devait suivre.
[SwitchA] display engine session application
Source IP Destination IP SPort DPort ProtocolID AppName AppID Expire(S)
----------------------------------------------------------------------------------------------
10.10.20.6 10.10.10.2 53 65112 17 DNS 431 285
10.10.20.5 10.10.10.2 53 64856 17 DNS 431 285
10.10.20.4 10.10.10.2 53 64686 17 DNS 431 285
10.10.20.3 10.10.10.2 53 62290 17 DNS 431 285
// page after page of DNS entries -- almost no room left for the applications actually of interest
[SwitchA] display logbuffer
Jun 7 2025 12:20:04 6730s-10003 SECE/4/ENGINE_APP_FEATURE:OID 1.3.6.1.4.1.2011.5.25.165.2.2.20.1 The
app feature flow usage exceeds the threshold. (Slot=0, TotalNum=16384, UsedNum=15739, Threshold=90)
// 15739 of 16384 table entries used -- the table, not the config, is the bottleneck
acl number 3666
rule 5 permit tcp source-port eq 88
rule 10 permit tcp destination-port eq 88
rule 15 permit udp source-port eq domain
rule 20 permit udp destination-port eq domain
ec-analytics whitelist acl 3666
// with the whitelist applied, the applications actually of interest start showing up in the tableLe commutateur est lent, des alarmes mémoire et CPU se déclenchent, et le coupable s'avère être le processus effectuant la classification d'applications, lié à un seul cœur aux côtés d'autres tâches système.
<HUAWEI> display cpu-usage history 1hour
100%|
95%|HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
// a long, sustained plateau, not a single spike -- worth investigating further
<HUAWEI> display cpu-usage
CPU Usage : 98% Max: 98%
TaskName CPU Task Explanation
OS 98% Operation System
[HUAWEI] diagnose
[HUAWEI-diagnose] display system process
No Name Pid Status MEM CPUOfOneCore CPUOfAllCores
14 ECA 8650 Active 3% 43% 10%
// the ECA task alone is using 43% of one core
[HUAWEI-diagnose] shell-command slot 0 top-thread 8650
8662 normal 20 0 317296 135692 18364 R 18.2 3.9 0:42.62 ECA
8657 normal 20 0 317296 135692 18364 S 9.1 3.9 0:11.05 SARS
// spread across several threads inside the same process -- not one runaway thread
[HUAWEI-diagnose] shell-command slot 0 pid-status 8650
Cpus_allowed: 3
Cpus_allowed_list: 0-1
// ECA is bound to cores 0-1 alongside other tasks -- contention on those cores pins overall CPU
[HUAWEI] undo defence engine enable
// if app recognition / ECA / IPCA isn't actually required on this deviceDeux cas de terrain réels, et deux disciplines d'exploitation connexes qui en découlent directement.
SYMPTÔMELe tableau de bord d'analyse d'applications rapporte très peu des applications réellement d'intérêt, et beaucoup de bruit à faible valeur à la place.
CAUSELa table de flux soutenant SA/ECA a un nombre fixe d'entrées — 16384 dans le cas de cette note. Un protocole bavard et à faible valeur comme le DNS obtient une entrée de table par session comme n'importe quel autre, et avec suffisamment de volume client derrière, il peut occuper la grande majorité de la table avec des entrées que personne n'a demandé à voir, jusqu'à et au-delà d'une alarme d'utilisation à 90% (15739 sur 16384 utilisées).
SOLUTIONConfigurez une liste blanche ec-analytics référençant une ACL correspondant aux protocoles et ports de bruit, afin que SA/ECA ne dépense jamais d'entrée de table à les reconnaître.
acl number 3666
rule 15 permit udp source-port eq domain
rule 20 permit udp destination-port eq domain
ec-analytics whitelist acl 3666SYMPTÔMELe commutateur est lent, des alarmes mémoire/CPU se déclenchent, et display system process montre une tâche ECA spécifique consommant une large part d'un cœur.
CAUSEL'affinité processus/cœur a placé la tâche ECA sur la même petite plage de cœurs que d'autres tâches système chargées. Le reste du travail de ce cœur entre en concurrence avec ECA pour les cycles et fait baisser la réactivité globale, même lorsque l'utilisation multi-cœur totale paraît anodine — c'est la vérification de Cpus_allowed_list qui révèle réellement cela, pas le chiffre CPU agrégé.
SOLUTIONConfirmez la liaison avec shell-command slot pid-status. Si le déploiement n'a pas réellement besoin de la reconnaissance d'applications ou d'IPCA, undo defence engine enable supprime la charge directement ; sinon, il s'agit d'un problème d'affinité de cœur à escalader avec les preuves déjà collectées.
[HUAWEI-diagnose] shell-command slot 0 pid-status 8650
Cpus_allowed_list: 0-1
[HUAWEI] undo defence engine enableSYMPTÔMEUne alarme CPU ou mémoire se déclenche — la question à se poser avant d'escalader est de savoir si c'est réellement en cours.
CAUSEUn pic momentané — un redémarrage, une rafale de collecte d'informations sur les modules optiques, une rafale de trafic — n'affecte généralement pas le fonctionnement normal et se résorbe de lui-même. Un plateau soutenu sur plusieurs minutes est le schéma qui mérite réellement d'être poursuivi jusqu'à une tâche ou un processus précis.
SOLUTIONUtilisez display cpu-usage history 1hour pour voir la forme de la charge dans le temps avant de décider si des vérifications display system process et d'affinité de cœur sont justifiées.
SYMPTÔMELes noms d'applications attendus sont absents de la table même si la SA est activée sur l'interface et que les signatures semblent correctes.
CAUSELa table de flux est partagée entre toutes les applications que la SA reconnaît, pas partitionnée par application. Une fois saturée par un autre trafic, il ne reste tout simplement plus de place pour l'entrée d'un nouveau flux, quelle que soit la justesse de la configuration des applications qui vous intéressent réellement.
SOLUTIONLisez les colonnes AppName et Expire de display engine session application avec toute alarme d'utilisation de flux du logbuffer — cette combinaison distingue la famine de capacité de table d'un véritable problème de signature ou de configuration.
Tirées directement du terrain — celles pour lesquelles il vaut la peine d'avoir une réponse prête.
Pas nécessairement en panne. Vérifiez d'abord l'utilisation de la table de flux — display engine session application plus l'alarme app feature flow usage dans le tampon de journal — avant de supposer un problème de configuration ou de licence. Une table saturée ressemble exactement à rien de reconnu du côté rapport, même si la SA classe correctement le trafic.
Mettez en liste blanche ce dont vous avez réellement confirmé que personne n'a besoin de visibilité — DNS, SSDP et Kerberos étaient les coupables spécifiques dans le cas de cette note. Une liste blanche trop large peut discrètement exclure quelque chose dont vous voudrez de la visibilité plus tard, alignez-la donc sur le trafic réel examiné avec le responsable du déploiement, pas une liste générique copiée d'ailleurs.
Seulement si c'est soutenu et corrèle réellement avec la lenteur. Vérifiez d'abord display cpu-usage history 1hour pour voir s'il s'agit d'un plateau maintenu sur plusieurs minutes plutôt que d'un pic momentané dû à un redémarrage, un cycle de collecte d'informations sur les modules optiques, ou une rafale de trafic — ce dernier est généralement inoffensif et se résorbe de lui-même.
Si le déploiement n'a pas réellement besoin de la reconnaissance d'applications, d'IPCA ou des analyses associées, undo defence engine enable supprime entièrement la charge. Si les analyses sont réellement requises, il s'agit d'un problème d'affinité de cœur et d'ordonnancement à escalader avec les preuves de processus et de pid-status déjà collectées, plutôt que de continuer à se diagnostiquer soi-même.
Oui — ce sont des limites de capacité indépendantes (entrées de table versus ordonnancement de cœur) qui se cachent toutes deux derrière la même fonctionnalité SAC/ECA. Un commutateur de périphérie de campus chargé, avec beaucoup de bavardage DNS et la reconnaissance d'applications toutes deux activées, est exactement le profil où l'on verrait les deux à la fois.
Cette note s'appuie sur la fonctionnalité de reconnaissance d'applications SAC/ECA des commutateurs de campus série S5731/S5732/S6730 (et des eKitEngine comparables) — le comportement de capacité de table de flux derrière display engine session application, et le comportement de liaison processus/cœur derrière display system process et shell-command pid-status — ainsi que les deux cas de terrain qui les sous-tendent. Les tailles exactes de table de flux et les noms de processus peuvent différer selon le modèle et la version, confirmez donc les deux sur votre propre matériel plutôt que de supposer que le même plafond de 16384 entrées ou le même nom de processus ECA s'applique partout. Elle ne couvre pas en profondeur les prérequis de licence SAC/ECA ni la configuration d'export NetStream/télémétrie.
Envoyez-nous display engine session application, l'alarme logbuffer s'il y en a une, et display system process, et nous vous aiderons à distinguer un problème de table de flux d'un problème de liaison de cœur.