Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Configuring SNMPv3

 

Minimum SNMPv3 Configuration on a Device Running Junos OS

To configure the minimum requirements for SNMPv3, include the following statements at the [edit snmp v3] and [edit snmp] hierarchy levels:

Note

You must configure at least one view (notify, read, or write) at the [edit snmp view-name] hierarchy level.

Example: SNMPv3 Configuration

Define an SNMPv3 configuration:

Creating SNMPv3 Users

For each SNMPv3 user, you can specify the username, authentication type, authentication password, privacy type, and privacy password. After a user enters a password, a key based on the engine ID and password is generated and is written to the configuration file. After the generation of the key, the password is deleted from this configuration file.

Note

You can configure only one encryption type for each SNMPv3 user.

To create users, include the user statement at the [edit snmp v3 usm local-engine] hierarchy level:

username is the name that identifies the SNMPv3 user.

To configure user authentication and encryption, include the following statements at the [edit snmp v3 usm local-engine user username] hierarchy level:

Example: Creating SNMPv3 Users

Define SNMPv3 users:

Configuring the SNMPv3 Authentication Type

By default, in a Junos OS configuration the SNMPv3 authentication type is set to none.

This topic includes the following sections:

Configuring MD5 Authentication

To configure the message digest algorithm (MD5) as the authentication type for an SNMPv3 user, include the authentication-md5 statement at the [edit snmp v3 usm local-engine user username] hierarchy level:

authentication-password is the password used to generate the key used for authentication.

SNMPv3 has special requirements when you create plain-text passwords on a router or switch:

  • The password must be at least eight characters long.

  • The password can include alphabetic, numeric, and special characters, but it cannot include control characters.

Configuring SHA Authentication

To configure the secure hash algorithm (SHA) as the authentication type for an SNMPv3 user, include the authentication-sha statement at the [edit snmp v3 usm local-engine user username] hierarchy level:

authentication-password is the password used to generate the key used for authentication.

SNMPv3 has special requirements when you create plain-text passwords on a router or switch:

  • The password must be at least eight characters long.

  • The password can include alphabetic, numeric, and special characters, but it cannot include control characters.

Configuring No Authentication

To configure no authentication for an SNMPv3 user, include the authentication-none statement at the [edit snmp v3 usm local-engine user username] hierarchy level:

Configuring the SNMPv3 Encryption Type

By default, encryption is set to none.

Note

Before you configure encryption, you must configure MD5 or SHA authentication.

Before you configure the privacy-des, privacy-3des and privacy-aes128 statements, you must install the jcrypto package, and either restart the SNMP process or reboot the router.

This topic includes the following sections:

Configuring the Advanced Encryption Standard Algorithm

To configure the Advanced Encryption Standard (AES) algorithm for an SNMPv3 user, include the privacy-aes128 statement at the [edit snmp v3 usm local-engine user username] hierarchy level:

privacy-password is the password used to generate the key used for encryption.

SNMPv3 has special requirements when you create plain-text passwords on a router or switch:

  • The password must be at least eight characters long.

  • The password can include alphabetic, numeric, and special characters, but it cannot include control characters.

Configuring the Data Encryption Algorithm

To configure the data encryption algorithm (DES) for an SNMPv3 user, include the privacy-des statement at the [edit snmp v3 usm local-engine user username] hierarchy level:

privacy-password is the password used to generate the key used for encryption.

SNMPv3 has special requirements when you create plain-text passwords on a router or switch:

  • The password must be at least eight characters long.

  • The password can include alphabetic, numeric, and special characters, but it cannot include control characters.

Configuring Triple DES

To configure triple DES for an SNMPv3 user, include the privacy-3des statement at the [edit snmp v3 usm local-engine user username] hierarchy level:

privacy-password is the password used to generate the key used for encryption.

SNMPv3 has special requirements when you create plain-text passwords on a router or switch:

  • The password must be at least eight characters long.

  • The password can include alphabetic, numeric, and special characters, but it cannot include control characters.

Configuring No Encryption

To configure no encryption for an SNMPv3 user, include the privacy-none statement at the [edit snmp v3 usm local-engine user username] hierarchy level:

Defining Access Privileges for an SNMP Group

