Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Identify Available Software and Hardware Resources

Learn how to find available software and hardware resources on your MX204, MX301, MX304, MX10004, or MX10008 router.

The Routing Engine serves as the control plane for MX platform. It runs Junos OS, maintains routing protocols, and manages the chassis. To detect capacity issues, unexpected processes, or hardware problems before they impact network traffic, you must regularly monitor the Routing Engine's CPU, memory, and buffer resources.

You must know a few commands to monitor these hardware and software resources on Juniper MX204, MX301, MX304, MX10004, and MX10008 routers.

Use the show chassis routing-engine command to view the status of both Routing Engine slots (primary and backup). This command displays temperature, DRAM usage, CPU utilization, uptime, and load averages.

Key fields:

Field

Description

Healthy Threshold

Temperature / CPU temperature Routing Engine board and CPU die temperature < 55°C typical
Memory utilization Percentage of installed DRAM in use < 80%
User CPU Time consumed by user-space daemons (RPD, chassisd…) < 70% sustained
Kernel CPU Time consumed by kernel tasks < 20% sustained
Interrupt CPU Time consumed by hardware interrupts < 10%
Idle CPU Available CPU headroom > 30% recommended
Load averages 1/5/15 min UNIX load averages — should be stable Stable and proportional to CPU count
Last reboot reason Last known cause of Routing Engine restart Investigate if unexpected
Note:

CPU utilization is reported over four time intervals: 5 seconds, 1 minute, 5 minutes, and 15 minutes. Short‑term spikes in the 5‑second interval are typically normal. Investigate sustained high user CPU utilization across all intervals by using the show system processes extensive command.

Process-Level CPU and Memory Usage

The show system processes summary command provides a real-time UNIX-style process table, equivalent to the top utility. It identifies which processes consume the most CPU and resident memory.

Key columns:

Column

Description

SIZE

Virtual memory allocated to the process

RES

Actual resident memory (physical RAM used) — the most meaningful field

WCPU

Weighted CPU usage — primary indicator of CPU load per process

TIME

Cumulative CPU time consumed since start

STAT

Process state: select/sleeping = normal; zombie = terminated but not reaped

Tip:

Use show system processes extensive for the full untruncated process list, sorted by CPU. Look for any non-idle daemon with unexpectedly high WCPU or RES, such as rpd, chassisd, or jinsightd.

System Memory Distribution

To verify the full kernel memory breakdown and per-process virtual and resident memory usage, run the show system memory command:

Memory segment descriptions:

Segment

Description

Reserved

Memory reserved by the kernel and not available to processes

Wired

Kernel pages that cannot be paged out (always in RAM)

Active

Memory currently in active use by processes

Inactive

Recently used memory, reclaimable if needed

Cache

File system cache

Free

Immediately available memory

In this output, 77% free memory indicates a healthy, lightly loaded Routing Engine. Memory pressure typically appears as a decrease in free and inactive memory, an increase in active memory, and potential swap usage.

Network Buffer Usage

To verify kernel network buffer (mbuf) usage, run the show system buffers command. The FreeBSD-based Junos kernel uses these memory structures to process network packets in the control plane.

Key indicators:

Field

Description

Warning Sign

mbufs in use (current)

Control-plane packet buffers actively used

Approaching total/max

requests denied

Allocation failures for mbufs or jumbo clusters

Any non-zero value

requests delayed

Delayed buffer allocations due to exhaustion

Any non-zero value

Jumbo cluster utilization

Large packet buffer usage (4k/9k/16k pages)

Current approaching max

Important:

Any non-zero value in the denied or delayed lines indicates that the kernel failed to allocate network buffers. This failure can cause control-plane packet drops—including BGP keepalives, OSPF hellos, or BFD PDUs—and requires immediate investigation.

To prevent traffic forwarding failures, you must regularly monitor Flexible PIC Concentrator (FPC) and Packet Forwarding Engine resources. Ensure the system maintains adequate headroom for next-hops, firewall filters, logical interface (IFL) counters, and class of service (CoS) queues. Exhausting any of these hardware resources causes traffic forwarding to fail, even when the Routing Engine (RE) remains healthy.

To verify the operational state, temperature, CPU utilization across three time windows, DRAM size, heap usage, and buffer utilization for all installed line cards, run the show chassis fpc command:

Key fields:

Field

Description

Warning Threshold

State

FPC operational status

Anything other than Online

Temp (C)

FPC board temperature

> 55°C typical

