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:
You must configure at least one view (notify, read, or
write) at the [edit snmp view-name] hierarchy level.
[edit snmp] view view-name { oid object-identifier (include | exclude); } [edit snmp v3] notify name { tag tag-name; } notify-filter profile-name { oid object-identifier (include | exclude); } snmp-community community-index { security-name security-name; } target-address target-address-name { address address; target-parameters target-parameters-name; } target-parameters target-parameters-name { notify-filter profile-name; parameters { message-processing-model (v1 | v2c | v3); security-level (authentication | none | privacy); security-model (usm | v1 | v2c); security-name security-name; } } usm { local-engine { user username { } } } vacm { access { group group-name { (default-context-prefix | context-prefix context-prefix){ security-model (any | usm | v1 | v2c) { security-level (authentication | none | privacy) { notify-view view-name; read-view view-name; write-view view-name; } } } } } security-to-group { security-model (usm | v1 | v2c) { security-name security-name { group group-name; } } } }
Example: SNMPv3 Configuration
Define an SNMPv3 configuration:
[edit snmp]
engine-id {
use-mac-address;
}
view jnxAlarms {
oid 1.3.6.1.4.1.2636.3.4 include;
}
view interfaces {
oid 1.3.6.1.2.1.2 include;
}
view ping-mib {
oid 1.3.6.1.2.1.80 include;
}
[edit snmp v3]
notify n1 {
tag router1; # Identifies a set of target addresses
type trap;# Defines type of notification
}
notify n2 {
tag host1;
type trap;
}
notify-filter nf1 {
oid .1 include; # Defines which traps to send
} # In this case, includes all traps
notify-filter nf2 {
oid 1.3.6.1.4.1 include; # Sends enterprise-specific traps only
}
notify-filter nf3 {
oid 1.3.6.1.2.1.1.5 include; # Sends BGP traps only
}
snmp-community index1 {
community-name "$9$JOZi.QF/AtOz3"; # SECRET-DATA
security-name john; # Matches the security name at the target parameters
tag host1; # Finds the addresses that are allowed to be used with
}
target-address ta1 {# Associates the target address with the group
# san-francisco.
address 10.1.1.1;
address-mask 255.255.255.0; # Defines the range of addresses
port 162;
tag-list router1;
target-parameters tp1; # Applies configured target parameters
}
target-address ta2 {
address 10.1.1.2;
address-mask 255.255.255.0;
port 162;
tag-list host1;
target-parameters tp2;
}
target-address ta3 {
address 10.1.1.3;
address-mask 255.255.255.0;
port 162;
tag-list “router1 host1”;
target-parameters tp3;
}
target-parameters tp1 { # Defines the target parameters
notify-filter nf1; # Specifies which notify filter to apply
parameters {
message-processing-model v1;
security-model v1;
security-level none;
security-name john; # Matches the security name configured at the
} # [edit snmp v3 snmp-community community-index hierarchy level.
}
target-parameters tp2 {
notify-filter nf2;
parameters {
message-processing-model v1;
security-model v1;
security-level none;
security-name john;
}
}
target-parameters tp3 {
notify-filter nf3;
parameters {
message-processing-model v1;
security-model v1;
security-level none;
security-name john;
}
}
usm {
local-engine { # Defines authentication and encryption for SNMPv3 users
user john { # security-name john is defined here
authentication-md5 {
authentication-password authentication-password;
}
privacy-des {
privacy-password privacy-password;
}
}
user bob { # security-name bob is defined here
authentication-sha {
authentication-password authentication-password;
}
privacy-none;
}
user julia { # security-name julia is defined here
authentication-none;
privacy-none;
}
user lauren { # security-name lauren is defined here
authentication-sha {
authentication-password authentication-password;
}
privacy-aes128 {
privacy-password privacy-password;
}
}
user richard { # security-name richard is defined here
authentication-sha {
authentication-password authentication-password;
}
privacy-none;
}
}
}
vacm {
access {
group san-francisco { #Defines the access privileges for the group
default-context-prefix { # called san-francisco
security-model v1 {
security-level none {
notify-view ping-mib;
read-view interfaces;
write-view jnxAlarms;
}
}
}
}
}
security-to-group {
security-model v1 {
security-name john { # Assigns john to security group san-fancisco
group san-francisco;
}
security-name bob { # Assigns bob to security group new-york
group new-york;
}
security-name julia {# Assigns julia to security group chicago
group chicago;
}
security-name lauren {# Assigns lauren to security group paris
group paris;
}
security-name richard {# Assigns richard to security group geneva
group geneva;
}
}
}
}
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.
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:
[edit snmp v3 usm local-engine] user username;
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:
[edit snmp v3 usm local-engine user username] authentication-md5 { authentication-password authentication-password; } authentication-sha { authentication-password authentication-password; } authentication-none; privacy-aes128 { privacy-password privacy-password; } privacy-des { privacy-password privacy-password; } privacy-3des { privacy-password privacy-password; } privacy-none;
Example: Creating SNMPv3 Users
Define SNMPv3 users:
[edit]
snmp {
v3 {
usm {
local-engine {
user user1 {
authentication-md5 {
authentication-password authentication-password;
}
privacy-des {
privacy-password password;
}
}
user user2 {
authentication-sha {
authentication-password authentication-password;
}
privacy-none;
}
user user3 {
authentication-none;
privacy-none;
}
user user4 {
authentication-md5 {
authentication-password authentication-password;
}
privacy-des {
privacy-password authentication-password;
}
}
user user5 {
authentication-sha {
authentication-password authentication-password;
}
privacy-aes128 {
privacy-password authentication-password;
}
}
}
}
}
}
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:
[edit snmp v3 usm local-engine user username] authentication-md5 { authentication-password authentication-password; }
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:
[edit snmp v3 usm local-engine user username] authentication-sha { authentication-password authentication-password; }
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:
[edit snmp v3 usm local-engine user username] authentication-none;
Configuring the SNMPv3 Encryption Type
By default, encryption is set to none.
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
- Configuring the Data Encryption Algorithm
- Configuring Triple DES
- Configuring No Encryption
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:
[edit snmp v3 usm local-engine user username] privacy-aes128 { privacy-password privacy-password; }
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:
[edit snmp v3 usm local-engine user username] privacy-des { privacy-password privacy-password; }
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:
[edit snmp v3 usm local-engine user username] privacy-3des { privacy-password privacy-password; }
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:
[edit snmp v3 usm local-engine user username] privacy-none;
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:
[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) {
notify-view view-name;
read-view view-name;
write-view view-name;
}
}
}
}
}
security-to-group {
security-model (usm | v1 | v2c) {
security-name security-name {
group group-name;
}
}
}
Configuring the Access Privileges Granted to a Group
This topic includes the following sections:
- Configuring the Group
- Configuring the Security Model
- Configuring the Security Level
- Associating MIB Views with an SNMP User Group
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:
[edit snmp v3 vacm access] group group-name;
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:
[edit snmp v3 vacm access group group-name (default-context-prefix | context-prefix context-prefix)] security-model (any | usm | v1 | v2c);
any—Any security modelusm—SNMPv3 security modelv1—SNMPV1 security modelv2c—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:
[edit snmp v3 vacm access group group-name default-context-prefix security-model (any | usm | v1 | v2c)] security-level (authentication | none | privacy);
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
noneas your security level. If you are configuring the SNMPv3 security model (USM), use theauthentication,none, orprivacysecurity 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:
[edit snmp v3 vacm accessgroup group-name (default-context-prefix | context-prefix context-prefix)security-model (any | usm | v1 | v2c) security-level (authentication | none | privacy)] notify-view view-name; read-view view-name; write-view view-name;
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:
[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)] notify-view view-name;
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:
[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)] read-view view-name;
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:
[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)] write-view view-name;
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:
[edit snmp v3 vacm]
access {
group group1 {
default-context-prefix {
security-model usm { #Define an SNMPv3 security model
security-level privacy {
notify-view nv1;
read-view rv1;
write-view wv1;
}
}
}
context-prefix lr1/ri1{ # routing instance ri1 in logical system lr1
security-model usm {
security-level privacy {
notify-view nv1;
read-view rv1;
write-view wv1;
}
}
}
}
group group2 {
default-context-prefix {
security-model usm { #Define an SNMPv3 security model
security-level authentication {
read-view rv2;
write-view wv2;
}
}
}
}
group group3 {
default-context-prefix {
security-model v1 { #Define an SNMPv3 security model
security-level none {
read-view rv3;
write-view wv3;
}
}
}
}
}
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:
[edit snmp v3 vacm security-to-group] security-model (usm | v1 | v2c) { security-name security-name { group group-name; } }
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:
[edit snmp v3 vacm security-to-group] security-model (usm | v1 | v2c);
usm—SNMPv3 security modelv1—SNMPv1 security modelv2c—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:
[edit snmp v3 vacm security-to-group security-model (usm | v1 | v2c)] security-name security-name;
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.
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:
[edit snmp v3 vacm security-to-group security-model (usm | v1 | v2c) security-name security-name] group group-name;
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:
vacm {
security-to-group {
security-model usm {
security-name user1 {
group group1;
}
security-name user2 {
group group2;
}
security-name user3 {
group group3;
}
}
}
}
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.
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:
[edit snmp v3] notify name { tag tag-name; type trap; } notify-filter name { oid object-identifier (include | exclude); } target-address target-address-name { address address; address-mask address-mask; logical-system logical-system; port port-number; routing-instance instance; tag-list tag-list; target-parameters target-parameters-name; } target-parameters target-parameters-name { notify-filter profile-name; parameters { message-processing-model (v1 | v2c | v3); security-level (authentication | none | privacy); security-model (usm | v1 | v2c); security-name security-name; } }
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:
[edit snmp v3] notify name { tag tag-name; type trap; }
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.
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:
[edit snmp v3]
notify n1 {
tag router1;
type trap;
}
notify n2 {
tag router2;
type trap
}
notify n3 {
tag router3;
type trap;
}
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:
[edit snmp v3] notify-filter profile-name;
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:
[edit snmp v3 notify-filter profile-name] oid oid (include | exclude);
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.
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:
[edit snmp v3] target-address target-address-name;
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:
[edit snmp v3 target-address target-address-name] address address; address-mask address-mask; logical-system logical-system; port port-number; routing-instance instance; tag-list tag-list; target-parameters target-parameters-name;
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:
set policy-options prefix-list SNMP 10.1.1.1/32 set policy-options prefix-list SNMP 192.168.1.0/24 set firewall family inet filter CoPP term SNMP from source-prefix-list SNMP set firewall family inet filter CoPP term SNMP from protocol udp set firewall family inet filter CoPP term SNMP from destination-port snmp set firewall family inet filter CoPP term SNMP then accept set firewall family inet filter CoPP term SNMP then count SNMP
- Configuring the Address
- Configuring the Address Mask
- Configuring the Port
- Configuring the Routing Instance
- Configuring the Trap Target Address
- Applying Target Parameters
Configuring the Address
To configure the address, include the address statement at the [edit snmp v3 target-address target-address-name] hierarchy level:
[edit snmp v3 target-address target-address-name] address address;
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:
[edit snmp v3 target-address target-address-name] address-mask address-mask;
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:
[edit snmp v3 target-address target-address-name] port port-number;
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:
[edit snmp v3 target-address target-address-name] routing-instance instance;
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:
[edit snmp v3 target-address target-address-name] tag-list “tag-list”;
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.
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:
[edit snmp v3 target-address target-address-name] target-parameters target-parameters-name;
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.
[edit snmp v3]
notify n1 {
tag router1; # Identifies a set of target addresses
type trap; # Defines the type of notification
}
notify n2 {
tag router2;
type trap;
}
target-address ta1 {
address 10.1.1.1;
address-mask 255.255.255.0;
port 162;
tag-list router1;
target-parameters tp1;
}
target-address ta2 {
address 10.1.1.2;
address-mask 255.255.255.0;
port 162;
tag-list router2;
target-parameters tp2;
}
target-address ta3 {
address 10.1.1.3;
address-mask 255.255.255.0;
port 162;
tag-list “router1 router2”; #Define multiple tags in the target address tag list
target-parameters tp3;
}
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:
[edit snmp v3] target-parameters target-parameters-name;
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:
[edit snmp v3 target-parameters target-parameter-name] notify-filter profile-name; parameters { message-processing-model (v1 | v2c | v3); security-level (authentication | none | privacy); security-model (usm | v1 | v2c); security-name security-name; }
When you configure SNMP trap notifications for subscriber secure policy on MX Series routers, you must configure the parameters as follows:
Message-processing model:
v3Security level:
privacySecurity 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:
[edit snmp v3 target-parameters target-parameter-name] notify-filter profile-name;
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:
[edit snmp v3 target-parameters target-parameter-name parameters] message-processing-model (v1 | v2c | v3); security-level (authentication | none | privacy); security-model (usm | v1 | v2c); security-name security-name;
This section includes the following topics:
- Configuring the Message Processing Model
- Configuring the Security Model
- Configuring the Security Level
- Configuring the Security Name
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:
[edit snmp v3 target-parameters target-parameter-name parameters] message-processing-model (v1 | v2c | v3);
v1—SNMPv1 message processing modelv2c—SNMPv2c message processing modelv3—SNMPV3 message processing model
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:
[edit snmp v3 target-parameters target-parameter-name parameters] security-model (usm | v1 | v2c);
usm—SNMPv3 security modelv1—SNMPv1 security modelv2c—SNMPv2c security model
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:
[edit snmp v3 target-parameters target-parameter-name parameters] security-level (authentication | none | privacy);
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
noneas your security level. If you are configuring the SNMPv3 (USM) security model, use theauthenticationorprivacysecurity level.The
privacysecurity 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:
[edit snmp v3 target-parameters target-parameter-name parameters] security-name security-name;
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.
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.
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:
[edit snmp v3] notify name { tag tag-name; type (trap | inform); } target-address target-address-name { address address; address-mask address-mask; logical-system logical-system; port port-number; retry-count number; routing-instance instance; tag-list tag-list; target-parameters target-parameters-name; timeout seconds; } target-parameters target-parameters-name { notify-filter profile-name; parameters { message-processing-model (v1 | v2c | v3); security-level (authentication | none | privacy); security-model (usm | v1 | v2c); security-name security-name; } }
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.
[edit snmp v3]
notify n1 {
type inform;
tag tl1;
}
notify-filter nf1 {
oid .1.3 include;
}
target-address ta1 {
address 172.17.20.184;
retry-count 3;
tag-list tl1;
address-mask 255.255.255.0;
target-parameters tp1;
timeout 30;
}
target-parameters tp1 {
parameters {
message-processing-model v3;
security-model usm;
security-level privacy;
security-name u10;
}
notify-filter nf1;
}
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:
[edit snmp v3] usm { remote-engine engine-id { user username { authentication-md5 { authentication-key key; } authentication-none; authentication-sha { authentication-key key; } privacy-3des { privacy-key key; } privacy-aes128 { privacy-key key; } privacy-des { privacy-key key; } privacy-none; } } }
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.
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.
set usm remote-engine 800007E5804089071BC6D10A41 user u10 authentication-md5 authentication-key "qol67R%?" set usm remote-engine 800007E5804089071BC6D10A41 user u10 privacy-des privacy-key "m*72Jl9v"
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:
Configure the remote engine ID, username, and authentication type and password.
[edit snmp v3] user@host# set usm remote-engine 800007E5804089071BC6D10A41 user u10 authentication-md5 authentication-key "qol67R%?"
Configure the encryption type and privacy password.
You can configure only one encryption type per SNMPv3 user.
[edit snmp v3] user@host# set usm remote-engine 800007E5804089071BC6D10A41 user u10 privacy-des privacy-key "m*72Jl9v"
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.
[edit snmp v3]
user@ host# show
usm {
remote-engine 800007E5804089071BC6D10A41 {
user u10 {
authentication-md5 {
authentication-key "$9$Tz/teK8NdsLXk.f5n6p0ORev"; ## SECRET-DATA
}
privacy-des {
privacy-key "$9$/gyNCu1KvWdwYMWw2gJHkRhcrWx"; ## SECRET-DATA
}
}
}
}
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
Local engine ID: 80 00 0a 4c 01 0a ff 03 e3
Engine boots: 3
Engine time: 769187 seconds
Max msg size: 65507 bytes
Engine ID: 80 00 07 e5 80 40 89 07 1b c6 d1 0a 41
User Auth/Priv Storage Status
u10 md5/des nonvolatile active
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
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:
[edit snmp] engine-id { (local engine-id-suffix | use-default-ip-address | use-mac-address); }
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.
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:
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.
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:
[edit snmp v3] snmp-community community-index;
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:
[edit snmp v3 snmp-community community-index] community-name community-name; context context-name; security-name security-name; tag tag-name;
This section includes the following topics:
- Configuring the Community Name
- Configuring the Context
- Configuring the Security Names
- Configuring the Tag
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:
[edit snmp v3 snmp-community community-index] community-name community-name;
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 (“ “).
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:
[edit snmp v3 snmp-community community-index] context context-name;
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:
[edit snmp v3 snmp-community community-index] security-name security-name;
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.
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:
[edit snmp v3 snmp-community community-index] tag tag-name;
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.
set snmp-community index1 community-name "public" set snmp-community index1 security-name john set snmp-community index1 tag router1 set target-address ta1 address 10.1.1.1 set target-address ta1 address-mask 255.255.255.0 set target-address ta1 port 162 set target-address ta1 tag-list router1 set target-address ta1 target-parameters tp1
Procedure
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 .
Configure the SNMP community name.
[edit snmp v3] user@host# set snmp-community index1 community-name "public"
Note:The SNMP community name must be unique.
Configure the security name to perform access control.
[edit snmp v3] user@host# set snmp-community index1 security-name john
Define the tag name. The tag name identifies the address of managers that are allowed to use a community string.
[edit snmp v3] user@host# set snmp-community index1 tag router1
Configure SNMP target address.
[edit snmp v3] user@host# set target-address ta1 address 10.1.1.1
Configure the mask range of the address for the community string access control.
[edit snmp v3] user@host#set target-address ta1 address-mask 255.255.255.0
Configure SNMPv3 target port number.
[edit snmp v3] user@host#set target-address ta1 port 162
Configure SNMPv3 tag list to select the target addresses.
[edit snmp v3] user@host#set target-address ta1 tag-list router1
Configure SNMPv3 target parameter name in the target parameter table.
[edit snmp v3] user@host#set target-address ta1 target-parameters tp1
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.
[edit]
user@host# show snmp v3
target-address ta1 {
address 10.1.1.1;
port 162;
tag-list router1;
address-mask 255.255.255.0;
target-parameters tp1;
}
snmp-community index1 {
community-name "$9$JOZi.QF/AtOz3"; ## SECRET-DATA
security-name john;
tag router1;
}
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.
Community Security Context Tag Storage Status index1 john router1 nonvolatile active
Meaning
The output displays the information about SNMPv3 community being enabled on the system.