Configuring Basic SNMP

To configure complete SNMP features, include the following statements at the [edit] hierarchy level of the configuration:

To configure complete SNMP features, include the following statements at the [edit snmp] hierarchy level:

You can specify an administrative contact for each system being managed by SNMP. This name is placed into the MIB II sysContact object. To configure a contact name, include the contact statement at the [edit snmp] hierarchy level:

If the name contains spaces, enclose it in quotation marks (" ").

To define a system contact name that contains spaces:

You can specify the location of each system being managed by SNMP. This string is placed into the MIB II sysLocation object. To configure a system location, include the location statement at the [edit snmp] hierarchy level:

If the location contains spaces, enclose it in quotation marks (" ").

To specify the system location:

You can specify a description for each system being managed by SNMP. This string is placed into the MIB II sysDescription object. To configure a description, include the description statement at the [edit snmp] hierarchy level:

If the description contains spaces, enclose it in quotation marks (" ").

To specify the system description:

To set the system contact details:

Junos OS enables you to override the system name by including the name statement at the [edit snmp] hierarchy level:

If the name contains spaces, enclose it in quotation marks (" ").

To specify the system name override:

When a router or switch first receives an SNMP nonvolatile Set request, a Junos OS XML protocol session opens and prevents other users or applications from changing the candidate configuration (equivalent to the command-line interface [CLI] configure exclusive command). If the router does not receive new SNMP Set requests within 5 seconds (the default value), the candidate configuration is committed and the Junos OS XML protocol session closes (the configuration lock is released). If the router receives new SNMP Set requests while the candidate configuration is being committed, the SNMP Set request is rejected and an error is generated. If the router receives new SNMP Set requests before 5 seconds have elapsed, the commit-delay timer (the length of time between when the last SNMP request is received and the commit is requested) resets to 5 seconds.

By default, the timer is set to 5 seconds. To configure the timer for the SNMP Set reply and start of the commit, include the commit-delay statement at the [edit snmp nonvolatile] hierarchy level:

seconds is the length of the time between when the SNMP request is received and the commit is requested for the candidate configuration. For more information about the configure exclusive command and locking the configuration, see the Junos OS CLI User Guide .

By default, filtering duplicate get, getNext, and getBulk SNMP requests is disabled on devices running Junos OS. If a network management station retransmits a Get, GetNext, or GetBulk SNMP request too frequently to the router, that request might interfere with the processing of previous requests and slow down the response time of the agent. Filtering these duplicate requests improves the response time of the SNMP agent. Junos OS uses the following information to determine if an SNMP request is a duplicate:

• Source IP address of the SNMP request

• Source UDP port of the SNMP request

• Request ID of the SNMP request

To filter duplicate SNMP requests, include the filter-duplicates statement at the [edit snmp] hierarchy level:

The SNMP community string defines the relationship between an SNMP server system and the client systems. This string acts like a password to control the clients’ access to the server.

To create a read-only SNMP community:

The SNMP community string defines the relationship between an SNMP server system and the client systems. This string acts like a password to control the clients’ access to the server. To configure a community string in a Junos OS configuration, include the community statement at the [edit snmp] hierarchy level:

If the community name contains spaces, enclose it in quotation marks (" ").

The default authorization level for a community is read-only. To allow Set requests within a community, you need to define that community as authorization read-write. For Set requests, you also need to include the specific MIB objects that are accessible with read-write privileges using the view statement. The default view includes all supported MIB objects that are accessible with read-only privileges; no MIB objects are accessible with read-write privileges. For more information about the view statement, see Configuring MIB Views.

The clients statement lists the IP addresses of the clients (community members) that are allowed to use this community. If no clients statement is present, all clients are allowed. For address, you must specify an IPv4 address, not a hostname. Include the default restrict option to deny access to all SNMP clients for which access is not explicitly granted. We recommend that you always include the default restrict option to limit SNMP client access to the local switch.

Junos OS enables you to add one or more groups of clients to an SNMP community. You can include the client-list-name name statement at the [edit snmp community community-name] hierarchy level to add all the members of the client list or prefix list to an SNMP community.

To define a list of clients, include the client-list statement followed by the IP addresses of the clients at the [edit snmp] hierarchy level:

You can configure a prefix list at the [edit policy options] hierarchy level. Support for prefix lists in the SNMP community configuration enables you to use a single list to configure the SNMP and routing policies. For more information about the prefix-list statement, see the Routing Policies, Firewall Filters, and Traffic Policers User Guide.

To add a client list or prefix list to an SNMP community, include the client-list-name statement at the [edit snmp community community-name] hierarchy level:

The following example shows how to define a client list:

The following example shows how to add a client list to an SNMP community:

The following example shows how to add a prefix list to an SNMP community:

Starting with Release 12.3, Junos OS enables you to assign one of the devices in the network as a proxy SNMP agent through which the network management system (NMS) can query other devices in the network. When you configure a proxy, you can specify the names of devices to be managed through the proxy SNMP agent.

When the NMS queries the proxy SNMP agent, the NMS specifies the community name (for SNMPv1 and SNMPv2) or the context and security name (for SNMPv3) associated with the device from which it requires the information.

