MIB2D_RTSLIB_READ_FAILURE

This article describes the following syslog message:

MIB2D_RTSLIB_READ_FAILURE

This message is reported into the system message file when a call by the management information base process (MIB2D) to a function in the routing socket library fails.

The MIB2D_RTSLIB_READ_FAILURE message is logged each time a call by MIB2D to a function in the routing socket library fails and is unable to get information from the kernel.

When the MIB2D process fails to get information from the kernel, it generates a message similar to the following

MIB2D_RTSLIB_READ_FAILURE: check_rtsock_rc: failed in reading ifls: 0 (Operation timed out)

MIB2D_RTSLIB_READ_FAILURE: check_rtsock_rc: failed in reading ifls: 0 (Invalid argument)

MIB2D_RTSLIB_READ_FAILURE:check_rtsock_rc: failed in reading lag_child, remote stats: 0 (Operation timed out)

MIB2D_RTSLIB_READ_FAILURE: get_counter_list: failed in reading counter names <xxx>: 38(No such file or directory)"

The MIB2D daemon might fail to get information from the kernel when the kernel is under load and is unable to send a response to the daemon. If the message occurs when kernel is busy, then this message is to be expected and can be ignored. The kernel also might not be able to respond to the MIB2D daemon if an interface is experiencing excessive physical errors or if there is an issue with the MIB2D daemon.

Perform these steps to determine the cause and resolve the problem (if any).

1. Collect the show command output on the Routing Engine.

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 | no-more
show interfaces extensive | no-more
show chassis routing-engine
show system processes extensive

2. Analyze the show log messages command output. How often do the messages occur?

Infrequently – If the message does not occur for every SNMP poll and is only seen once in a while, it should be harmless and might point to secondary issues, which can be ignored.
Frequently – If the message occurs with every poll and constantly, then try restarting the MIB2D process with the restart mib-process command.

Note: For more information on restarting a process, see Restart a JUNOS OS Process.

If the message continues to occur in the logs, proceed to Step 3.

3. Analyze the show interfaces extensive command output. Do any of the interfaces show an increase in physical errors (or excessive errors) that might cause the kernel to fail to respond to MIB2D requests?

Yes – Troubleshoot the physical errors to ensure that they are not the cause of the messages.
No – Continue to Step 4.

4. Analyze the show chassis routing-engine and show system processes extensive command outputs. Is the RE/Kernel CPU high?

Yes – Troubleshoot the RE/Kernel high CPU.
No – Continue with Step 5.

5. If these efforts do not resolve the problem, contact your technical support representative to investigate the issue further.

Related