Cisco ISE High CPU and RADIUS Authentication Failures: Diagnosing and Fixing the Bug Behind Mass Lockouts

Cisco TAC has documented several specific defects that produce sustained high CPU on ISE nodes independent of actual traffic load, and recognizing that a bug ID exists for your symptom saves significant time over troubleshooting from scratch. CSCvc86247 describes high CPU caused by threads on a policy service node (PSN) entering what Cisco's own case notes describe as an infinite loop, consuming CPU with no corresponding increase in useful authentication throughput. CSCvc75209 covers ISE 2.1 and later versions showing high I/O and high CPU attributable to the underlying Oracle database process specifically while the node is in monitoring (MNT) mode, which is a meaningful distinguishing detail since it points at the reporting and logging subsystem rather than the authentication path itself. CSCvd56372 describes a deadlock condition surfacing in the Oracle alert log, which again implicates the database layer rather than RADIUS processing directly. All three are consistent with a broader pattern Cisco support has stated directly in community threads: the practical fix for a confirmed software-defect signature is installing the latest cumulative patch for your ISE version, not a configuration change, because the defect lives in ISE's own code rather than in how it was deployed.

Separate from a confirmed code defect, ISE's profiling engine and its Monitoring and Troubleshooting (MNT) reporting subsystem are legitimate, non-buggy sources of sustained CPU load when they are handling more work than the node is sized for. Every successful RADIUS authentication is logged, and by default every one of those log entries is written and indexed for reporting, which at high authentication volume, large numbers of endpoints re-authenticating frequently, aggressive session timeout intervals forcing frequent re-auth, or a busy guest and BYOD deployment, can saturate the reporting pipeline well before it saturates the actual authentication logic. Similarly, active profiling probes (DHCP, HTTP, NetFlow, RADIUS, SNMP) each consume CPU cycles per endpoint they are actively fingerprinting, and a deployment that has every probe enabled by default regardless of whether the resulting endpoint classification is actually used downstream in policy is paying a CPU cost for data nobody consumes.

A third distinct cause is not a defect in ISE at all but a genuine mismatch between the RADIUS request volume actually arriving at a node and the authentication and authorization sources it depends on to answer each request. A node proxying to Active Directory, an external identity provider, or a certificate authority for every authentication adds a network round trip and a dependency on that external system's own responsiveness to every single request; if that external dependency is slow or intermittently unavailable, ISE does not fail fast, it holds the request open, and enough held-open requests queuing simultaneously produces CPU pressure that looks identical to a software bug from a dashboard alone. This is the case most likely to be mistaken for a defect, because the CPU graph looks the same, but the actual root cause and fix live entirely outside ISE, in the responsiveness of the domain controllers, LDAP servers, or CA it depends on.

From the ISE CLI, run show cpu and show tech-support to get a process-level breakdown of what is actually consuming CPU rather than working from the aggregate percentage alone; the community-documented "tech top" style output shows utilization broken out by running process, and a defect signature like CSCvc86247 or CSCvc75209 shows up as a specific named process, most often something in the Oracle database stack, pinned high independent of authentication volume, while a genuine traffic-volume cause shows CPU tracking authentication request rate proportionally. Cross-reference that against ISE's own alarms under the alarm dashboard; a node approaching or exceeding its licensed or sized authentication capacity typically raises its own capacity-related alarm before or alongside the CPU spike, which is a strong signal toward cause three above rather than a defect. For the authentication failures themselves, work from RADIUS Live Logs (Operations, RADIUS, Live Logs) first: open the specific failed session and read the textual failure reason ISE provides directly, which will say explicitly whether the failure was an MSCHAPv2 failure, an Active Directory error, a certificate validation error, or a timeout, rather than guessing from the generic failed-authentication count. If an expected authentication attempt does not appear in Live Logs at all, use the built-in TCP Dump utility under Operations, Troubleshooting, Diagnostic Tools, or run tcpdump directly from the ISE CLI filtered to UDP ports 1812 and 1813, to confirm whether the RADIUS packets are reaching the node's interface at all; packets that never arrive point upstream to the switch or wireless controller configuration, while packets that arrive but never appear in Live Logs point to an ISE-internal processing bottleneck consistent with the CPU pressure you are already seeing.