To configure a proxy SNMP agent and specify devices to be managed by the proxy SNMP agent, you can include the following configuration statements at the [edit snmp] hierarchy level:

• The proxy statement enables you to specify a unique name for the proxy configuration.

• The version-v1, version-v2c, and version-v3 statements enable you to specify the SNMP version.

• The no-default-comm-to-v3-config statement is an optional statement at the [edit snmp proxy proxy-name <version-v1 | version-v2c>] hierarchy level that when included in the configuration requires you to manually configure the statements at the [edit snmp v3 snmp-community community-name] and [edit snmp v3 vacm] hierarchy levels.

  If the no-default-comm-to-v3-config statement is not included at the [edit snmp proxy proxy-name <version-v1 | version-v2c>] hierarchy level, the [edit snmp v3 snmp-community community-name] and [edit snmp v3 vacm] hierarchy level configurations are automatically initialized.

• The logical-system and routing-instance statements are optional statements that enable you to specify logical system and routing instance names if you want to create proxies for logical systems or routing instances on the device.

You can use the show snmp proxy operational mode command to view proxy details on a device. The show snmp proxy command returns the proxy names, device names, SNMP version, community/security, and context information.

You can create and name a group of one or more types of SNMP traps and then define which systems receive the group of SNMP traps.. The name of the trap group is embedded in SNMP trap notification packets as one variable binding (varbind) known as the community name.

To configure an SNMP trap:

You can create and name a group of one or more types of SNMP traps and then define which systems receive the group of SNMP traps. The trap group must be configured for SNMP traps to be sent. To create an SNMP trap group, include the trap-group statement at the [edit snmp] hierarchy level:

The trap group name can be any string and is embedded in the community name field of the trap. To configure your own trap group port, include the destination-port statement. The default destination port is port 162.

For each trap group that you define, you must include the target statement to define at least one system as the recipient of the SNMP traps in the trap group. Specify the IPv4 or IPv6 address of each recipient, not its hostname.

Specify the types of traps the trap group can receive in the categories statement. For information about the category to which the traps belong, see the Standard SNMP Traps Supported by Junos OS and Enterprise-Specific SNMP Traps Supported by Junos OS topics.

Specify the routing instance used by the trap group in the routing-instance statement. All targets configured in the trap group use this routing instance.

A trap group can receive the following categories:

• authentication—Authentication failures

• chassis—Chassis or environment notifications

• chassis-cluster—Clustering notifications

• configuration—Configuration notifications

• link—Link-related notifications (up-down transitions, DS-3 and DS-1 line status change, IPv6 interface state change, and Passive Monitoring PIC overload)

  Note:

  To send Passive Monitoring PIC overload interface traps, select the link trap category.

• otn-alarms—OTN alarm trap subcategories

• remote-operations—Remote operation notifications

• rmon-alarm—Alarm for RMON events

• routing—Routing protocol notifications

• services—Services notifications such as circuit down or up, connection down or up, CPU exceeded, alarms, and status changes.

• sonet-alarms—SONET/SDH alarms

  Note:

  If you omit the SONET/SDH subcategories, all SONET/SDH trap alarm types are included in trap notifications.

  • loss-of-light—Loss of light alarm notification

  • pll-lock—PLL lock alarm notification

  • loss-of-frame—Loss of frame alarm notification

  • loss-of-signal—Loss of signal alarm notification

  • severely-errored-frame—Severely errored frame alarm notification

  • line-ais—Line alarm indication signal (AIS) alarm notification

  • path-ais—Path AIS alarm notification

  • loss-of-pointer—Loss of pointer alarm notification

  • ber-defect—SONET/SDH bit error rate alarm defect notification

  • ber-fault—SONET/SDH error rate alarm fault notification

  • line-remote-defect-indication—Line remote defect indication alarm notification

  • path-remote-defect-indication—Path remote defect indication alarm notification

  • remote-error-indication—Remote error indication alarm notification

  • unequipped—Unequipped alarm notification

  • path-mismatch—Path mismatch alarm notification

  • loss-of-cell—Loss of cell delineation alarm notification

  • vt-ais—Virtual tributary (VT) AIS alarm notification

  • vt-loss-of-pointer—VT loss of pointer alarm notification

  • vt-remote-defect-indication—VT remote defect indication alarm notification

  • vt-unequipped—VT unequipped alarm notification

  • vt-label-mismatch—VT label mismatch error notification

  • vt-loss-of-cell—VT loss of cell delineation notification

• startup—System warm and cold starts

• timing-events—Timing events and defects notification

• vrrp-events—Virtual Router Redundancy Protocol (VRRP) events such as new-primary or authentication failures

If you include SONET/SDH subcategories, only those SONET/SDH trap alarm types are included in trap notifications.

The version statement allows you to specify the SNMP version of the traps sent to targets of the trap group. If you specify v1 only, SNMPv1 traps are sent. If you specify v2 only, SNMPv2 traps are sent. If you specify all, both an SNMPv1 and an SNMPv2 trap are sent for every trap condition. For more information about the version statement, see version (SNMP).

