Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Tracing SNMP Activity

 

Monitoring SNMP Activity and Tracking Problems That Affect SNMP Performance on a Device Running Junos OS

The following sections contain information about monitoring the SNMP activity on devices running the Junos OS and identifying problems that might impact the SNMP performance on devices running Junos OS:

Checking for MIB Objects Registered with the snmpd

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:

user@host> show snmp registered-objects
user@host> file show /var/log/snmp_reg_objs
Note

The /var/log/snmp_reg_objs file contains only those objects that are associated with the Junos OS processes that are up and running and registered with the snmpd, at the time of executing 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.

Tracking SNMP Activity

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:

user@host> show log snmpd

Monitoring SNMP Statistics

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

user@host> show snmp statistics extensive

Checking CPU Utilization

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

user@host> show system processes extensive

Checking Kernel and Packet Forwarding Engine Response

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

user@host> show log mib2d | grep “kernel response time”

Tracing SNMP Activity on a Device Running Junos OS

SNMP tracing operations track activity for SNMP agents and record the information in log files. The logged error descriptions provide detailed information to help you solve problems faster.

By default, Junos OS does not trace any SNMP activity. If you include the traceoptions statement at the [edit snmp] hierarchy level, the default tracing behavior is:

  • Important activities are logged in files located in the /var/log directory. Each log is named after the SNMP agent that generates it. Currently, the following log files are created in the /var/log directory when the traceoptions statement is used:

    • chassisd

    • craftd

    • ilmid

    • mib2d

    • rmopd

    • serviced

    • snmpd

  • When a trace file named filename reaches its maximum size, it is renamed filename.0, then filename.1, and so on, until the maximum number of trace files is reached. Then the oldest trace file is overwritten. (For more information about how log files are created, see the System Log Explorer.)

  • Log files can be accessed only by the user who configured the tracing operation.

You cannot change the directory (/var/log) in which trace files are located. However, you can customize the other trace file settings by including the following statements at the [edit snmp] hierarchy level:

These statements are described in the following sections:

Configuring the Number and Size of SNMP Log Files

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).

Configuring Access to the Log File

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:

Configuring a Regular Expression for Lines to Be Logged

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:

Configuring the Trace Operations

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.

Table 1: SNMP Tracing Flags

Flag

Description

Default Setting

all

Log all operations.

Off

configuration

Log reading of the configuration at the [edit snmp] hierarchy level.

Off

database

Log events involving storage and retrieval in the events database.

Off

events

Log important events.

Off

general

Log general events.

Off

interface-stats

Log physical and logical interface statistics.

Off

nonvolatile-set

Log nonvolatile SNMP set request handling.

Off

pdu

Log SNMP request and response packets.

Off

policy

Log policy processing.

Off

protocol-timeouts

Log SNMP response timeouts.

Off

routing-socket

Log routing socket calls.

Off

server

Log communication with processes that are generating events.

Off

subagent

Log subagent restarts.

Off

timer

Log internal timer events.

Off

varbind-error

Log variable binding errors.

Off

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.

Example: Tracing SNMP Activity

Trace information about SNMP packets:

Configure the Certificate Expiration Trap

This topic shows how to configure certificate expiration trap and configure the number of days before to generate the trap.

Before you begin:

  1. Configure the number of days before to generate the trap for all certificates.
  2. Configure the number of days before to generate the trap for CA certificate.
  3. Configure the number of days before to generate the trap for local certificate.
  4. Confirm your configuration by entering the show security pki trap command.

Enable Peer Down and IPsec Tunnel Down Traps

This topic shows how to enable peer-down and ipsec-tunnel-down traps.

  1. Enable the IKE trap peer down. Trap gets generated when the peer is down.
  2. Enable the IKE trap IPsec tunnel down. Trap gets generated when the peer is up and the IPsec SA is down.
  3. Confirm your configuration by entering the show security ike trap command.