Once CLI diagnostics confirm a named process consistent with a documented bug ID rather than a traffic-proportional CPU curve, the fix is installing the cumulative patch Cisco has released for that defect on your specific ISE version, not a configuration workaround, since the underlying issue is in ISE's own code. Check the fixed-in version noted against the specific bug ID in the Cisco Bug Search Tool before patching, since a defect fixed in one patch level can still be present in an earlier patch on the same major release, and confirm your current patch level with show version before assuming you are already current. Schedule the patch through a maintenance window and validate on a single node first if you are running a distributed deployment, since a patch that resolves the CPU issue can still carry its own regression risk on an unrelated subsystem.

If the diagnostic signature points at profiling or MNT reporting overload rather than a coded defect, the fastest stopgap, deployable immediately without a maintenance window, is disabling profiling probes that are not actually feeding an authorization policy decision; under Administration, System, Deployment, edit each node's profiling configuration and turn off any probe (commonly NetFlow and SNMP query probes are the heaviest and least frequently load-bearing) that is not directly referenced by a profiling policy you rely on. Separately, enable RADIUS logging suppression under Administration, System, Settings, Protocols, RADIUS, which prevents repeated successful authentications from the same endpoint within a short interval from each generating a full, separately indexed log entry, reducing MNT subsystem load without losing the failure-side detail you actually need for troubleshooting. Neither change addresses a genuine software defect, and neither should be treated as a substitute for patching once a bug ID is confirmed; treat both as buying time on an already-overloaded node while a patch is scheduled, not as the permanent fix.

If diagnostics point at cause three, RADIUS volume proportional to CPU with a healthy process-level breakdown and no matching bug ID, the fix is capacity and dependency work rather than anything inside the ISE node's own configuration. Confirm the node is running within its licensed and sized authentication-per-second capacity for its hardware or VM allocation, and add a node to the deployment or rebalance load across existing nodes if it is not. If the CPU pressure correlates with proxied lookups to Active Directory, LDAP, or a certificate authority, work the responsiveness of that upstream system directly, since ISE holding open requests waiting on a slow external dependency is a symptom of that dependency's health, not of ISE's configuration, and no ISE-side change fixes a slow domain controller.

A CPU graph returning to a normal baseline is not sufficient validation on its own, since a masking fix, disabling a probe, suppressing logs, or a node simply receiving less traffic temporarily, can bring the number down without the underlying cause being addressed. Confirm recovery on two separate signals: the process-level CPU breakdown from show tech-support no longer shows the specific process implicated in diagnostics pinned high, and the RADIUS authentication success rate reported in Live Logs and the RADIUS Authentications report has returned to its pre-incident baseline rather than merely no longer degrading further. Watch that success rate over a period long enough to include your normal peak-load window, typically the morning login surge for a wired or wireless deployment, since a fix validated only during an off-peak lull can still fail the same way at the next capacity peak. If the fix was a patch, keep the specific bug ID's fixed-in version documented against this node so a future upgrade does not inadvertently revert to a pre-patch build.

The most common incomplete fix is disabling profiling probes or enabling logging suppression on a node whose real problem is a confirmed bug ID; CPU comes down, authentications recover temporarily, and the same defect resurfaces weeks later once traffic grows back into the range that re-triggers it, because the actual code path was never patched. A second failure case is recurrence after an unrelated upgrade: patching one specific bug ID does not guarantee a subsequent major-version upgrade does not reintroduce a different, unrelated CPU issue, since ISE upgrades routinely change default probe configurations, default logging verbosity, and database schema behavior, any of which can independently produce a new high-CPU pattern that looks identical to the one you just fixed but has a different underlying cause. A third failure case is treating a traffic-volume cause as if it were a bug: adding capacity or rebalancing load resolves cause three, but if the actual root cause was a bug ID, added capacity only delays the CPU spike rather than preventing it, since the defective process still runs on every node regardless of how load is distributed across them.

Open a TAC case once CLI diagnostics show a process-level CPU signature that does not match a bug ID you can already find in the Cisco Bug Search Tool, since TAC has access to defect data and internal engineering escalation paths beyond what is publicly searchable, and a novel signature is exactly the case where independent troubleshooting has the lowest odds of resolving anything further on your own. Also escalate immediately, without extended internal troubleshooting first, if the affected node is providing authentication for a production environment currently experiencing mass authentication failures, since TAC's severity-based response process exists specifically for active-outage conditions and self-directed troubleshooting time has a direct cost in locked-out endpoints. Before opening the case, gather a support bundle from Operations, Troubleshooting, Download Logs, covering the incident window, the output of show tech-support and show version from the affected node, the specific RADIUS Live Log failure reasons observed with timestamps, and, if you captured one, the TCP dump from the affected interface; TAC engineers consistently move faster on a case that arrives with this bundle already attached than one that requires several rounds of follow-up requests for the same data.