The r/Juniper thread "High Memory Util on our Core Switch — EX4600 JUNOS" ends with a JTAC statement that reorients the whole conversation: it is normal for this firmware to run about 75% utilized memory. Before and after an upgrade, utilization can jump tens of percent with no leak at all. Here is how to read EX-series memory the way TAC does.
Why 75% Can Be Normal: Pre-Allocation
Junos allocates memory for structures the switch may need — buffer descriptors, hash tables, route and MAC table headroom — at boot, not on demand. The number everyone stares at (Mem: xx% used) is mostly that static reservation. On EX4600/EX4300 class hardware, a steady 70–80% with stable processes is the design center, not a warning. The mistake is judging memory by total percentage alone.
Read It Properly: Split Kernel from Processes
show system buffers
show system processes extensive
show chassis routing-engineTwo questions matter: how much is kernel-allocated (buffers, descriptors — the static part) and how much is process heap (RSS of daemons — the part that can leak). Judge each separately: kernel growth after config changes can be normal scale-out; process RSS growth over days without traffic growth is the leak signature.
The Leak Signature
show system processes extensive | match "rpd|snmpd|mgd|eventd|mib2d"Watch a specific daemon's RES (resident) memory over hours: leak means monotonic growth uncorrelated with load — rpd climbing during a quiet Sunday night, snmpd growing without polling changes. Contrast with load-correlated growth (mib2d rising during a big SNMP walk, rpd rising during route churn), which is healthy scaling. Record values hourly; a graph of RSS over 24 hours separates the two cases instantly.
What Actually Fixes It
- Known leaks: each Junos release fixes some and introduces others; if a daemon grows without bound on your version, check release notes and known-issues for that daemon, and plan an upgrade to the recommended release — following the validation and rollback procedure in our Junos upgrade guide so the memory fix does not arrive with a validation failure.
- Self-inflicted load: oversized SNMP walks, aggressive NETCONF pollers and leftover traceoptions all inflate daemon memory. The SNMP polling guide trims the biggest offender.
- Structural pressure: MAC tables filling from a spoofing host or loop (the EX MAC flooding guide shows the protection commands) forces scale-out that can push marginal platforms over their comfortable range.
- Restart discipline:
restart <daemon> gracefullyfrees leaked memory immediately and is safe for most daemons — but schedule it; the same reasoning as the mgd restart warning applies.
Decision Table
| Observation | Verdict | Action |
|---|---|---|
| 75-80% steady, processes stable | Normal pre-allocation | None — monitor trend |
| Jump after Junos upgrade | New version allocations | Confirm with JTAC/release notes |
| One daemon RSS climbing daily | Leak | Identify version, upgrade/restart daemon |
| Memory + CPU climbing together during polls | Poller pressure | Tune NMS, add SNMP views |
Memory that "feels high" is the least actionable alarm in networking; the trend of individual daemon RSS is the actionable one. Pair this method with the CPU side of the same equation in the routing engine high-CPU guide, and remember both matter most when the box is also carrying overlay duties — the resource behavior of EVPN leaf deployments is covered in the EX3400/EX4300 leaf guide.
Discussion (0)