Total CPU

Overall FPC CPU utilization (microkernel)

> 80% sustained

Interrupt CPU

CPU time consumed by hardware interrupts

> 10% sustained

Heap (%)

Percentage of FPC heap (ukern) memory used

> 70% (configurable threshold)

Buffer (%)

Packet buffer utilization on the FPC

> 80%

To verify per-FPC hardware details—including total DRAM, High Bandwidth Memory (HBM) used by Trio ASICs for forwarding tables, power consumption, operating bandwidth, and active Packet Forwarding Engines with their individual bandwidth—run the show chassis fpc <slot> detail command:

Key fields:

Field

Description

Total CPU DRAM

General-purpose DRAM available to the FPC microkernel (heap)

Total HBM

High bandwidth memory dedicated to forwarding table storage (next-hops, routes, filters)

Max power consumption

Rated max pwer draw—relevat for power budget planning

Operating Bandwidth

Total aggregate bandwidth of the FPC (sum of all active PFEs)

PFE Bandwidth

Per-Packet Forwarding Engine forwarding capacity—800G per PFE on this MX10004 LC

To verify hardware error events at both the board (FPC microkernel) and Packet Forwarding Engine (ASIC) scope across multiple categories and severity levels, run the show chassis fpc errors command:

Output structure:

Column

Description

Scope

board = FPC-level error; pfe = PFE ASIC-level error

Category

Error domain: functional, memory, io, storage, switch, processing, internal

Level

Severity: MinorMajorFatal

Occurred

Total number of times this error has triggered

Cleared

Number of times the error condition self-resolved

Action-Taken

Count of times an action was triggered

Action

System response: LOG, CM ALARM, GET STATE, RESET, DISABLE PFE

Error severity and associated automatic actions:

Severity

Board Action

PFE Action

Minor

LOG + chassis alarm

LOG + chassis alarm

Major

Collect state + chassis alarm

Collect state + chassis alarm + disable PFE

Fatal

Collect state + FPC reset

Collect state + FPC reset

Important:

You must immediately investigate any Major or Fatal error that shows a non-zero count in the Occurred column. If a Minor functional error occurs at the board scope, correlate the event against syslog messages and Juniper JTAC advisories. To confirm which packet forwarding engines remain active, check the Pfe-State line at the bottom of each Packet Forwarding Engines scope.

To verify per-FPC and per-PFE utilization of the three key data-plane ASIC memory pools—filter counter memory, IFL counter memory, and expansion memory (used for forwarding table entries and next-hop chains)—run the show system resource-monitor summary command. This command also reports heap memory consumption and CoS queue block utilization:

Packet Forwarding Engine memory pool descriptions:

Memory Pool

Description

Configured Threshold

Heap (ukern)

General FPC microkernel memory—used by daemons and local processes

70%

Filter counter memory

ASIC memory for firewall filter byte/packet counters

100%

IFL counter memory

ASIC memory for logical interface (IFL) statistics counters

95%

Expansion memory

ASIC memory for forwarding table entries: routes, next-hops, MPLS labels

95%

CoS queue blocks

Scheduler memory blocks allocated per output queue

100%

Resource denial counters:

Counter

Meaning

Client denied

FPC rejected a resource allocation request from a client process

Service Denied

Service-level resource request denied

IFL Denied

New logical interface creation denied due to counter memory exhaustion

Warning:

When Expansion memory % approaches the configured threshold (95%), the FPC will start throttling new forwarding entries—this can manifest as route installation failures or next-hop programming errors. Similarly, IFL Denied > 0 means logical interfaces could not be created, which would impact subscriber or tunnel scaling.

In this output, all three FPCs show healthy utilization: heap at 23–30%, filter counters at 2%, IFL counters at 4%, and expansion memory at 13% — providing significant headroom.

To view free memory watermarks for heap, next-hop, and firewall memory pools for a specific FPC, run the show system resource-monitor fpc slot <n> command. This command provides a per-FPC view and breaks down free ENCAP, next-hop, and firewall memory per Packet Forwarding Engine:

Note:

Watermark thresholds can be tunned in the configuration.

Key fields:

Field

Description

Alert Trigger

% Heap Free

Percentage of FPC heap memory remaining

Below 20% watermark (marked with *)

% NH mem Free

Free next-hop ASIC memory per PFE — used for forwarding adjacencies

Below 20% watermark

% FW mem Free

Free firewall/filter ASIC memory per PFE

Below 20% watermark