The SNMP version 3 (SNMPv3) uses the view-based access control model (VACM), which allows you to configure the access privileges granted to a group. Access is controlled by filtering the MIB objects available for a specific operation through a predefined view. You assign views to determine the objects that are visible for read, write, and notify operations for a particular group, using a particular context, a particular security model (v1, v2c, or usm), and particular security level (authenticated, privacy, or none). For information about how to configure views, see Configuring MIB Views.

You define user access to management information at the [edit snmp v3 vacm] hierarchy level. All access control within VACM operates on groups, which are collections of users as defined by USM, or community strings as defined in the SNMPv1 and SNMPv2c security models. The term security-name refers to these generic end users. The group to which a specific security name belongs is configured at the [edit snmp v3 vacm security-to-group] hierarchy level. That security name can be associated with a group defined at the [edit snmp v3 vacm security-to-group] hierarchy level. A group identifies a collection of SNMP users that share the same access policy. You then define the access privileges associated with a group at the [edit snmp v3 vacm access] hierarchy level. Access privileges are defined using views. For each group, you can apply different views depending on the SNMP operation; for example, read (get, getNext, or getBulk) write (set), notifications, the security level used (authentication, privacy, or none), and the security model (v1, v2c, or usm) used within an SNMP request.

You configure members of a group with the security-name statement. For v3 packets using USM, the security name is the same as the username. For SNMPv1 or SNMPv2c packets, the security name is determined based on the community string. Security names are specific to a security model. If you are also configuring VACM access policies for SNMPv1 or SNMPv2c packets, you must assign security names to groups for each security model (SNMPv1 or SNMPv2c) at the [edit snmp v3 vacm security-to-group] hierarchy level. You must also associate a security name with an SNMP community at the [edit snmp v3 snmp-community community-index] hierarchy level.

To configure the access privileges for an SNMP group, include statements at the [edit snmp v3 vacm] hierarchy level:

Configuring the Access Privileges Granted to a Group

This topic includes the following sections:

Configuring the Group

To configure the access privileges granted to a group, include the group statement at the [edit snmp v3 vacm access] hierarchy level:

group-name is a collection of SNMP users that belong to a common SNMP list that defines an access policy. Users belonging to a particular SNMP group inherit all access privileges granted to that group.

Configuring the Security Model

To configure the security model, include the security-model statement at the [edit snmp v3 vacm access group group-name (default-context-prefix | context-prefix context-prefix)] hierarchy level:

  • any—Any security model

  • usm—SNMPv3 security model

  • v1—SNMPV1 security model

  • v2c—SNMPv2c security model

Configuring the Security Level

To configure the access privileges granted to packets with a particular security level, include the security-level statement at the [edit snmp v3 vacm access group group-name (default-context-prefix | context-prefix context-prefix) security-model (any | usm | v1 | v2c)] hierarchy level:

  • none—Provides no authentication and no encryption.

  • authentication—Provides authentication but no encryption.

  • privacy—Provides authentication and encryption.

    Note

    Access privileges are granted to all packets with a security level equal to or greater than that configured. If you are configuring the SNMPv1 or SNMPv2c security model, use none as your security level. If you are configuring the SNMPv3 security model (USM), use the authentication, none, or privacy security level.

Associating MIB Views with an SNMP User Group

MIB views define access privileges for members of a group. Separate views can be applied for each SNMP operation (read, write, and notify) within each security model (usm, v1, and v2c) and each security level (authentication, none, and privacy) supported by SNMP.

To associate MIB views with an SNMP user group, include the following statements at the [edit snmp v3 vacm access group group-name (default-context-prefix | context-prefix context-prefix) security-model (any | usm | v1 | v2c) security-level (authentication | none | privacy)] hierarchy level:

Note

You must associate at least one view (notify, read, or write) at the [edit snmp v3 vacm access group group-name (default-context-prefix | context-prefix context-prefix) security-model (any | usm | v1 | v2c) security-level (authentication | none | privacy)] hierarchy level.

You must configure the MIB view at the [edit snmp view view-name] hierarchy level. For information about how to configure MIB views, see Configuring MIB Views.

This section describes the following topics related to this configuration:

Configuring the Notify View

