- play_arrow Overview
- play_arrow Operation, Administration, and Management Features
- play_arrow Ethernet OAM and Connectivity Fault Management for Routers
- Introduction to OAM Connectivity Fault Management (CFM)
- Configure Connectivity Fault Management (CFM)
- CFM Action Profile
- Ethernet Local Management Interface
- CFM Support for CCC Encapsulated Packets
- Configure Unified ISSU for 802.1ag CFM
- CFM Monitoring between CE and PE Devices
- Configure Continuity Check Messages
- Example: Configure Ethernet CFM on Physical Interfaces
- Example: Configure Ethernet CFM on Bridge Connections
- Example: Configure Ethernet CFM over VPLS
- play_arrow Link Fault Management for Routers
- play_arrow Ethernet OAM Link Fault Management for Switches
- play_arrow Ethernet OAM Connectivity Fault Management for Switches
- play_arrow Ethernet Frame Delay
- Ethernet Frame Delay Measurements on Switches
- Configure MEP Interfaces on Switches to Support Ethernet Frame Delay Measurements (CLI Procedure)
- Configure One-Way Ethernet Frame Delay Measurements on Switches (CLI Procedure)
- Configure an Iterator Profile on a Switch (CLI Procedure)
- Trigger an Ethernet Frame Delay Measurement Session on a Switch
- Configure Two-Way Ethernet Frame Delay Measurements on Switches (CLI Procedure)
- play_arrow Ethernet Service OAM (ITU-TY.1731) for Routers
- ITU-T Y.1731 Ethernet Service OAM Overview
- Configure Ethernet Frame Delay Measurement Sessions
- Configuring MEP Interfaces to Support Ethernet Frame Delay Measurements
- Configure Ethernet Frame Loss Measurement
- Configure an Iterator Profile
- Configure Ethernet Synthetic Loss Measurements
- Ethernet Alarm Indication
- Inline Transmission Mode
-
- play_arrow Remote Network Monitoring (RMON) with SNMP Alarms and Events
- play_arrow Accounting Options
- play_arrow Monitoring Options
- play_arrow Interface Alarms
- play_arrow IP Monitoring
- play_arrow sFlow Monitoring Technology
- play_arrow Adaptive Sampling for Routers and Switches
- play_arrow Packet Flow Accelerator Diagnostics Software
-
- play_arrow Monitoring Common Security Features
- play_arrow Performance Management
- play_arrow Port Mirroring
- play_arrow Port Mirroring and Analyzers
- Port Mirroring and Analyzers
- Configuring Port Mirroring and Analyzers
- Configuring Port Mirroring Instances
- Configuring Port Mirroring on Physical Interfaces
- Configuring Port Mirroring on Logical Interfaces
- Configuring Port Mirroring for Multiple Destinations
- Configuring Port Mirroring for Remote Destinations
- Configuring Port Mirroring Local and Remote Analysis
- 1:N Port Mirroring to Multiple Destinations on Switches
- Example: Configure Port Mirroring with Family any and a Firewall Filter
- Monitoring Port Mirroring
- Configure Packet Mirroring with Layer 2 Headers for Layer 3 Forwarded Traffic
- Troubleshooting Port Mirroring
-
- play_arrow System Log Messages
- play_arrow Network Management and Troubleshooting
- Compressing Troubleshooting Logs from /var/logs to Send to Juniper Networks Technical Support
- Monitoring and Troubleshooting
- Troubleshooting System Performance with Resource Monitoring Methodology
- Configuring Data Path Debugging and Trace Options
- Using MPLS to Diagnose LSPs, VPNs, and Layer 2 Circuits
- Using Packet Capture to Analyze Network Traffic
- On-Box Packet Sniffer Overview
- Troubleshooting Security Devices
- play_arrow Configuration Statements and Operational Commands
SNMP Communities
An SNMP community defines the level of authorization granted to its members, such as the available MIB objects, the operations (read-only or read-write) that are valid for those objects, and the authorized SNMP clients, based on their source IP addresses.
Configure SNMP Communities
Configuring the SNMP agent in Junos OS is a straightforward task that shares familiar settings with other managed devices in your network. For example, you need to configure Junos OS with an SNMP community string and a destination for traps. Community strings are administrative names that group collections of devices and the agents that are running on them together into common management domains. If a manager and an agent share the same community, they can communicate with each other.
The SNMP community string defines the relationship between an SNMP server system and the client system. This string is a password to control the client's access to the server.
To create a read-only SNMP community:
To create a read-write SNMP community:
Enter the SNMP community used in your network.
content_copy zoom_out_map[edit] user@host# set snmp community name
This example standard community string
private
to identify the community granted read-write access to the SNMP agent running on the device.content_copy zoom_out_map[edit] user@host# set snmp community private
Define the authorization level for the community.
content_copy zoom_out_map[edit snmp community name] user@host# set authorization authorization
This example confines the public community to read-only access. Any SNMP client (for example, an SNMP management system) that belongs to the public community can read MIB variables but cannot set (change) them.
content_copy zoom_out_map[edit snmp community public] user@host# set authorization read-write
Define a list of clients in the community who are authorized to make changes to the SNMP agent in Junos OS.
List the clients by IP address and prefix.
content_copy zoom_out_map[edit snmp community name] user@host# set clients address
For example:
content_copy zoom_out_map[edit snmp community private] user@host# set clients 192.168.1.15/24 user@host# set clients 192.168.1.18/24
Define the clients that are not authorized within the community by specifying their IP address, followed by the
restrict
statement.content_copy zoom_out_map[edit snmp community name] user@host# set clients address resrict
The following statement defines all other hosts as being restricted from the public community.
content_copy zoom_out_map[edit snmp community private] user@host# set clients 0/0 restrict
Commit the configuration.
content_copy zoom_out_mapuser@host# commit
Add a Group of Clients to an SNMP Community
Junos OS enables you to add one or more groups of clients to an SNMP community.
You can include the client-list-name name
statement at the [edit snmp community
community-name]
hierarchy level to add all the
members of the client list or prefix list to an SNMP community.
To define a list of clients, use the set snmp client-list
client-list-name
statement followed by the
IP addresses of the clients.
You can configure a prefix list at the [edit policy options]
hierarchy level. Support for prefix lists in the SNMP community configuration
enables you to use a single list to configure the SNMP and routing policies. For
more information about the prefix-list
statement, see the Routing Policies, Firewall Filters, and Traffic Policers User
Guide.
To add a client list or prefix list to an SNMP community, use the set
snmp commmunity community-name client-list-name
statement.
The client list and prefix list must not have the same name.
The following example shows how to define a client list:
[edit] snmp { client-list clentlist1 { 10.1.1.1/32; 10.2.2.2/32; } }
The following example shows how to add a client list to an SNMP community:
[edit] snmp { community community1 { authorization read-only; client-list-name clientlist1; } }
The following example shows how to add a prefix list to an SNMP community:
[edit] policy-options { prefix-list prefixlist { 10.3.3.3/32; 10.5.5.5/32; } } snmp { community community2 { client-list-name prefixlist; } }
Configure SNMP Community String
The SNMP community string defines the relationship between an SNMP server system and the client system. This string acts like a password to control the client’s access to the server.
To configure a community string in a Junos OS configuration, use the set snmp
community
statement.
If the community name contains spaces, enclose it in quotation marks (" ").
The default authorization level for a community is read-only
. To allow
Set
requests within a community, you need to define that
community as authorization read-write
. For Set
requests, you also need to include the specific MIB objects that are accessible with
read-write privileges using the view
statement. The default view
includes all supported MIB objects that are accessible with read-only privileges; no
MIB objects are accessible with read-write privileges. For more information about
the view
statement, see Configure
MIB Views.
The IP addresses of the clients (community members) that are allowed to use this community are
listed in the clients
statement lists. If no
clients
statement is present, all clients are allowed. For
address
, you must specify an IPv4
address, not a hostname. Include the default restrict
option to
deny access to all SNMP client’s for which access is not granted. We recommend
that you always include the default restrict
option to limit SNMP
client access to the local switch.
Community names must be unique within each SNMP system.
See Also
Examples: Configure the SNMP Community String
Grant read-only access to all clients. With the following
configuration, the system responds to SNMP Get
, GetNext
, and GetBulk
requests that contain the community string public
:
[edit] snmp { community public { authorization read-only; } }
Grant all clients read-write access to the ping MIB and jnxPingMIB
. With the following configuration, the system responds
to SNMP Get
, GetNext
, GetBulk
, and Set
requests that contain the community string private
and specify an OID contained in the ping MIB or jnxPingMIB
hierarchy:
[edit] snmp { view ping-mib-view { oid pingMIB include; oid jnxPingMIB include; community private { authorization read-write; view ping-mib-view; } } }
The following configuration allows read-only access to
clients with IP addresses in the range 1.2.3.4/24
,
and denies access to systems in the range fe80::1:2:3:4/64
:
[edit] snmp { community field-service { authorization read-only; clients { default restrict; # Restrict access to all SNMP clients not explicitly # listed on the following lines. 1.2.3.4/24; # Allow access by all clients in 1.2.3.4/24 except fe80::1:2:3:4/64 restrict;# fe80::1:2:3:4/64. } } }
Configure 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;
The following is a minimal set of sample configuration that is needed for snmp v3
snmp-community
configuration:
set snmp v3 vacm security-to-group security-model v2c security-name NOSNMPV3 group SNMPV3GROUP set snmp v3 vacm access group SNMPV3GROUP default-context-prefix security-model any security-level none read-view SNMPVIEW set snmp v3 vacm access group SNMPV3GROUP default-context-prefix security-model any security-level none write-view SNMPVIEW set snmp v3 snmp-community SNMPV3COMMUNITY community-name JTACCOMMUNITY set snmp v3 snmp-community SNMPV3COMMUNITY security-name NOSNMPV3 set snmp view SNMPVIEW oid .1 include
The community used by the user which does not support SNMPv3, will continue to use SNMPv2.
For more information, see the following configuration:
snmpget -v 2c -c JTACCOMMUNITY 10.52.170.100 sysUpTime.0
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. For more
information about this statement, see community-name.
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. For more information about this statement, see context (SNMPv3).
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.
For more information about this statement, see tag.
Example: Configure 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.
content_copy zoom_out_map[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.
content_copy zoom_out_map[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.
content_copy zoom_out_map[edit snmp v3] user@host# set snmp-community index1 tag router1
Configure SNMP target address.
content_copy zoom_out_map[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.
content_copy zoom_out_map[edit snmp v3] user@host#set target-address ta1 address-mask 255.255.255.0
Configure SNMPv3 target port number.
content_copy zoom_out_map[edit snmp v3] user@host#set target-address ta1 port 162
Configure SNMPv3 tag list to select the target addresses.
content_copy zoom_out_map[edit snmp v3] user@host#set target-address ta1 tag-list router1
Configure SNMPv3 target parameter name in the target parameter table.
content_copy zoom_out_map[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.