Tracing SNMP Activity

For the SNMP process to be able to access data related to a MIB object, the MIB object must be registered with the snmpd. When an SNMP subagent comes online, it tries to register the associated MIB objects with the snmpd. The snmpd maintains a mapping of the objects and the subagents with which the objects are associated. However, the registration attempt fails occasionally, and the objects remain unregistered with the snmpd until the next time the subagent restarts and successfully registers the objects.

When a network management system polls for data related to objects that are not registered with the snmpd, the snmpd returns either a noSuchName error (for SNMPv1 objects) or a noSuchObject error (for SNMPv2 objects).

You can use the following commands to check for MIB objects that are registered with the snmpd:

• show snmp registered-objects—Creates a /var/log/snmp_reg_objs file that contains the list of registered objects and their mapping to various subagents.

• file show /var/log/snmp_reg_objs—Displays the contents of the /var/log/snmp_reg_objs file.

The following example shows the steps for creating and displaying the /var/log/snmp_reg_objs file:

SNMP tracing operations track activity of SNMP agents and record the information in log files. The logged event descriptions provide detailed information to help you solve problems faster. By default, Junos OS does not trace any SNMP activity. To enable tracking of SNMP activities on a device running Junos OS, include the traceoptions statement at the [edit snmp] hierarchy level.

A sample traceoptions configuration might look like:

When the traceoptions flag all statement is included at the [edit snmp] hierarchy level, the following log files are created:

• snmpd

• mib2d

• rmopd

You can use the show log log-filename operational mode command to view the contents of the log file. In the snmpd log file (see the following example), a sequence of >>> represents an incoming packet, whereas a sequence of <<< represents an outgoing packet. Note that the request response pair might not follow any sequence if there are multiple network management systems polling the device at the same time. You can use the source and request ID combinations to match requests and responses. However, note that no response log is created in the log file if the SNMP master agent or the SNMP subagent has not responded to a request.

A careful analysis of the request-response time can help you identify and understand delayed responses.

Reviewing a Log File

The following example shows the output for the show log snmpd command:

The show snmp statistics extensive operational mode command provides you with an option to review SNMP traffic, including traps, on a device. Output for the show snmp statistics extensive command shows real-time values and can be used to monitor values such as throttle drops, currently active, max active, not found, time out, max latency, current queued, total queued, and overflows. You can identify slowness in SNMP responses by monitoring the currently active count, because a constant increase in the currently active count is directly linked to slow or no response to SNMP requests.

Sample Output for the show snmp statistics extensive Command

High CPU usage of the software processes that are being queried, such as snmpd or mib2d, is another factor that can lead to slow response or no response. You can use the show system processes extensive operational mode command to check the CPU usage levels of the Junos OS processes.

Sample Output of show system processes extensive Command

As mentioned in Understanding SNMP Implementation in Junos OS, some SNMP MIB data are maintained by the kernel or Packet Forwarding Engine. For such data to be available for the network management system, the kernel has to provide the required information to the SNMP subagent in mib2d. A slow response from the kernel can cause a delay in mib2d returning the data to the network management system. Junos OS adds an entry in the mib2d log file every time that an interface takes more than 10,000 microseconds to respond to a request for interface statistics. You can use the show log log-filename | grep “kernel response time” command to find out the response time taken by the kernel.

Checking the Kernel Response Time

By default, when the trace file reaches 128 kilobytes (KB) in size, it is renamed filename.0, then filename.1, and so on, until there are three trace files. Then the oldest trace file (filename.2) is overwritten.

You can configure the limits on the number and size of trace files by including the following statements at the [edit snmp traceoptions] hierarchy level:

For example, set the maximum file size to 2 MB, and the maximum number of files to 20. When the file that receives the output of the tracing operation (filename) reaches 2 MB, filename is renamed filename.0, and a new file called filename is created. When the new filename reaches 2 MB, filename.0 is renamed filename.1 and filename is renamed filename.0. This process repeats until there are 20 trace files. Then the oldest file (filename.19) is overwritten by the newest file (filename.0).

The number of files can be from 2 through 1000 files. The file size of each file can be from 10 KB through 1 gigabyte (GB).

By default, log files can be accessed only by the user who configured the tracing operation.

To specify that any user can read all log files, include the file world-readable statement at the [edit snmp traceoptions] hierarchy level:

To explicitly set the default behavior, include the file no-world-readable statement at the [edit snmp traceoptions] hierarchy level:

By default, the trace operation output includes all lines relevant to the logged activities.

You can refine the output by including the match statement at the [edit snmp traceoptions file filename] hierarchy level and specifying a regular expression (regex) to be matched:

By default, only important activities are logged. You can specify which trace operations are to be logged by including the following flag statement (with one or more tracing flags) at the [edit snmp traceoptions] hierarchy level:

Table 1 describes the meaning of the SNMP tracing flags.

To display the end of the log for an agent, issue the show log agentd | last operational mode command:

where agent is the name of an SNMP agent.