To associate notify access with an SNMP user group, include the notify-view statement at the [edit snmp v3 vacm access group group-name (default-context-prefix | context-prefix context-prefix) security-model (any | usm | v1 | v2c) security-level (authentication | none | privacy)] hierarchy level:

view-name specifies the notify access, which is a list of notifications that can be sent to each user in an SNMP group. A view name cannot exceed 32 characters.

Configuring the Read View

To associate a read view with an SNMP group, include the read-view statement at the [edit snmp v3 vacm access group group-name (default-context-prefix | context-prefix context-prefix) security-model (any | usm | v1 | v2c) security-level (authentication | none | privacy)] hierarchy level:

view-name specifies read access for an SNMP user group. A view name cannot exceed 32 characters.

Configuring the Write View

To associate a write view with an SNMP user group, include the write-view statement at the [edit snmp v3 vacm access group group-name (default-context-prefix | context-prefix context-prefix) security-model (any | usm | v1 | v2c) security-level (authentication | none | privacy)] hierarchy level:

view-name specifies write access for an SNMP user group. A view name cannot exceed 32 characters.

Example: Configuring the Access Privileges Granted to a Group

Define access privileges:

Assigning Security Model and Security Name to a Group

To assign security names to groups, include the following statements at the [edit snmp v3 vacm security-to-group] hierarchy level:

This topic includes the following sections:

Configuring the Security Model

To configure the security model, include the security-model statement at the [edit snmp v3 vacm security-to-group] hierarchy level:

  • usm—SNMPv3 security model

  • v1—SNMPv1 security model

  • v2c—SNMPv2 security model

Assigning Security Names to Groups

To associate a security name with an SNMPv3 user, or a v1 or v2 community string, include the security-name statement at the [edit snmp v3 vacm security-to-group security-model (usm | v1 | v2c)] hierarchy level:

For SNMPv3, the security-name is the username configured at the [edit snmp v3 usm local-engine user username] hierarchy level. For SNMPv1 and SNMPv2c, the security name is the community string configured at the [edit snmp v3 snmp-community community-index] hierarchy level. For information about configuring usernames, see Creating SNMPv3 Users. For information about configuring a community string, see Configuring the SNMPv3 Community.

Note

The USM security name is separate from the SNMPv1 and SNMPv2c security name. If you support SNMPv1 and SNMPv2c in addition to SNMPv3, you must configure separate security names within the security-to-group configuration at the [edit snmp v3 vacm access] hierarchy level.

Configuring the Group

After you have created SNMPv3 users, or v1 or v2 security names, you associate them with a group. A group is a set of security names belonging to a particular security model. A group defines the access rights for all users belonging to it. Access rights define what SNMP objects can be read, written to, or created. A group also defines what notifications a user is allowed to receive.

If you already have a group that is configured with all of the view and access permissions that you want to give a user, you can add the user to that group. If you want to give a user view and access permissions that no other groups have, or if you do not have any groups configured, create a group and add the user to it.

To configure the access privileges granted to a group, include the group statement at the [edit snmp v3 vacm security-to-group security-model (usm | v1 | v2c) security-name security-name] hierarchy level:

group-name identifies a collection of SNMP security names that share the same access policy. For more information about groups, see Defining Access Privileges for an SNMP Group.

Example: Security Group Configuration

Assign security names to groups:

Configuring SNMPv3 Traps on a Device Running Junos OS

In SNMPv3, you create traps and informs by configuring the notify, target-address, and target-parameters parameters. Traps are unconfirmed notifications, whereas informs are confirmed notifications. This section describes how to configure SNMP traps. For information about configuring SNMP informs, see Configuring SNMP Informs.

The target address defines a management application’s address and parameters to be used in sending notifications. Target parameters define the message processing and security parameters that are used in sending notifications to a particular management target. SNMPv3 also lets you define SNMPv1 and SNMPv2c traps.

Note

When you configure SNMP traps, make sure your configured access privileges allow the traps to be sent. Access privileges are configured at the [edit snmp v3 vacm access] and [edit snmp v3 vacm security-to-group] hierarchy levels.

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

Configuring the SNMPv3 Trap Notification

The notify statement specifies the type of notification (trap) and contains a single tag. The tag defines a set of target addresses to receive a trap. The tag list contains one or more tags and is configured at the [edit snmp v3 target-address target-address-name] hierarchy level. If the tag list contains this tag, Junos OS sends a notification to all the target addresses associated with this tag.

