Activar el reconocimiento de aplicaciones — SAC clasificando el tráfico, ECA haciendo el análisis detrás — añade una tabla de flujo y un proceso en segundo plano a la ruta de cada paquete. Dos cosas fallan con suficiente frecuencia como para valer la pena conocerlas antes de desplegarlo: el tráfico de ruido llena silenciosamente la tabla de flujo antes de que sus informes siquiera empiecen, y el propio proceso ECA puede terminar fijado a un solo núcleo haciendo todo el trabajo de clasificación del switch.
Por Yuwen Zhang (Atlas), fundador de AtlasCommTech — 13 años de despliegues de redes de operadores y empresariales · Actualizado en julio de 2026
SAC clasifica, ECA analiza e informa — ambos casos a continuación se remontan a lo que ocurre una vez que ese pipeline está activo bajo tráfico real.
Activar SA (reconocimiento de tráfico) en una interfaz de entrada y desplegar análisis de aplicaciones SAC/ECA suena como una función de solo lectura — se supone que le dice qué hay en el cable, no que cambia cómo se comporta el cable. En la práctica, añade una tabla de flujo con un número fijo de entradas, y un proceso que debe clasificar cada nuevo flujo contra un conjunto grande de firmas. Ambos tienen una capacidad, y ambos aparecen en tickets cuando esa capacidad se usa en un lugar distinto al esperado.
Los dos casos de esta nota provienen de despliegues reales: un switch de campus cuyo panel de análisis de aplicaciones no reportaba casi nada útil porque la tabla de flujo estaba llena de DNS, y un switch que se volvió lento porque el proceso ECA que hacía el trabajo de clasificación estaba vinculado a un solo núcleo de CPU junto con otras tareas. Ambos tienen una ruta de diagnóstico clara y una solución específica.
Una falla reside en la tabla de flujo, la otra en la planificación de proceso/núcleo — comandos display distintos encuentran cada una.
Leer primero el síntoma frente a este árbol indica si está persiguiendo un problema de capacidad de tabla de flujo o uno de vinculación de CPU/proceso.
Las etiquetas del diagrama se mantienen en inglés por claridad técnica.
Ninguno de los dos indica que SAC/ECA en sí esté roto — ambos son comportamientos de capacidad y planificación que aparecen de forma predecible una vez que se sabe dónde buscar.
Ambos parten de un síntoma que un NOC realmente notaría — un panel de aplicaciones casi vacío, o un switch lento para responder — y terminan en una lectura específica de un contador o proceso.
La plataforma de análisis reporta un puñado de aplicaciones que a nadie le importan, y casi ninguna de las que el despliegue fue construido para rastrear.
[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 tableEl switch está lento, se disparan alarmas de memoria y CPU, y el culpable resulta ser el proceso que hace la clasificación de aplicaciones, vinculado a un solo núcleo junto con otras tareas del sistema.
<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 deviceDos casos de campo reales, y dos disciplinas operativas relacionadas que surgen directamente de ellos.
SÍNTOMAEl panel de análisis de aplicaciones reporta muy pocas de las aplicaciones realmente de interés, y en cambio mucho ruido de bajo valor.
CAUSALa tabla de flujo que respalda a SA/ECA tiene un número fijo de entradas — 16384 en el caso de esta nota. Un protocolo hablador y de bajo valor como DNS obtiene una entrada de tabla por sesión igual que cualquier otro, y con suficiente volumen de clientes detrás, puede ocupar la gran mayoría de la tabla con entradas que nadie pidió ver, hasta llegar e incluso superar una alarma de uso del 90% (15739 de 16384 usadas).
SOLUCIÓNConfigure una lista blanca ec-analytics que referencie una ACL que coincida con los protocolos y puertos de ruido, para que SA/ECA nunca gaste una entrada de tabla reconociéndolos.
acl number 3666
rule 15 permit udp source-port eq domain
rule 20 permit udp destination-port eq domain
ec-analytics whitelist acl 3666SÍNTOMAEl switch está lento, se disparan alarmas de memoria/CPU, y display system process muestra que una tarea ECA específica consume una gran parte de un núcleo.
CAUSALa afinidad proceso/núcleo colocó la tarea ECA en el mismo rango pequeño de núcleos que otras tareas del sistema ocupadas. El otro trabajo de ese núcleo compite con ECA por ciclos y reduce la capacidad de respuesta general, incluso cuando la utilización total multinúcleo parece poco destacable — verificar Cpus_allowed_list es lo que realmente revela esto, no el número agregado de CPU.
SOLUCIÓNConfirme la vinculación con shell-command slot pid-status. Si el despliegue no necesita realmente reconocimiento de aplicaciones o IPCA, undo defence engine enable elimina la carga directamente; de lo contrario, es un problema de afinidad de núcleo que vale la pena escalar con la evidencia ya recopilada.
[HUAWEI-diagnose] shell-command slot 0 pid-status 8650
Cpus_allowed_list: 0-1
[HUAWEI] undo defence engine enableSÍNTOMASe dispara una alarma de CPU o memoria — la pregunta que vale la pena hacer antes de escalar es si realmente está en curso.
CAUSAUn pico momentáneo — un reinicio, una ráfaga de recolección de información de módulos ópticos, una ráfaga de tráfico — normalmente no afecta el funcionamiento normal y se resuelve por sí solo. Una meseta sostenida durante minutos es el patrón que realmente vale la pena rastrear hasta una tarea o proceso específico.
SOLUCIÓNUse display cpu-usage history 1hour para ver la forma de la carga a lo largo del tiempo antes de decidir si están justificadas las verificaciones de display system process y afinidad de núcleo.
SÍNTOMAFaltan los nombres de aplicaciones esperados en la tabla aunque SA está habilitado en la interfaz y las firmas parecen correctas.
CAUSALa tabla de flujo se comparte entre todas las aplicaciones que SA reconoce, no está particionada por aplicación. Una vez saturada por otro tráfico, simplemente no queda espacio para la entrada de un nuevo flujo, sin importar cuán correctamente estén configuradas las aplicaciones que realmente le importan.
SOLUCIÓNLea las columnas AppName y Expire de display engine session application junto con cualquier alarma de uso de flujo del logbuffer — esa combinación distingue la falta de capacidad de tabla de un problema real de firma o configuración.
Extraídas directamente del campo — las que vale la pena tener una respuesta lista.
No necesariamente está roto. Primero revise la utilización de la tabla de flujo — display engine session application más la alarma app feature flow usage en el búfer de registros — antes de suponer un problema de configuración o licencia. Una tabla saturada se ve exactamente como si no se reconociera nada desde el lado de los informes, aunque SA esté clasificando correctamente el tráfico.
Ponga en lista blanca lo que realmente ha confirmado que nadie necesita ver — DNS, SSDP y Kerberos fueron los culpables específicos en el caso de esta nota. Una lista blanca demasiado amplia puede excluir silenciosamente algo que sí quiera ver más adelante, así que ajústela al tráfico real que ha revisado con quien administra el despliegue, no a una lista genérica copiada de otro lado.
Solo si es sostenido y realmente se correlaciona con la lentitud. Verifique primero display cpu-usage history 1hour para ver si es una meseta mantenida durante minutos en lugar de un pico momentáneo por un reinicio, un ciclo de recolección de información de módulos ópticos, o una ráfaga de tráfico — esto último suele ser inofensivo y se resuelve solo.
Si el despliegue no necesita realmente reconocimiento de aplicaciones, IPCA o los análisis relacionados, undo defence engine enable elimina la carga por completo. Si los análisis realmente se requieren, este es un problema de afinidad de núcleo y planificación que vale la pena escalar con la evidencia de proceso y pid-status ya recopilada, en lugar de seguir autodiagnosticando.
Sí — son límites de capacidad independientes (entradas de tabla versus planificación de núcleo) que se esconden ambos detrás de la misma función SAC/ECA. Un switch de borde de campus ocupado, con mucho tráfico de DNS y reconocimiento de aplicaciones habilitados, es exactamente el perfil donde vería ambos a la vez.
Esta nota se basa en la función de reconocimiento de aplicaciones SAC/ECA de los switches de campus serie S5731/S5732/S6730 (y eKitEngine comparables) — el comportamiento de capacidad de tabla de flujo detrás de display engine session application, y el comportamiento de vinculación proceso/núcleo detrás de display system process y shell-command pid-status — además de los dos casos de campo detrás de ellos. Los tamaños exactos de tabla de flujo y los nombres de proceso pueden diferir según el modelo y la versión, así que confirme ambos en su propio hardware en lugar de suponer que el mismo límite de 16384 entradas o el mismo nombre de proceso ECA se aplica en todas partes. No cubre en profundidad los requisitos de licencia de SAC/ECA ni la configuración de exportación de NetStream/telemetría.
Envíenos display engine session application, la alarma de logbuffer si la hay, y display system process, y le ayudamos a distinguir un problema de tabla de flujo de uno de vinculación de núcleo.