This article describes the issue of the krt_sndrcv_nh_packet log messages being generated, when a MX router is upgraded to 11.4R4.

After upgrading a MX router to 11.4R4, the following messages are generated in log messages:

Sep 6 04:08:26 border1-rt-re1 rpd[1920]: krt_sndrcv_nh_packet: ack requested but did not get cookie - nhp 0x937494C type 20 nhid 1048584
Sep 6 23:48:35 border1-rt-re1 rpd[1920]: krt_sndrcv_nh_packet: ack requested but did not get cookie - nhp 0x9374A54 type 20 nhid 1048585


• This log message was added in 11.4R4, as a result of PR690690.


• When there is a change in the route/NH, RPD can request an acknowledgment from the kernel.


• A part of this process involves the kernel allocating memory for this ACK cookie. The message indicates that an ACK cookie was not created or allocated.

Check the KRT queue:

user@wsr1-rt-re1> show krt queue
Routing table add queue: 0 queued
Interface add/delete/change queue: 0 queued
High-priority multicast add/change: 0 queued
Indirect next hop add/change: 0 queued
MPLS add queue: 0 queued
Indirect next hop delete: 0 queued
High-priority deletion queue: 0 queued
MPLS change queue: 0 queued
High-priority change queue: 0 queued
High-priority add queue: 0 queued
Normal-priority indirect next hop queue: 0 queued
Normal-priority deletion queue: 0 queued
Normal-priority composite next hop deletion queue: 0 queued
Normal-priority change queue: 0 queued
Normal-priority add queue: 0 queued
Routing table delete queue: 0 queued

The above output will help to determine if any specific routes are getting stuck in the KRT queue. Ideally, no routes will be stuck in the KRT queue; if they are, start troubleshooting to check why the KRT queue is stuck and check the logs for additional messages, based on what the KRT queue is displaying.

If the customer has no impact, this is just a transient and harmless message, as per PR690690. The message could be due to a flood of route/NH changes or the resources were temporarily unavailable. This is common in scaled scenarios and in such cases, RPD should retry.

As long as the KRT queue does not get stuck, there is no cause for concern.