To configure the trap notifications, include the notify statement at the [edit snmp v3] hierarchy level:

name is the name assigned to the notification.

tag-name defines the target addresses to which this notification is sent. This notification is sent to all the target-addresses that have this tag in their tag list. The tag-name is not included in the notification.

trap is the type of notification.

Note

Each notify entry name must be unique.

Junos OS supports two types of notification: trap and inform.

For information about how to configure the tag list, see Configuring the Trap Target Address.

Example: Configuring SNMPv3 Trap Notification

Specify three sets of destinations to send traps:

Configuring the Trap Notification Filter

SNMPv3 uses the notify filter to define which traps (or which objects from which traps) are sent to the network management system (NMS). The trap notification filter limits the type of traps that are sent to the NMS.

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). You can also use the wildcard character asterisk (*) in the object identifier (OID) to specify object identifiers that match a particular pattern.

To configure the trap notifications filter, include the notify-filter statement at the [edit snmp v3] hierarchy level:

profile-name is the name assigned to the notify filter.

By default, the OID is set to include. To define access to traps (or objects from traps), include the oid statement at the [edit snmp v3 notify-filter profile-name] hierarchy level:

oid is the object identifier. All MIB objects represented by this statement have the specified OID as a prefix. It can be specified either by a sequence of dotted integers or by a subtree name.

  • include—Include the subtree of MIB objects represented by the specified OID.

  • exclude—Exclude the subtree of MIB objects represented by the specified OID.

Configuring the Trap Target Address

The target address defines a management application’s address and parameters that are used in sending notifications. It can also identify management stations that are allowed to use specific community strings. When you receive a packet with a recognized community string and a tag is associated with it, Junos OS looks up all the target addresses with this tag and verifies that the source address of this packet matches one of the configured target addresses.

Note

You must configure the address mask when you configure the SNMP community.

To specify where you want the traps to be sent and define what SNMPv1 and SNMPv2cc packets are allowed, include the target-address statement at the [edit snmp v3] hierarchy level:

target-address-name is the string that identifies the target address.

To configure the target address properties, include the following statements at the [edit snmp v3 target-address target-address-name] hierarchy level:

Unlike with SNMP v2, In SNMPv3, there is no configuration option to limit inbound polling. But you can configure a lo0 filter to limit inbound polling by creating a rule to allow SNMP from your monitoring system IPs. For example:

Configuring the Address

To configure the address, include the address statement at the [edit snmp v3 target-address target-address-name] hierarchy level:

address is the SNMP target address.

Configuring the Address Mask

The address mask specifies a set of addresses that are allowed to use a community string and verifies the source addresses for a group of target addresses.

To configure the address mask, include the address-mask statement at the [edit snmp v3 target-address target-address-name] hierarchy level:

address-mask combined with the address defines a range of addresses. For information about how to configure the community string, see Configuring the SNMPv3 Community.

Configuring the Port

By default, the UDP port is set to 162. To configure a different port number, include the port statement at the [edit snmp v3 target-address target-address-name] hierarchy level:

port-number is the SNMP target port number.

Configuring the Routing Instance

Traps are sent over the default routing instance. To configure the routing instance for sending traps, include the routing-instance statement at the [edit snmp v3 target-address target-address-name] hierarchy level:

instance is the name of the routing instance. To configure a routing instance within a logical system, specify the logical system name followed by the routing instance name. Use a slash ( / ) to separate the two names (for example, test-lr/test-ri). To configure the default routing instance on a logical system, specify the logical system name followed by default (for example, test-lr/default).

Configuring the Trap Target Address

Each target-address statement can have one or more tags configured in its tag list. Each tag can appear in more than one tag list. When a significant event occurs on the network device, the tag list identifies the targets to which a notification is sent.

To configure the tag list, include the tag-list statement at the [edit snmp v3 target-address target-address-name] hierarchy level:

tag-list specifies one or more tags as a space-separated list enclosed within double quotes.

For an example of tag list configuration, see Example: Configuring the Tag List.

For information about how to specify a tag at the [edit snmp v3 notify notify-name] hierarchy level, see Configuring the SNMPv3 Trap Notification.

Note

