Turning on application recognition — SAC classifying traffic, ECA doing the analytics behind it — adds a flow table and a background process to every packet's path. Two things go wrong often enough to be worth knowing before you deploy it: noise traffic quietly fills the flow table before your reporting even starts, and the ECA process itself can end up pinned to a single core doing the whole switch's classification work.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
SAC classifies, ECA analyzes and reports — both cases below trace back to what happens once that pipeline is live under real traffic.
Enabling SA (traffic recognition) on an ingress interface and deploying SAC/ECA application analytics sounds like a read-only feature — it's supposed to tell you what's on the wire, not change how the wire behaves. In practice it adds a flow table with a fixed number of entries, and a process that has to classify every new flow against a large signature set. Both of those have a capacity, and both show up in tickets when that capacity gets used somewhere other than where you expected.
The two cases in this note come from actual deployments: a campus switch whose application analytics dashboard was reporting almost nothing useful because the flow table was full of DNS, and a switch that got sluggish because the ECA process doing the classification work was bound to a single CPU core alongside other tasks. Both have a clean diagnostic path and a specific fix.
One failure sits in the flow table, the other in process/core scheduling — different display commands find each one.
Reading the symptom against this tree first tells you whether you're chasing a flow-table capacity problem or a CPU/process-binding one.
Diagram labels are kept in English for engineering clarity.
Neither of these is a sign that SAC/ECA itself is broken — both are capacity and scheduling behavior that show up predictably once you know to look for them.
Both start from a symptom a NOC would actually notice — a near-empty applications dashboard, or a switch that's slow to respond — and end at a specific counter or process reading.
The analytics platform reports a handful of applications nobody cares about, and almost none of the ones the deployment was built to track.
[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 tableThe switch is sluggish, memory and CPU alarms fire, and the culprit turns out to be the process doing application classification, bound to one core alongside other system tasks.
<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 deviceTwo real field cases, and two related pieces of operating discipline that come straight out of them.
SYMPTOMThe application analytics dashboard reports very few of the applications actually of interest, and plenty of low-value noise instead.
CAUSEThe flow table backing SA/ECA has a fixed number of entries — 16384 in the case behind this note. A chatty, low-value protocol like DNS gets a table entry per session just like anything else, and with enough client volume behind it, it can occupy the large majority of the table with entries nobody asked to see, right up to and past a 90% usage alarm (15739 of 16384 used).
FIXConfigure an ec-analytics whitelist referencing an ACL that matches the noise protocols and ports, so SA/ECA never spends a table entry recognizing them in the first place.
acl number 3666
rule 15 permit udp source-port eq domain
rule 20 permit udp destination-port eq domain
ec-analytics whitelist acl 3666SYMPTOMThe switch is sluggish, memory/CPU alarms fire, and display system process shows a specific ECA task consuming a large share of one core.
CAUSEProcess/core affinity placed the ECA task on the same small core range as other busy system tasks. That core's other work competes with ECA for cycles and pushes overall responsiveness down, even when total multi-core utilization looks unremarkable — checking Cpus_allowed_list is what actually surfaces this, not the aggregate CPU number.
FIXConfirm the binding with shell-command slot pid-status. If the deployment doesn't genuinely need application recognition or IPCA, undo defence engine enable removes the load outright; otherwise this is a core-affinity issue worth escalating with the evidence already collected.
[HUAWEI-diagnose] shell-command slot 0 pid-status 8650
Cpus_allowed_list: 0-1
[HUAWEI] undo defence engine enableSYMPTOMA CPU or memory alarm fires — the question worth asking before escalating is whether it's actually ongoing.
CAUSEA momentary spike — a reboot, a burst of optical-module information collection, a traffic burst — usually doesn't affect normal operation and resolves on its own. A plateau sustained over minutes is the pattern actually worth chasing down to a specific task or process.
FIXUse display cpu-usage history 1hour to see the shape of the load over time before deciding whether display system process and core-binding checks are warranted.
SYMPTOMExpected application names are missing from the table even though SA is enabled on the interface and the signatures look correct.
CAUSEThe flow table is shared across every application SA recognizes, not partitioned per application. Once it's saturated by other traffic, there's simply no room left for a new flow's entry, regardless of how correctly the applications you actually care about are configured.
FIXRead display engine session application's AppName and Expire columns together with any logbuffer flow-usage alarm — that combination tells table-capacity starvation apart from an actual signature or configuration problem.
Pulled straight from the field — the ones worth having an answer ready for.
Not necessarily broken. Check flow-table utilization first — display engine session application plus the app feature flow usage alarm in the log buffer — before assuming a configuration or licensing problem. A saturated table looks exactly like nothing is being recognized from the reporting side, even though SA is classifying traffic correctly.
Whitelist what you've actually confirmed nobody needs visibility into — DNS, SSDP and Kerberos were the specific offenders in the case behind this note. An overly broad whitelist can quietly exclude something you do want visibility into later, so match it to real traffic you've reviewed with whoever owns the deployment, not a generic list copied from somewhere else.
Only if it's sustained and actually correlates with sluggishness. Check display cpu-usage history 1hour first to see whether it's a plateau held over minutes rather than a momentary spike from a reboot, an optical-module information collection cycle, or a traffic burst — the latter is usually harmless and resolves on its own.
If the deployment doesn't genuinely need application recognition, IPCA, or the related analytics, undo defence engine enable removes the load entirely. If the analytics are actually required, this is a core-affinity and scheduling issue worth escalating with the process and pid-status evidence you've already collected, rather than something to keep self-diagnosing.
Yes — they're independent capacity limits (table entries versus core scheduling) that both sit behind the same SAC/ECA feature. A busy campus edge switch with plenty of DNS chatter and application recognition both enabled is exactly the profile where you'd see both at once.
This note is built around the S5731/S5732/S6730-series (and comparable eKitEngine) campus switch's SAC/ECA application-recognition feature — the flow-table capacity behavior behind display engine session application, and the process/core-binding behavior behind display system process and shell-command pid-status — plus the two field cases behind them. Exact flow-table sizes and process names can differ by model and version, so confirm both on your own hardware rather than assuming the same 16384-entry ceiling or the same ECA process name applies everywhere. It doesn't cover SAC/ECA licensing prerequisites or NetStream/telemetry export configuration in depth.
Send us display engine session application, the logbuffer alarm if there is one, and display system process, and we'll help you tell a flow-table problem from a core-binding one.