Ativar o reconhecimento de aplicações — SAC classificando o tráfego, ECA fazendo a análise por trás — adiciona uma tabela de fluxo e um processo em segundo plano ao caminho de cada pacote. Duas coisas dão errado com frequência suficiente para valer a pena conhecer antes de implantar: o tráfego de ruído preenche silenciosamente a tabela de fluxo antes mesmo de seus relatórios começarem, e o próprio processo ECA pode acabar fixado em um único núcleo fazendo todo o trabalho de classificação do switch.
Por Yuwen Zhang (Atlas), fundador da AtlasCommTech — 13 anos de implantações de redes de operadoras e empresariais · Atualizado em julho de 2026
O SAC classifica, o ECA analisa e reporta — os dois casos abaixo remontam ao que acontece quando esse pipeline entra em operação sob tráfego real.
Ativar o SA (reconhecimento de tráfego) em uma interface de entrada e implantar análises de aplicações SAC/ECA parece uma funcionalidade somente leitura — deveria apenas dizer o que está no fio, não mudar como o fio se comporta. Na prática, isso adiciona uma tabela de fluxo com um número fixo de entradas, e um processo que precisa classificar cada novo fluxo contra um grande conjunto de assinaturas. Ambos têm uma capacidade, e ambos aparecem em chamados quando essa capacidade é usada em outro lugar diferente do esperado.
Os dois casos desta nota vêm de implantações reais: um switch de campus cujo painel de análise de aplicações relatava quase nada útil porque a tabela de fluxo estava cheia de DNS, e um switch que ficou lento porque o processo ECA que fazia o trabalho de classificação estava vinculado a um único núcleo de CPU junto com outras tarefas. Ambos têm um caminho de diagnóstico claro e uma solução específica.
Uma falha reside na tabela de fluxo, a outra no escalonamento de processo/núcleo — comandos display diferentes encontram cada uma.
Ler primeiro o sintoma diante desta árvore indica se você está perseguindo um problema de capacidade de tabela de fluxo ou um de vinculação de CPU/processo.
Os rótulos do diagrama permanecem em inglês para clareza técnica.
Nenhum dos dois indica que o próprio SAC/ECA esteja quebrado — ambos são comportamentos de capacidade e escalonamento que aparecem de forma previsível quando se sabe onde procurar.
Ambos partem de um sintoma que um NOC realmente notaria — um painel de aplicações quase vazio, ou um switch lento para responder — e terminam em uma leitura específica de contador ou processo.
A plataforma de análise relata um punhado de aplicações que ninguém liga, e quase nenhuma das que a implantação foi construída 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 tableO switch está lento, alarmes de memória e CPU disparam, e o culpado acaba sendo o processo que faz a classificação de aplicações, vinculado a um único núcleo junto com outras tarefas do 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 deviceDois casos de campo reais, e duas disciplinas operacionais relacionadas que vêm diretamente deles.
SINTOMAO painel de análise de aplicações relata muito poucas das aplicações realmente de interesse, e bastante ruído de baixo valor em vez disso.
CAUSAA tabela de fluxo que sustenta o SA/ECA tem um número fixo de entradas — 16384 no caso desta nota. Um protocolo tagarela e de baixo valor como o DNS ganha uma entrada de tabela por sessão como qualquer outro, e com volume de clientes suficiente por trás, pode ocupar a grande maioria da tabela com entradas que ninguém pediu para ver, chegando a ultrapassar um alarme de uso de 90% (15739 de 16384 usadas).
SOLUÇÃOConfigure uma whitelist ec-analytics referenciando uma ACL que corresponda aos protocolos e portas de ruído, para que o SA/ECA nunca gaste uma entrada de tabela reconhecendo-os.
acl number 3666
rule 15 permit udp source-port eq domain
rule 20 permit udp destination-port eq domain
ec-analytics whitelist acl 3666SINTOMAO switch está lento, alarmes de memória/CPU disparam, e display system process mostra uma tarefa ECA específica consumindo uma grande parte de um núcleo.
CAUSAA afinidade processo/núcleo colocou a tarefa ECA na mesma pequena faixa de núcleos que outras tarefas do sistema ocupadas. O outro trabalho desse núcleo compete com o ECA por ciclos e reduz a capacidade de resposta geral, mesmo quando a utilização total multi-núcleo parece nada notável — verificar Cpus_allowed_list é o que realmente revela isso, não o número agregado de CPU.
SOLUÇÃOConfirme a vinculação com shell-command slot pid-status. Se a implantação não precisa realmente de reconhecimento de aplicações ou IPCA, undo defence engine enable remove a carga diretamente; caso contrário, este é um problema de afinidade de núcleo que vale a pena escalar com as evidências já coletadas.
[HUAWEI-diagnose] shell-command slot 0 pid-status 8650
Cpus_allowed_list: 0-1
[HUAWEI] undo defence engine enableSINTOMAUm alarme de CPU ou memória dispara — a pergunta que vale a pena fazer antes de escalar é se isso está realmente em curso.
CAUSAUm pico momentâneo — uma reinicialização, uma rajada de coleta de informações de módulos ópticos, uma rajada de tráfego — geralmente não afeta a operação normal e se resolve sozinho. Um platô sustentado por minutos é o padrão que realmente vale a pena rastrear até uma tarefa ou processo específico.
SOLUÇÃOUse display cpu-usage history 1hour para ver o formato da carga ao longo do tempo antes de decidir se as verificações de display system process e vinculação de núcleo são justificadas.
SINTOMAOs nomes de aplicações esperados estão ausentes da tabela mesmo com o SA habilitado na interface e as assinaturas parecendo corretas.
CAUSAA tabela de fluxo é compartilhada entre todas as aplicações que o SA reconhece, não é particionada por aplicação. Uma vez saturada por outro tráfego, simplesmente não sobra espaço para a entrada de um novo fluxo, independentemente de quão corretamente as aplicações que você realmente se importa estejam configuradas.
SOLUÇÃOLeia as colunas AppName e Expire de display engine session application junto com qualquer alarme de uso de fluxo do logbuffer — essa combinação diferencia a falta de capacidade de tabela de um problema real de assinatura ou configuração.
Tiradas diretamente do campo — aquelas para as quais vale a pena ter uma resposta pronta.
Não necessariamente quebrado. Verifique primeiro a utilização da tabela de fluxo — display engine session application mais o alarme app feature flow usage no buffer de logs — antes de supor um problema de configuração ou licenciamento. Uma tabela saturada parece exatamente como se nada estivesse sendo reconhecido do lado do relatório, mesmo que o SA esteja classificando o tráfego corretamente.
Coloque na whitelist o que você realmente confirmou que ninguém precisa visualizar — DNS, SSDP e Kerberos foram os culpados específicos no caso desta nota. Uma whitelist muito ampla pode excluir silenciosamente algo que você queira visualizar mais tarde, então ajuste-a ao tráfego real que você revisou com quem é responsável pela implantação, não a uma lista genérica copiada de outro lugar.
Somente se for sustentado e realmente se correlacionar com a lentidão. Verifique primeiro display cpu-usage history 1hour para ver se é um platô mantido por minutos em vez de um pico momentâneo de uma reinicialização, um ciclo de coleta de informações de módulo óptico, ou uma rajada de tráfego — esta última geralmente é inofensiva e se resolve sozinha.
Se a implantação não precisa realmente de reconhecimento de aplicações, IPCA ou das análises relacionadas, undo defence engine enable remove a carga completamente. Se as análises realmente são necessárias, este é um problema de afinidade de núcleo e escalonamento que vale a pena escalar com as evidências de processo e pid-status já coletadas, em vez de continuar autodiagnosticando.
Sim — são limites de capacidade independentes (entradas de tabela versus escalonamento de núcleo) que ficam ambos por trás da mesma funcionalidade SAC/ECA. Um switch de borda de campus ocupado, com bastante tráfego de DNS e reconhecimento de aplicações habilitados, é exatamente o perfil onde você veria os dois ao mesmo tempo.
Esta nota se baseia na funcionalidade de reconhecimento de aplicações SAC/ECA dos switches de campus série S5731/S5732/S6730 (e eKitEngine comparáveis) — o comportamento de capacidade de tabela de fluxo por trás de display engine session application, e o comportamento de vinculação processo/núcleo por trás de display system process e shell-command pid-status — além dos dois casos de campo por trás deles. Os tamanhos exatos da tabela de fluxo e os nomes de processo podem diferir por modelo e versão, então confirme ambos no seu próprio hardware em vez de supor que o mesmo limite de 16384 entradas ou o mesmo nome de processo ECA se aplica em todo lugar. Não cobre em profundidade os pré-requisitos de licenciamento do SAC/ECA nem a configuração de exportação NetStream/telemetria.
Envie-nos display engine session application, o alarme do logbuffer se houver, e display system process, e ajudamos você a distinguir um problema de tabela de fluxo de um de vinculação de núcleo.