When you configure SNMP traps, make sure your configured access privileges allow the traps to be sent. Configure access privileges at the [edit snmp v3 vacm access] hierarchy level.

Applying Target Parameters

The target-parameters statement at the [edit snmp v3] hierarchy level applies the target parameters configured at the [edit snmp v3 target-parameters target-parameters-name] hierarchy level.

To reference configured target parameters, include the target-parameters statement at the [edit snmp v3 target-address target-address-name] hierarchy level:

target-parameters-name is the name associated with the message processing and security parameters that are used in sending notifications to a particular management target.

Example: Configuring the Tag List

In the following example, two tag entries (router1 and router2) are defined at the [edit snmp v3 notify notify-name] hierarchy level. When an event triggers a notification, Junos OS sends a trap to all target addresses that have router1 or router2 configured in their target-address tag list. This results in the first two targets getting one trap each, and the third target getting two traps.

Defining and Configuring the Trap Target Parameters

Target parameters define the message processing and security parameters that are used in sending notifications to a particular management target.

To define a set of target parameters, include the target-parameters statement at the [edit snmp v3] hierarchy level:

target-parameters-name is the name assigned to the target parameters.

To configure target parameter properties, include the following statements at the [edit snmp v3 target-parameters target-parameter-name] hierarchy level:

Note

When you configure SNMP trap notifications for subscriber secure policy on MX Series routers, you must configure the parameters as follows:

  • Message-processing model: v3

  • Security level: privacy

  • Security model: usm

For more information about configuring subscriber secure policies, see Subscriber Secure Policy Overview.

This topic includes the following sections:

Applying the Trap Notification Filter

To apply the trap notification filter, include the notify-filter statement at the [edit snmp v3 target-parameters target-parameter-name] hierarchy level:

profile-name is the name of a configured notify filter. For information about configuring notify filters, see Configuring the Trap Notification Filter.

Configuring the Target Parameters

To configure target parameter properties, include the following statements at the [edit snmp v3 target-parameters target-parameter-name parameters] hierarchy level:

This section includes the following topics:

Configuring the Message Processing Model

The message processing model defines which version of SNMP to use when generating SNMP notifications. To configure the message processing model, include the message-processing-model statement at the [edit snmp v3 target-parameters target-parameter-name parameters] hierarchy level:

  • v1—SNMPv1 message processing model

  • v2c—SNMPv2c message processing model

  • v3—SNMPV3 message processing model

Note

The v3 message-processing model is required for subscriber secure policy on MX Series routers. See Subscriber Secure Policy Overview for more information.

Configuring the Security Model

To define the security model to use when generating SNMP notifications, include the security-model statement at the [edit snmp v3 target-parameters target-parameter-name parameters] hierarchy level:

  • usm—SNMPv3 security model

  • v1—SNMPv1 security model

  • v2c—SNMPv2c security model

Note

The usm security model is required for subscriber secure policy on MX Series routers. See Subscriber Secure Policy Overview for more information.

Configuring the Security Level

The security-level statement specifies whether the trap is authenticated and encrypted before it is sent.

To configure the security level to use when generating SNMP notifications, include the security-level statement at the [edit snmp v3 target-parameters target-parameter-name parameters] hierarchy level:

  • authentication—Provides authentication but no encryption.

  • none—No security. Provides no authentication and no encryption.

  • privacy—Provides authentication and encryption.

    Note

    If you are configuring the SNMPv1 or SNMPV2c security model, use none as your security level. If you are configuring the SNMPv3 (USM) security model, use the authentication or privacy security level.

    The privacy security level is required for subscriber secure policy on MX Series routers. See Subscriber Secure Policy Overview for more information.

Configuring the Security Name

To configure the security name to use when generating SNMP notifications, include the security-name statement at the [edit snmp v3 target-parameters target-parameter-name parameters] hierarchy level:

If the USM security model is used, the security-name identifies the user that is used when the notification is generated. If the v1 or v2c security models are used, security-name identifies the SNMP community used when the notification is generated.

Note

The access privileges for the group associated with a security name must allow this notification to be sent.

If you are using the v1 or v2 security models, the security name at the [edit snmp v3 vacm security-to-group] hierarchy level must match the security name at the [edit snmp v3 snmp-community community-index] hierarchy level.

