Support Support Downloads Knowledge Base Juniper Support Portal Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

[MX] 'krt_sndrcv_nh_packet' log messages



Article ID: KB26918 KB Last Updated: 07 Mar 2013Version: 1.0
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.
Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search