There is a software bug in the Routing Protocol Daemon (RPD). This bug allows a bad network packet to trap the routing software in an infinite loop.

The issue happens when the router receives a network test packet (like an SRv6 LSP Ping or Traceroute). Inside this packet, the header details lie about its actual size. The packet is physically very small, but its internal header claims that the data is huge.

The router's software trusts this false size value when it tries to write system logs. Because the software looks for data that does not exist, it corrupts its own internal tracking memory. When the function tries to finish, it gets stuck in an infinite loop instead of exiting normally. This causes the RPD process to spike to 100% CPU utilization, making the routing engine unresponsive.

When this issue occurs, you will notice the following indicators on the device:

• High CPU Usage: The Routing Protocol Daemon (RPD) process suddenly spikes to 100% CPU utilization and remains permanently stuck.
• Unresponsive Routing Engine: The router stops responding to configuration commands, and routing protocols (like BGP, OSPF, or ISIS) drop or become unstable.
• Traffic Pattern: The issue is immediately preceded by the node receiving network diagnostic traffic, such as an LSP Ping or Traceroute, typically sent over UDP port 53 or UDP port 3503

Recovery Action Plan

If your device experiences this 100% CPU spike, follow these steps to restore services and collect necessary diagnostic data:

1. Perform a Routing Engine Switchover: If RE1 is the active master and its RPD process gets stuck at 100% CPU, immediately switch control over to the backup Routing Engine (RE0). This will quickly restore all routing protocols and network services.

2. Collect Debugging Data: While the issue is actively happening, run the following commands to collect critical state information for support teams:text

show task memory detail | no-more

show task memory | no-more

show task io | no-more

show task history | no-more

show task statistics | no-more

show task job | no-more

show task jobs | no-more

show krt queue | no-more

show krt state | no-more

show system processes extensive | no-more

show chassis routing-engine

show task replication

show log messages | last 100

Use code with caution.

3. Generate a Live RPD Core Dump: On the specific Routing Engine where the problem is reported, you can gather a core file using one of the two options below:

• Option A (Junos CLI): Run the following command

request system core-dump routing running

• Option B (Root Shell - Use if Option A fails): Log into the shell, find the running RPD process ID (PID), and force a core generation using gcore:text

root@router:~ # ps -aux | grep rpd

root  40625 100.0 5.3 6243244 5335176 - R  Wed09    444:11.22 /usr/libexec64/rpd -N

root@router:~ # gcore -s -c /var/tmp/rpd_live 40625

(Note: Once you trigger the gcore write command, the RPD process will remain at 100% CPU for an additional 2–3 minutes while the file is written to storage).

4. Restart Routing on the Backup RE: After completing the switchover, the original master (RE1) becomes the backup engine. However, its RPD process will remain stuck at 100% CPU loop. You must restart or reboot the routing process explicitly on RE1 to fully clear the stuck loop and bring the CPU usage back down to normal.