Configuring SNMP Informs

Junos OS supports two types of notifications: traps and informs. With traps, the receiver does not send any acknowledgment when it receives a trap. Therefore, the sender cannot determine if the trap was received. A trap may be lost because a problem occurred during transmission. To increase reliability, an inform is similar to a trap except that the inform is stored and retransmitted at regular intervals until one of these conditions occurs:

  • The receiver (target) of the inform returns an acknowledgment to the SNMP agent.

  • A specified number of unsuccessful retransmissions have been attempted and the agent discards the inform message.

If the sender never receives a response, the inform can be sent again. Thus, informs are more likely to reach their intended destination than traps are. Informs use the same communications channel as traps (same socket and port) but have different protocol data unit (PDU) types.

Informs are more reliable than traps, but they consume more network, router, and switch resources (see Figure 1). Unlike a trap, an inform is held in memory until a response is received or the timeout is reached. Also, traps are sent only once, whereas an inform may be retried several times. Use informs when it is important that the SNMP manager receive all notifications. However, if you are more concerned about network traffic, or router and switch memory, use traps.

Figure 1: Inform Request and Response
Inform Request and Response

Configuring the Inform Notification Type and Target Address

To configure the inform notification type and target information, include the following statements at the [edit snmp v3] hierarchy level:

notify name is the name assigned to the notification. Each notify entry name must be unique.

tag tag-name defines the target addresses that are sent this notification. The notification is sent to all target addresses that have this tag in their tag list. The tag-name is not included in the notification. For information about how to configure the tag list, see Configuring the Trap Target Address.

type inform is the type of notification.

target-address target-address-name identifies the target address. The target address defines a management application’s address and parameters that are used to respond to informs.

timeout seconds is the number of seconds to wait for an acknowledgment. If no acknowledgment is received within the timeout period, the inform is retransmitted. The default timeout is 15 seconds.

retry-count number is the maximum number of times an inform is transmitted if no acknowledgment is received. The default is 3. If no acknowledgment is received after the inform is transmitted the maximum number of times, the inform message is discarded.

message-processing-model defines which version of SNMP to use when SNMP notifications are generated. Informs require a v3 message processing model.

security-model defines the security model to use when SNMP notifications are generated. Informs require a usm security model.

security-model defines the security model to use when SNMP notifications are generated. Informs require a usm security model.

security-level specifies whether the inform is authenticated and encrypted before it is sent. For the usm security model, the security level must be one of the following:

  • authentication—Provides authentication but no encryption.

  • privacy—Provides authentication and encryption.

security-name identifies the username that is used when generating the inform.

Example: Configuring the Inform Notification Type and Target Address

In the following example, target 172.17.20.184 is configured to respond to informs. The inform timeout is 30 seconds and the maximum retransmit count is 3. The inform is sent to all targets in the tl1 list. The security model for the remote user is usm and the remote engine username is u10.

Configuring the Remote Engine and Remote User

To send inform messages to an SNMPv3 user on a remote device, you must first specify the engine identifier for the SNMP agent on the remote device where the user resides. The remote engine ID is used to compute the security digest for authenticating and encrypting packets sent to a user on the remote host. When sending an inform message, the agent uses the credentials of the user configured on the remote engine (inform target).

To configure a remote engine and remote user to receive and respond to SNMP informs, include the following statements at the [edit snmp v3] hierarchy level:

For informs, remote-engine engine-id is the identifier for the SNMP agent on the remote device where the user resides.

For informs, user username is the user on a remote SNMP engine who receives the informs.

Informs generated can be unauthenticated, authenticated, or authenticated_and_encrypted, depending on the security level of the SNMPv3 user configured on the remote engine (the inform receiver). The authentication key is used for generating message authentication code (MAC). The privacy key is used to encrypt the inform PDU part of the message.

Example: Configuring the Remote Engine ID and Remote User

This example shows how to configure a remote engine and remote user so you can receive and respond to SNMP inform notifications. Inform notifications can be authenticated and encrypted. They are also more reliable than traps, another type of notification that Junos OS supports. Unlike traps, inform notifications are stored and retransmitted at regular intervals until one of these conditions occurs:

  • The target of the inform notification returns an acknowledgment to the SNMP agent.

  • A specified number of unsuccessful retransmissions have been attempted.

