Description

This article describes the cause for the rtslib_dfwsm_get_async_cb syslog message to be reported, and indicates whether any action must be taken to resolve the issue.

 

Symptoms

The following syslog messages are reported: 

Nov 20 09:30:40  router-re1 mib2d[22801]: %DAEMON-7: rtslib_dfwsm_get_async_cb: rtslib_dfwsm_get_async_cb:u_data:8c1ea68 k_usr_d:8c1ea68
Nov 20 09:30:40  router-re1 mib2d[22801]: %DAEMON-7: rtslib_dfwsm_get_async_cb: rtslib_dfwsm_get_async_cb:u_data:8c1eb08 k_usr_d:8c1eb08
Nov 20 09:30:40  router-re1 mib2d[22801]: %DAEMON-7: rtslib_dfwsm_get_async_cb: rtslib_dfwsm_get_async_cb:u_data:8c1eba8 k_usr_d:8c1eba8
Nov 20 09:30:41  router-re1 mib2d[22801]: %DAEMON-7: rtslib_dfwsm_get_async_cb: rtslib_dfwsm_get_async_cb:u_data:8c6d1a8 k_usr_d:8c6d1a8
Nov 20 09:30:41  router-re1 mib2d[22801]: %DAEMON-7: rtslib_dfwsm_get_async_cb: rtslib_dfwsm_get_async_cb:u_data:8c1ea68 k_usr_d:8c1ea68
Nov 20 09:30:41  router-re1 mib2d[22801]: %DAEMON-7: rtslib_dfwsm_get_async_cb: rtslib_dfwsm_get_async_cb:u_data:8c1eb08 k_usr_d:8c1eb08
Nov 20 09:30:42  router-re1 mib2d[22801]: %DAEMON-7: rtslib_dfwsm_get_async_cb: rtslib_dfwsm_get_async_cb:u_data:8c1eba8 k_usr_d:8c1eba8
Nov 20 09:30:42  router-re1 mib2d[22801]: %DAEMON-7: rtslib_dfwsm_get_async_cb: rtslib_dfwsm_get_async_cb:u_data:8c6d1a8 k_usr_d:8c6d1a8
Nov 20 09:30:42  router-re1 mib2d[22801]: %DAEMON-7: rtslib_dfwsm_get_async_cb: rtslib_dfwsm_get_async_cb:u_data:8c1ea68 k_usr_d:8c1ea68
Nov 20 09:30:43  router-re1 mib2d[22801]: %DAEMON-7: rtslib_dfwsm_get_async_cb: rtslib_dfwsm_get_async_cb:u_data:8c1eb08 k_usr_d:8c1eb08
Nov 20 09:30:43  router-re1 mib2d[22801]: %DAEMON-7: rtslib_dfwsm_get_async_cb: rtslib_dfwsm_get_async_cb:u_data:8c1eba8 k_usr_d:8c1eba8

 

Solution

These are syslog info level messages that are generated when the mib2d process gets a callback that data is available for it to read from the kernel. This is part of the asynchronous statistics gathering mechanism, which was introduced in Junos OS 14.1 via RLI/13174, and does not indicate a problem or that the kernel is busy.

When a request for firewall statistics is triggered by SNMP polling [for example, from a Network Management System (NMS)], the mib2d process generates a request to the kernel for those statistics and waits (not blocks) for a response. When the statistics are received from all the Packet Forwarding Engines (PFEs), the kernel notifies the mib2d process about them, which then reads them from the kernel and returns them to the SNMP polling devices (for example, the NMS).

 

These are informative messages that are logged when syslog is set to Info level. Depending on the polling rate, these could generate a large number of messages in the log file.

To prevent the log from filling up, add a filter at the syslog / archiving configuration as follows: 

syslog {
       user * {
           any emergency;
       }
        host <[SYSLOG_HOST_ADDRESS_1]> {
           any info;
           authorization none;
           firewall notice;
           match "!(.*UI_CHILD_START.*)|(.*UI_CHILD_STATUS.*)|(.*UI_CMDLINE_READ_LINE.*)|(rtslib_dfwsm_get_async_cb:*)";
           facility-override local7;
       }
 

For example: 

set system syslog host 192.20.110.24 match "!(.*UI_CHILD_START.*)|(.*UI_CHILD_STATUS.*)|(.*UI_CMDLINE_READ_LINE.*)|(rtslib_dfwsm_get_async_cb:*)“