SystemEXEC

show processes cpu

Displays CPU utilization statistics for all processes running on the Cisco IOS-XR router.

Overview

The 'show processes cpu' command is a fundamental tool for monitoring and troubleshooting CPU utilization on Cisco IOS-XR routers. CPU usage directly impacts router performance: high CPU can cause packet drops, routing protocol instability, and slow management plane responses. This command displays real-time CPU statistics for each process running on the router, allowing engineers to identify which processes are consuming excessive CPU cycles.

In Cisco IOS-XR, the operating system runs multiple processes in a protected memory space, each handling specific functions such as routing protocols (BGP, OSPF, ISIS), forwarding (L2FIB, IPFIB), and system management (sysmgr, fys). Unlike traditional IOS, IOS-XR uses a microkernel architecture where processes are more isolated, making CPU monitoring even more critical for diagnosing process-level issues.

Use this command when you suspect CPU-related problems, such as slow CLI responses, routing protocol flaps, or high packet loss. It is also useful for baseline monitoring and capacity planning. The command provides average CPU utilization over 1, 5, and 15 minutes, plus per-process details including PID, CPU core, percentage CPU, runtime, invocations, and state. The 'sort' option orders processes by CPU usage, helping to quickly pinpoint the top consumer. The 'detail' option adds per-core breakdown and memory usage. For multi-chassis systems, use 'location <node-id>' to target a specific line card or RP.

In a troubleshooting workflow, start with 'show processes cpu' to get an overview. If a process shows high %CPU, investigate further with 'show processes cpu detail <process>' or 'show logging' for related errors. For routing protocols, check for route flaps or neighbor issues. For forwarding processes, examine interface statistics or hardware drops. This command is often the first step in isolating CPU-related problems.

Syntax·EXEC

show processes cpu [detail | sort | location <node-id> | process <process-name>]

When to Use This Command

Identify processes consuming excessive CPU during network congestion or attacks.
Monitor CPU usage baseline for capacity planning and performance tuning.
Troubleshoot high CPU caused by routing protocol processes (e.g., BGP, OSPF).
Verify process health after software upgrade or configuration change.

Parameters

Parameter	Syntax	Required	Description
detail	detail	Optional	Provides detailed per-process information including per-core CPU usage, memory usage, and process-specific statistics.
sort	sort	Optional	Sorts the process list by CPU usage in descending order, making it easier to identify the top CPU consumers.
location	location <node-id>	Optional	Specifies a particular node (e.g., line card or RP) in a multi-chassis system to display CPU statistics for that node only.
process	process <process-name>	Optional	Filters output to show only the specified process by name (e.g., 'bgp', 'ospf').

Command Examples

Basic CPU utilization overview

show processes cpu

CPU utilization for one minute: 15%   five minutes: 12%   fifteen minutes: 10%

PID    Process           CPU     %CPU    Runtime(ms)    Invoked   uSecs    State
1      init              0       0.0%    0              1         0        S
2      scheduler         0       0.0%    0              1         0        S
...
12345  bgp               1       8.5%    4567890        123456    37       S
12346  ospf              0       2.1%    1234567        654321    1.9      S
12347  l2fib             0       0.3%    123456         12345     10       S

The first line shows average CPU utilization over 1, 5, and 15 minutes. The table lists each process with its PID, CPU core number, percentage CPU usage, total runtime in milliseconds, number of invocations, average microseconds per invocation, and state (S=sleeping, R=running). High %CPU for a process like bgp (8.5%) indicates significant CPU consumption.

Detailed CPU per process with sort

show processes cpu sort

CPU utilization for one minute: 22%   five minutes: 18%   fifteen minutes: 15%

PID    Process           CPU     %CPU    Runtime(ms)    Invoked   uSecs    State
12345  bgp               1       12.3%   7890123        234567    33.6     R
12346  ospf              0       5.6%    2345678        876543    2.7      S
12347  l2fib             0       1.2%    345678         45678     7.6      S
...

The 'sort' option orders processes by CPU usage descending. Here, bgp is the top consumer at 12.3% and is in running state (R). This helps quickly identify the most CPU-intensive processes.

Understanding the Output