Requirements

No special configuration beyond device initialization is required before configuring this example.

This feature requires the use of plain-text passwords valid for SNMPv3. SNMPv3 has the following special requirements when you create plain-text passwords on a router or switch:

  • The password must be at least eight characters long.

  • The password can include alphabetic, numeric, and special characters, but it cannot include control characters.

Although quotation marks are not always required to enclose passwords, it is best to use them. You need quotation marks if the password contains any spaces or possibly in the case of certain special characters or punctuation.

Overview

Inform notifications are supported in SNMPv3 to increase reliability. For example, an SNMP agent receiving an inform notification acknowledges the receipt.

For inform notifications, the remote engine ID identifies the SNMP agent on the remote device where the user resides, and the username identifies the user on a remote SNMP engine who receives the inform notifications.

Consider a scenario in which you have the values in Table 1 to use in configuring the remote engine ID and remote user in this example.

Table 1: Values to Use in Example

Name of Variable

Value

username

u10

remote engine ID

800007E5804089071BC6D10A41

authentication type

authentication-md5

authentication password

qol67R%?

encryption type

privacy-des

privacy password

m*72Jl9v

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands and paste them into a text file, remove any line breaks and change any details necessary to match your network configuration, copy and paste these commands into the CLI at the [edit snmp v3] hierarchy level, and then enter commit from configuration mode.

Configuring the Remote Engine and Remote User

Step-by-Step Procedure

The following example requires that you navigate to various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide.

To configure the remote engine ID and remote user:

  1. Configure the remote engine ID, username, and authentication type and password.
  2. Configure the encryption type and privacy password.

    You can configure only one encryption type per SNMPv3 user.

Results

In configuration mode, confirm your configuration by entering the show command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

After you have confirmed that the configuration is correct, enter commit from configuration mode.

Verification

Verifying the Configuration of the Remote Engine ID and Username

Purpose

Verify the status of the engine ID and user information.

Action

Display information about the SNMPv3 engine ID and user.

user@host> show snmp v3

Meaning

The output displays the following information:

  • Local engine ID and detail about the engine

  • Remote engine ID (labeled Engine ID)

  • Username

  • Authentication type and encryption (privacy) type that is configured for the user

  • Type of storage for the username, either nonvolatile (configuration saved) or volatile (not saved)

  • Status of the new user; only users with an active status can use SNMPv3

See also

Configuring the Local Engine ID

By default, the local engine ID uses the default IP address of the router. The local engine ID is the administratively unique identifier for the SNMPv3 engine. This statement is optional. To configure the local engine ID, include the engine-id statement at the [edit snmp] hierarchy level:

  • local engine-id-suffix—The engine ID suffix is explicitly configured.

  • use-default-ip-address—The engine ID suffix is generated from the default IP address.

  • use-mac-address—The SNMP engine identifier is generated from the Media Access Control (MAC) address of the management interface on the router.

Note

If you are using SNMPv3 and if the engine ID is based on the MAC address and you upgrade from an earlier release to one of these releases (14.1X53-D50, 16.1R5, 17.1R2, 17.2R1, 15.1X53-D231, 14.1X53-D43, 15.1X53-D232), you must reconfigure SNMPv3 because the engine ID is changed by the upgrade. If you do not reconfigure SNMPv3, you will see authentication error for SNMPv3 polling because the engine ID is changed after the upgrade. You only need to reconfigure SNMPv3 on the first such upgrade. If you then upgrade from one of the mentioned releases to another of these releases, you do not have to upgrade SNMPv3 again.

To reconfigure SNMPv3, use the following procedure. Do not use the rollback 1 command.

To reconfigure SNMPv3:

  1. Check what the SNMPv3 configuration is.
  2. Delete the SNMPv3 configuration.
  3. Reconfigure SNMPv3 configuration (see ouput from Step 1).

The local engine ID is defined as the administratively unique identifier of an SNMPv3 engine, and is used for identification, not for addressing. There are two parts of an engine ID: prefix and suffix. The prefix is formatted according to the specifications defined in RFC 3411, An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks. You can configure the suffix here.

Note

