This article explains the cause, analysis, and recommended troubleshooting steps for the minor alarm message: Minor alarm set. Potential slow peers are: rpd
This alarm typically indicates that one or more processes on the Routing Engine (RE) are consuming excessive resources or are otherwise behaving in a delayed or unresponsive manner. By following the steps below, you can collect the necessary data for initial triage.
mgd[56789]: %DAEMON-3-UI_RECONN_READ_FAILED: Invalid response from peer 'routing': 421 Connection unexpectedly terminated
cscript: %DAEMON-3: snmputility.slax run for 122 seconds
alarmd[12345]: %DAEMON-4: Alarm set: RE id=123456789, color=YELLOW, class=CHASSIS, reason=Potential slow peers are: rpd
craftd[12345]: %DAEMON-4: Minor alarm set, Potential slow peers are: rpd
rpd: %USER-3-JTASK_SEND_RECV_ERROR: : Send msg call failed for task rsvp-io with error : Network is down
last message repeated 50 times
last message repeated 633 times
last message repeated 1012 times
alarmd[12345]: %DAEMON-4: Alarm cleared: RE id=123456789, color=YELLOW, class=CHASSIS, reason=Potential slow peers are: rpd
craftd[24042]: %DAEMON-4: Minor alarm cleared, Potential slow peers are: rpd
- Slow system responsiveness or degraded performance.- High CPU utilization on Routing Engine.
This alarm is typically triggered when internal system processes, such as `rpd`, are experiencing delays due to high CPU utilisation or kernel-level resource contention. This may impact route installation and processing.
Data Collection
At the time of the issue, collect the following outputs to assist in further analysis:
> show chassis alarms no-forwarding <<< Check active alarms
> show system processes extensive <<< Identify high CPU processes
> show chassis routing-engine no-forwarding <<< Review kernel utilization
> show log messages <<< Look for system messages or errors
> request support information | no-more <<< Capture comprehensive support snapshot
> show krt queue <<< Check kernel routing table queue
> show krt state <<< Examine routing kernel table state
> show system commit <<< Check for any configuration or scripts that have been pushed before the issue started.
Additionally, collect real-time routing socket activity:
> start shell
% rtsockmon -t > /var/tmp/rtsockmon.txt
Remediation Steps
1. Temporarily deactivate high-availability features to reduce CPU load:
deactivate chassis redundancy graceful-switchover
deactivate routing-options nonstop-routing
deactivate protocols layer2-control nonstop-bridging
2. If CPU utilisation remains high even after the above, **perform an RE mastership switchover**:
request chassis routing-engine master switch check
request chassis routing-engine master switch
3. If the issue persists and you observe high CPU usage across all processor cores (based on `show system processes extensive`), consider rebooting the Routing Engine as a last resort:
request system reboot (on RE0)
Post-Recovery Observation
After the RE0 reboot, system resource utilisation returned to normal, and the minor alarm cleared. Continued monitoring is advised to ensure the issue does not reoccur.
Additional Notes
If the above steps do not resolve the issue or if you're unable to determine the root cause, please provide the collected logs and outputs to Juniper Support for deeper analysis.