The output begins with average CPU utilization over three time windows: 1 minute, 5 minutes, and 15 minutes. These averages give a quick health check: values consistently above 70% may indicate a problem. The process table lists each process with its PID, CPU core (0,1,...), %CPU (percentage of total CPU), total runtime in milliseconds, number of times the process was invoked, average microseconds per invocation, and current state (S=sleeping, R=running, Z=zombie). High %CPU for a single process (e.g., >20%) warrants investigation. The 'uSecs' field shows average execution time per call; high values may indicate inefficient code. The state 'R' means the process is actively running, while 'S' means it is sleeping (idle). A process stuck in 'R' for long periods could indicate a loop. Use the 'detail' option to see per-core breakdown and memory usage.

Configuration Scenarios

Monitoring BGP CPU usage on a route reflector

A route reflector is experiencing high CPU and BGP session resets. Need to check BGP process CPU usage.

Topology

    [RR] --- eBGP --- [AS 100]
     |
   iBGP
     |
   [Client]

Steps

1.Connect to the route reflector via SSH or console.
2.Enter EXEC mode and run 'show processes cpu sort' to see top CPU consumers.
3.If BGP is high, run 'show processes cpu process bgp' for detailed BGP CPU stats.
4.Check BGP neighbor states with 'show bgp summary' to identify flapping sessions.

Configuration

! No configuration change needed for monitoring; this is a show command.

Verify: After identifying high BGP CPU, verify with 'show processes cpu process bgp detail' to see per-core usage and runtime.

Watch out: On multi-RP systems, ensure you specify the correct location (e.g., 'location 0/0/CPU0') to get the RP where BGP runs.

Troubleshooting with This Command

When troubleshooting high CPU on Cisco IOS-XR, 'show processes cpu' is your starting point. Begin by checking the 1-minute average: if it exceeds 70%, investigate further. Use 'show processes cpu sort' to identify the top process. Common culprits include routing protocols (BGP, OSPF, ISIS) during convergence or flapping, forwarding processes (l2fib, ipfib) under heavy traffic, and management processes (sysmgr, fys) due to excessive logging or SNMP polling.

If a routing protocol shows high CPU, check for route flaps using 'show bgp neighbor <ip> | include flaps' or 'show ospf statistics'. For forwarding processes, examine interface counters with 'show interfaces <interface> | include errors|dropped'. High CPU in 'sysmgr' may indicate process crashes or restarts – check 'show logging' for related messages.

Use the 'detail' option to see per-core utilization; a process pinned to one core may indicate a scaling issue. Also, compare with baseline values – a sudden spike is more concerning than consistently high usage. If CPU remains high after identifying the process, consider configuration changes like route aggregation, BGP update tuning, or implementing control-plane policing (CoPP). Remember that on IOS-XR, some processes are multi-threaded and may show high CPU across multiple cores – this is normal for processes like 'bgp' with many peers.

CCNA Exam Tips

Remember that 'show processes cpu' is for real-time CPU monitoring; for historical data use 'show processes cpu history'.

In CCNP troubleshooting, high CPU from routing protocols often indicates route flapping or misconfiguration.

The 'sort' parameter is useful for quickly identifying top CPU consumers in exam scenarios.

Common Mistakes

Confusing 'show processes cpu' with 'show processes memory' – the former shows CPU, the latter memory.

Assuming low CPU utilization means no issues – some problems cause intermittent spikes missed by averages.

Forgetting to specify location on multi-chassis systems – use 'location <node-id>' to target a specific node.

Platform Notes

On Cisco IOS-XR, the 'show processes cpu' command differs from classic IOS in several ways. IOS-XR uses a more granular process model with per-core statistics available via the 'detail' option. The output includes a 'CPU' column indicating which core the process is running on, which is not present in IOS. Additionally, IOS-XR supports the 'location' parameter to target specific nodes in a distributed system, whereas IOS typically uses 'show processes cpu' without location.

Equivalent commands on other platforms: On Juniper Junos, use 'show system processes extensive' or 'show task statistics'. On Arista EOS, use 'show processes top' or 'show cpu utilization'. On Nokia SR OS, use 'show system cpu'.

Version differences: In earlier IOS-XR versions (e.g., 4.x), the command output may not include the 'uSecs' column. Starting from IOS-XR 6.0, the 'sort' option was enhanced to sort by %CPU. Always check the specific version documentation for exact output format.

Practice for the CCNA 200-301

Test your knowledge with hundreds of CCNA practice questions covering all exam domains.

Practice CCNA Questions