SNMPv3 authentication and encryption keys are generated based on the associated passwords and the engine ID. If you configure or change the engine ID, you must commit the new engine ID before you configure SNMPv3 users. Otherwise, the keys generated from the configured passwords are based on the previous engine ID. For the engine ID, we recommend using the primary IP address of the device if the device has multiple routing engines and has the primary IP address configured. Alternatively, you can use the MAC address of the management port if the device has only one Routing Engine.

Configuring the SNMPv3 Community

The SNMP community defines the relationship between an SNMP server system and the client systems. This statement is optional.

To configure the SNMP community, include the snmp-community statement at the [edit snmp v3] hierarchy level:

community-index is the index for the SNMP community.

To configure the SNMP community properties, include the following statements at the [edit snmp v3 snmp-community community-index] hierarchy level:

This section includes the following topics:

Configuring the Community Name

The community name defines the SNMP community. The SNMP community authorizes SNMPv1 or SNMPv2c clients. The access privileges associated with the configured security name define which MIB objects are available and the operations (read, write, or notify) allowed on those objects.

To configure the SNMP community name, include the community-name statement at the [edit snmp v3 snmp-community community-index] hierarchy level:

community-name is the community string for an SNMPv1 or SNMPv2c community.

If unconfigured, it is the same as the community index.

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

Note

Community names must be unique. You cannot configure the same community name at the [edit snmp community] and [edit snmp v3 snmp-community community-index] hierarchy levels. The configured community name at the [edit snmp v3 snmp-community community-index] hierarchy level is encrypted. You cannot view the community name after you have configured it and committed your changes. In the command-line interface (CLI), the community name is concealed.

Configuring the Context

An SNMP context defines a collection of management information that is accessible to an SNMP entity. Typically, an SNMP entity has access to multiple contexts. A context can be a physical or logical system, a collection of multiple systems, or even a subset of a system. Each context in a management domain has a unique identifier.

To configure an SNMP context, include the context context-name statement at the [edit snmp v3 snmp-community community-index] hierarchy level:

Note

To query a routing instance or a logical system,

Configuring the Security Names

To assign a community string to a security name, include the security-name statement at the [edit snmp v3 snmp-community community-index] hierarchy level:

security-name is used when access control is set up. The security-to-group configuration at the [edit snmp v3 vacm] hierarchy level identifies the group.

Note

This security name must match the security name configured at the [edit snmp v3 target-parameters target-parameters-name parameters] hierarchy level when you configure traps.

Configuring the Tag

To configure the tag, include the tag statement at the [edit snmp v3 snmp-community community-index] hierarchy level:

tag-name identifies the address of managers that are allowed to use a community string.

Example: Configuring an SNMPv3 Community

This example shows how to configure an SNMPv3 community.

Requirements

No special configuration beyond device initialization is required before configuring this example.

Overview

This example demonstrates how to create an SNMPv3 community. Define the SNMP community name, specify security name to perform the access control, and define tag name which identifies the address of managers that are allowed to use a community string. The target address defines a management application's address and parameters that are used in sending notifications.



When the device receives a packet with a recognized community string and a tag is associated with that packet, the Junos software looks up all the target addresses with this tag and verifies that the source address of this packet matches one of the configured target addresses.



Specify where you want the traps to be sent and define what SNMPv1 and SNMPv2c packets are allowed. Specify target address name that identifies the target address, define the target address, mask range of address, port number, tag list, and target parameter.

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit snmp v3] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide .

  1. Configure the SNMP community name.
    Note

    The SNMP community name must be unique.

  2. Configure the security name to perform access control.
  3. Define the tag name. The tag name identifies the address of managers that are allowed to use a community string.
  4. Configure SNMP target address.
  5. Configure the mask range of the address for the community string access control.
  6. Configure SNMPv3 target port number.
  7. Configure SNMPv3 tag list to select the target addresses.
  8. Configure SNMPv3 target parameter name in the target parameter table.

Results

From configuration mode, confirm your configuration by entering the show snmp v3 command. If the output does not display the intended configuration, repeat the configuration instructions in this example.

Verification

Verifying SNMPv3 community

Purpose

Verify if SNMPv3 community is enabled.

Action

To verify SNMPv3 community configuration, enter show snmp v3 community command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Meaning

The output displays the information about SNMPv3 community being enabled on the system.