Trace SNMP Activity

To access data related to a MIB object, the MIB object must be registered with the snmpd. When an SNMP subagent is online, it registers 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:

The /var/log/snmp_reg_objs file contains objects that are associated with the Junos OS processes which are registered with the snmpd. You can view the objects using the show snmp registered-objects command. If a MIB object related to a Junos OS process that is up and running is not shown in the list of registered objects, you might want to restart the software process to retry object registration with the snmpd.

SNMP tracing operations track activity of SNMP agents and record the information in log files. By default, Junos OS does not trace any SNMP activity. To enable tracking of SNMP activities on a device running Junos OS, include the set traceoptions flag all statement at the [edit snmp] hierarchy level.

The following log files are created:

• snmpd

• mib2d

• rmopd

You can use the show log log-filename operational 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. You can use the source and request ID combinations to match requests and responses, if there are multiple network management systems polling the device at the same time. Response log is not created in the log file if the SNMP master agent or the SNMP subagent has not responded to a request.

You can analyze the request-response time to identify and understand delayed responses.

You can review the log file using the show log snmpd command.

The show snmp statistics extensive operational 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.

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 command to check the CPU usage levels of the Junos OS processes.

As mentioned in Understand 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 reach 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.