By default, all router or switch interfaces have SNMP access privileges. To limit the access through certain interfaces only, include the interface statement at the [edit snmp] hierarchy level:

Specify the names of any logical or physical interfaces that should have SNMP access privileges. Any SNMP requests entering the router or switch from interfaces not listed are discarded.

Junos OS enables you to filter out information related to specific interfaces from the output of SNMP Get and GetNext requests performed on interface-related MIBs such as IF MIB, ATM MIB, RMON MIB, and the Juniper Networks enterprise-specific IF MIB.

You can use the following options of the filter-interfaces statement at the [edit snmp] hierarchy level to specify the interfaces that you want to exclude from SNMP Get and GetNext queries:

• interfaces—Interfaces that match the specified regular expressions.

• all-internal-interfaces—Internal interfaces.

Starting with Release 12.1, Junos OS provides an except option (! operator) that enables you to filter out all interfaces except those interfaces that match all the regular expressions prefixed with the ! mark.

For example, to filter out all interfaces except the ge interfaces from the SNMP get and get-next results, enter the following command:

When this is configured, Junos OS filters out all interfaces except the ge interfaces from the SNMP get and get-next results.

However, note that these settings are limited to SNMP operations, and the users can continue to access information related to the interfaces (including those hidden using the filter-interfaces options) using the appropriate Junos OS command-line interface (CLI) commands.

By default, an SNMP community grants read access and denies write access to all supported MIB objects (even communities configured as authorization read-write). To restrict or grant read or write access to a set of MIB objects, you must configure a MIB view and associate the view with a community.

To configure MIB views, include the view statement at the [edit snmp] hierarchy level:

The view statement defines a MIB view and identifies a group of MIB objects. Each MIB object of a view has a common object identifier (OID) prefix. Each object identifier represents a subtree of the MIB object hierarchy. The subtree can be represented either by a sequence of dotted integers (such as 1.3.6.1.2.1.2) or by its subtree name (such as interfaces). A configuration statement uses a view to specify a group of MIB objects on which to define access. You can also use a wildcard character asterisk (*) to include OIDs that match a particular pattern in the SNMP view. You need to use * for each sub-OIDs to match. For example, use OID interfaces.*.*.*.123 to match OID interfaces.2.1.2.123. Wildcard interfaces.*.123 will not match OID interfaces.2.1.2.123. To enable a view, you must associate the view with a community.

To remove an OID completely, use the delete view all oid oid-number command but omit the include parameter.

The following example creates a MIB view called ping-mib-view. The oid statement does not require a dot at the beginning of the object identifier. The snmp view statement includes the branch under the object identifier .1.3.6.1.2.1.80. This includes the entire DISMAN-PINGMIB subtree (as defined in RFC 2925, Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations), which effectively permits access to any object under that branch.

The following example adds a second branch in the same MIB view.

Assign a MIB view to a community that you want to control.

To associate MIB views with a community, include the view statement at the [edit snmp community community-name] hierarchy level:

For more information about the Ping MIB, see RFC 2925 and PING MIB.

Restrict the ping-mib community to read and write access of the Ping MIB and jnxpingMIB only. Read or write access to any other MIB using this community is not allowed.

The following configuration prevents the no-ping-mib community from accessing Ping MIB and jnxPingMIB objects. However, this configuration does not prevent the no-ping-mib community from accessing any other MIB object that is supported on the device.

Even though the Junos OS has built-in performance metrics and monitoring options, you might need to have customized performance metrics. To make it easier for you to monitor such customized data through a standard monitoring system, the Junos OS provides you with an enterprise-specific Utility MIB that can store such data and thus extend SNMP support for managing and monitoring the data of your choice.

The enterprise-specific Utility MIB provides you with container objects of the following types: 32-bit counters, 64-bit counters, signed integers, unsigned integers, and octet strings. You can use these container MIB objects to store the data that are otherwise not supported for SNMP operations. You can populate data for these objects either by using CLI commands or with the help of Op scripts and an RPC API that can invoke the CLI commands.

The following CLI commands enable you to set and clear Utility MIB object values:

• request snmp utility-mib set instance name object-type <counter | counter 64 | integer | string | unsigned integer> object-value value

• request snmp utility-mib clear instance name object-type <counter | counter 64 | integer | string | unsigned integer>

The instance name option of the request snmp utility-mib <set | clear> command specifies the name of the data instance and is the main identifier of the data. The object-type <counter | counter 64 | integer | string | unsigned integer> option enables you specify the object type, and the object-value value option enables you to set the value of the object.

To automate the process of populating Utility MIB data, you can use a combination of an event policy and event script. The following examples show the configuration for an event policy to run show system buffers every hour and to store the show system buffers data in Utility MIB objects by running an event script (check-mbufs.slax).

Event Policy Configuration

To configure an event policy that runs the show system buffers command every hour and invokes check-mbufs.slax to store the show system buffers data into Utility MIB objects, include the following statements at the [edit] hierarchy level:

check-mbufs.slax Script

The following example shows the check-mbufs.slax script that is stored under /var/db/scripts/event/:

You can run the following command to check the data stored in the Utility MIB as a result of the event policy and script shown in the preceding examples: