The post appears weekly: "SRX345 at 100% CPU — do I need a bigger firewall?" Usually the answer is no — a single process is misbehaving and the fix is configuration. This guide walks from "the box feels slow" to "this process, this cause, this fix."

Step 1: Which Engine, and How Bad?

show chassis routing-engine

Confirm the Routing Engine (control plane) is the busy side — the Packet Forwarding Engine passing transit traffic is a different problem entirely and does not show here. Sustained RE CPU above 70 to 80 percent warrants a look; brief spikes from commit or SNMP walks are normal.

Step 2: Name the Process

show system processes extensive

Sort mentally by CPU column. The usual suspects and what each one's high usage means:

  • rpd — the routing protocol daemon. High CPU means route churn: BGP updates storming in, OSPF or IS-IS SPF running repeatedly, or a route limit being pushed. This is the most common cause on core routers, and our BGP troubleshooting guides show how to find a flapping peer driving it.
  • snmpd and mib2d — an NMS polling too aggressively, often walking large tables (the full ifTable on a 48-port switch every 30 seconds). Fix at the poller: raise intervals, use views, target specific OIDs.
  • httpd — J-Web or the SRX web management being hammered or stuck; on SRX this is a known CPU eater. If you do not use J-Web: delete system services web-management.
  • eventd and syslogd — a logging storm, frequently from traceoptions someone left enabled, or an error message repeating thousands of times per minute. Check show log messages | last 100 for the repeated line, fix the underlying error, remove debug traceoptions.
  • kmd — the SRX key management daemon for IPsec. High usage points at VPN renegotiation churn — see the IPsec tunnel troubleshooting guide.
  • mgd — management daemon; brief spikes during commit and CLI use are normal, sustained usage suggests a NETCONF poller or management session storm.

Step 3: rpd Deep Dive — Find the Churn

show route summary
show bgp summary
show ospf statistics
show ospf log

show route summary exposes a table filling toward its limit (a leaking default route or an upstream sending full tables where you expected partial). show ospf log lists recent SPF runs — repeated full SPF every few seconds means instability somewhere in the area. Combine with the interface health method in our CRC and input-errors guide, because flapping physical links are the usual root cause of protocol churn.

Step 4: Protect the Control Plane

Once healthy, keep it healthy: apply loopback firewall filters that rate-limit traffic to the RE (SSH, BGP, OSPF, ICMP), configure prefix-limits on BGP peers, disable unused web management, and audit that no traceoptions survive from past incidents. These are standard items in any SRX hardening baseline.

When Bigger Hardware Really Is the Answer

If CPU is high on flow processing — check show security flow session summary utilization and SPU statistics on SRX — and sessions approach platform capacity, you have a capacity question rather than a process bug; our flow session guide covers reading those limits. But for the classic "rpd at 90 percent" case, the fix is almost always config, not chassis.