As it restarted, the routing protocol process (rpd), which controls the routing protocols that run on the router, could not process a route obtained from the kernel because the route contained references to objects that are no longer valid.
The RPD_KRT_KERNEL_BAD_ROUTE message is logged each time the routing protocol process is not able to process a route obtained from the kernel.
When an RPD_KRT_KERNEL_BAD_ROUTE event occurs, a message similar to the following is reported:
rpd: RPD_KRT_KERNEL_BAD_ROUTE: KRT: lost ifl xxx for route y.y.y.y
rpd: RPD_KRT_KERNEL_BAD_ROUTE: KRT Ifstate: lost ifl 75 for route (null)
The symptoms related to this error can vary. They might be as minor as the messages being added to the log file or as major as the routing protocol daemon (rpd) restarting. There might be core files created as part of this error.
The rpd process did not recognize or could not process some elements in the route message, such as the logical interface index or an address family.
Perform these steps to determine the cause and resolve the problem (if any):
1. Collect the show command output to help determine the cause of this message.
Capture the output to a file (in case you have to open a technical support case). To do this, configure each SSH client/terminal emulator to log your session.
show log messages
show system core-dumps
show krt queue
show route summary
2. Analyze the show command output. Look for any related events that occurred at or just before the RPD_KRT_KERNEL_BAD_ROUTE message. Check to see if any core files were generated at the same time as the log message.
3. If the RPD_KRT_KERNEL_BAD_ROUTE message occurred in connection with an upgrade or commit, this is expected, and rpd can probably solve the problem. Verify by checking the entry for the indicated route prefix in the forwarding table. If the prefix’s route and forwarding table entries are inconsistent, contact a technical support representative for instructions.
4. If this issue is time critical or if you will need a root cause analysis, then open a case with your technical support representative to troubleshoot further. Otherwise continue with the following steps to attempt to resolve the issue.
5. If a core file was generated, a case will need to be opened with your technical support representative to investigate the issue, and the core file will need to be uploaded to the Juniper FTP site under that case for analysis.
6. If there appears to be a stuck route in the krt queue output, then make any change to the configuration under the [chassis] hierarchy, and commit. For example, if GRES is configured, this can be deactivated. This will not affect routing, since it will restart the PFE listener process without restarting routing. The change can then be backed out with a rollback 1 command in configuration mode.
7. During a maintenance window, as it may impact transit traffic, try the following:
- If there are two or more Routing Engines and GRES is configured, try a
1commit full synchronize
- Try restarting the routing protocol daemon by running the command