Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Configure Basic SNMP

Configure SNMP

You can implement SNMP in the Junos OS Software running on the QFX Series and OCX Series products. By default, SNMP is not enabled. To enable SNMP, you must include the SNMP configuration statements at the [edit] hierarchy level.

To configure the minimum requirements for SNMP, include the following statements at the [edit] hierarchy level of the configuration:

To configure complete SNMP features, see snmp.

Configuration Statements at the [edit snmp] Hierarchy Level

This topic shows all configuration statements at the [edit snmp] hierarchy level and their level in the configuration hierarchy. When you are configuring Junos OS, your current hierarchy level is shown in the banner on the line preceding the user@host# prompt.

Configure Basic Settings for SNMP

The following sections contain information about basic SNMP configuration and a few examples of configuring the basic SNMP operations on devices running Junos OS:

Configure Basic Settings for SNMPv1 and SNMPv2

You cannot enable SNMP on devices running Junos OS by default. To enable SNMP on devices running Junos OS, include the community public statement at the [edit  snmp] hierarchy level.

Enabling SNMPv1 and SNMPv2 Get and GetNext Operations

A community that is defined as public grants access to all MIB data to any client.

To enable SNMPv1 and SNMPv2 Set operations on the device, you must include the following statements at the [edit snmp] hierarchy level:

Enabling SNMPv1 and SNMPv2 Set Operations

The following example shows the basic minimum configuration for SNMPv1 and SNMPv2 traps on a device:

Configuring SNMPv1 and SNMPv2 Traps

Configure Basic Settings for SNMPv3

The following example shows the minimum SNMPv3 configuration for enabling Get, GetNext, and Set operations on a device (note that the configuration has authentication set to md5 and privacy to none):

Enabling SNMPv3 Get, GetNext, and Set Operations

The following example shows the basic configuration for SNMPv3 informs on a device (the configuration has authentication and privacy settings to none):

Configuring SNMPv3 Informs

You can convert the SNMPv3 informs to traps by setting the value of the type statement at the [edit snmp v3 notify N1_all_tl1_informs] hierarchy level to trap as shown in the following example:

Converting Informs to Traps

See Also

Configure SNMP Details

You can use SNMP to store basic administrative details, such as a contact name and the location of the device. Your management system can then retrieve this information remotely when you are troubleshooting an issue or performing an audit. In SNMP terminology, these are the sysName, sysContact, sysDescription, and sysLocation objects found within the system group of MIB-2 (as defined in RFC 1213, Management Information Base for Network Management of TCP/IP-based internets: MIB-II). You can set initial values directly in the Junos OS configuration for each system being managed by SNMP.

Note:

For the devices that are managed by SNMP, always keep the name, location, contact, and description information configured and updated.

To set the SNMP details:

  1. Configure a system name.
    Set the system name details by including the name statement at the [edit snmp] hierarchy level.

    For example:

  2. Configure a system contact.
    Set the system contact details by including the contact statement at the [edit snmp] hierarchy level, or in an appropriate configuration group as shown here.

    This administrative contact is placed into the MIB II sysContact object.

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

    For example:

  3. Configure a system description.

    This string is placed into the MIB II sysDescription object. If the description contains spaces, enclose it in quotation marks (" ").

    For example:

  4. Configure a system location.

    This string is placed into the MIB II sysLocation object. If the location contains spaces, enclose it in quotation marks (" ").

    To specify the system location:

    For example:

  5. At the top level of the configuration, apply the configuration group.

    If you use a configuration group, you must apply it for it to take effect.

  6. Commit the configuration.
  7. To verify the configuration, enter the show snmp mib walk system operational-mode command.

    The show snmp mib walk system command performs a MIB walk through of the system table (from MIB-2 as defined in RFC 1213). The SNMP agent in Junos OS responds by printing each row in the table and its associated value. You can use the same command to perform a MIB walk through any part of the MIB tree supported by the agent.

Optimize the Network Management System Configuration for the Best Results

You can modify your network management system configuration to optimize the response time for SNMP queries. The following sections contain a few tips on how you can configure the network management system:

Change the Polling Method from Column-by-Column to Row-by-Row

You can configure the network management system to use the row-by-row method for SNMP data polling. It is evident that row-by-row and multiple row-by-multiple-row polling methods are more efficient than column-by-column polling.

By configuring the network management system to use the row-by-row data polling method, you can:

  • Poll the data for only one interface in a request instead of a single request polling data for multiple interfaces as in the case with column-by-column polling.

  • Reduces the risk of requests timing out.

Reduce the Number of Variable Bindings per PDU

You can improve the response time for SNMP requests by reducing the number of variable bindings per protocol data unit (PDU). A request that polls for data related to multiple objects mapped to different index entries, translate into multiple requests at the device end. This is because the subagent might have to poll different modules to obtain data linked to different index entries.

The recommended method is to ensure that a request has only objects linked to one index entry instead of multiple objects linked to different index entries.

Note:

If responses from a device are slow, avoid using the GetBulk option for the device, because a GetBulk request might contain objects that are linked to various index entries and might further increase the response time.

snmp bulk-get recommended number of OIDs and max-repetitions

An SNMP bulk-get request responds with a total of (max-repetitions * number-of-OIDs) variable bindings. When interface statistics objects (such as ifInOctets, ifOutOctets, etc) are present in a query, the requests are sent to lower layers. Hence, there is an impact on the responses by an increase in the max-repetitions that you send in a bulk-get request. For bulk-get queries for interface stats objects, it is recommended to use the ‘max-repetitions’ value of 10, and the maximum number of OIDs per request is 10.

Increase Timeout Values in Polling and Discovery Intervals

By increasing the timeout values for polling and discovery intervals, you can:

  • Increase the queuing time at the device end.

  • Reduce the number of throttle drops that occur because of the request timing out.

Reduce Incoming Packet Rate at the snmpd

The following methods reduce the risk of SNMP requests piling up on any device.

  • Reduce the frequency of sending SNMP requests to a device.

  • Increase the polling interval.

  • Control the use of GetNext requests.

  • Reduce the number of polling stations per device.

See Also

Configure Options on Managed Devices for Better SNMP Response Time

The following sections contain information about configuration options on the managed devices that can enhance SNMP performance:

Enable the stats-cache-lifetime Option

Junos OS provides you with an option to configure the length of time (in seconds) the interface stats are cached. If the NMS queries again for the same interface within the cache time, the same data is returned. If the NMS queries after the cache time, the cache is no longer valid, fresh data is fetched from the lower layers, and the cache timestamp is updated. The default stats-cache-lifetime is 5 seconds. This can be tuned as per the polling frequency.

Note:

Reducing the value of the stats-cache-lifetime option results in more queries and can impact performance. To get the live uncached statistics, set the value of the stats-cache-lifetime option to 0. However, this is not recommended since it completely disables the caching feature and impacts performance.

Filter Out Duplicate SNMP Requests

If a network management station retransmits a Get, GetNext, or GetBulk SNMP request too frequently to a device, that request might interfere with the processing of previous requests and slow down the response time of the agent. Filtering these duplicate requests improves the response time of the SNMP agent. The Junos OS enables you to filter out duplicate Get, GetNext, and GetBulk SNMP requests. The Junos OS uses the following information to determine if an SNMP request is a duplicate:

  • Source IP address of the SNMP request

  • Source UDP port of the SNMP request

  • Request ID of the SNMP request

Note:

By default, filtering of duplicate SNMP requests is disabled on devices running the Junos OS.

To enable filtering of duplicate SNMP requests on devices running the Junos OS, include the filter-duplicates statement at the [edit snmp] hierarchy level:

Exclude Interfaces That Are Slow in Responding to SNMP Queries

An interface that is slow in responding to SNMP requests for interface statistics can delay the kernel responses to SNMP requests. You can review the mib2d log file to find out how long the kernel takes to respond to various SNMP requests. For more information about reviewing the log file for the kernel response data, see “Checking Kernel and Packet Forwarding Engine Response” under Monitoring SNMP Activity and Tracking Problems That Affect SNMP Performance on a Device Running Junos OS.

If you notice that a particular interface is slow in responding and think that it is slowing down the kernel from responding to SNMP requests, exclude that interface from the SNMP queries to the device. You can exclude an interface from the SNMP queries either by configuring the filter-interface statement or by modifying the SNMP view settings.

The following example shows a sample configuration for excluding interfaces from the SNMP Get, GetNext, and Set operations:

The following example shows the SNMP view configuration for excluding the interface with an interface index (ifIndex) value of 312 from a request for information related to the ifTable and ifXtable objects:

Alternatively, you can take the interface that is slow in responding offline.

See Also

Configure SNMP on a Device Running Junos OS

By default, SNMP is disabled on devices running Junos OS. To enable SNMP on a router or switch, you must include the SNMP configuration statements at the [edit snmp] hierarchy level.

To configure the minimum requirements for SNMP, include the following statements at the [edit snmp] hierarchy level of the configuration:

The community defined here as public grants read access to all MIB data to any client.

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

See Also

Example: Configure SNMP on the QFabric System

By default, SNMP is disabled on devices running Junos OS. This example describes the steps for configuring SNMP on the QFabric system.

Requirements

This example uses the following hardware and software components:

  • Junos OS Release 12.2

  • Network management system (NMS) (running the SNMP manager)

  • QFabric system (running the SNMP agent) with multiple Node devices

Overview

Because SNMP is disabled by default on devices running Junos OS, you must enable SNMP on your device by including configuration statements at the [edit snmp] hierarchy level. At a minimum, you must configure the community public statement. The community defined as public grants read-only access to MIB data to any client.

If no clients statement is configured, all clients are allowed. We recommend that you always include the restrict option to limit SNMP client access to the switch.

Topology

The network topology in this example includes an NMS, a QFabric system with four Node devices, and external SNMP servers that are configured for receiving traps.

Configuration

Procedure

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, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Step-by-Step Procedure

The following example requires that you 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 .

To configure SNMP on the QFabric system:

Note:

If the name, description, location, contact, or community name contains spaces, enclose the text in quotation marks (" ").

  1. Configure the SNMP system name:

    Note:

    The above configured SNMP system name can be accessed:

    • By doing a query with the SNMPGet on policy object identifier (OID) sysName.0.

    • From the generic jnxSyslogTrap. To send the jnxSyslogTrap, configure the trap events at [edit event-options policy] hierarchy.

  2. Specify a description.

    This string is placed into the MIB II sysDescription object.

  3. Specify the physical location of the QFabric system.

    This string is placed into the MIB II sysLocation object.

  4. Specify an administrative contact for the SNMP system.

    This name is placed into the MIB II sysContact object.

  5. Specify a unique SNMP community name and the read-only authorization level.

    Note:

    The read-write option is not supported on the QFabric system.

  6. Create a client list with a set of IP addresses that can use the SNMP community.

  7. Specify IP addresses of clients that are restricted from using the community.

  8. Configure a trap group, destination port, and a target to receive the SNMP traps in the trap group.

    Note:

    You do not need to include the destination-port statement if you use the default port 162.

    The trap group qf-traps is configured to send traps to 192.168.0.100.

Results

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

If you are done configuring the device, enter commit from configuration mode.

See Also

Configure the Commit Delay Timer

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

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

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

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.

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.

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 create a read-only SNMP community:

  1. Enter the SNMP community used in your network.

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

    Community names must be unique.

    Note:

    You cannot configure the same community name at the [edit snmp community] and [edit snmp v3 snmp-community community-index] hierarchy levels.

    This example uses the standard name public to create a community that gives limited read-only access.

  2. Define the authorization level for the community.

    The default authorization level for a community is read-only.

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

    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.

  3. Define a list of clients in the community who are authorized to communicate with the SNMP agent in Junos OS.

    The clients statement lists the IP addresses of the clients (community members) that are allowed to use this community. List the clients by IP address and prefix. Typically, the list includes the SNMP network management system in your network or the address of your management network. If no clients statement is present, all clients are allowed. For address, you must specify an IPv4 or IPv6 address, not a hostname.

    The following statement defines the hosts in the 192.168.1.0/24 network as being authorized in the public community.

  4. Define the clients that are not authorized within the community by specifying their IP address, followed by the restrict statement.

    The following statement defines all other hosts as being restricted from the public community.

  5. At the top level of the configuration, apply the configuration group.

    If you use a configuration group, you must apply it for it to take effect.

  6. Commit the configuration.

To create a read-write SNMP community:

  1. Enter the SNMP community used in your network.

    This example standard community string private to identify the community granted read-write access to the SNMP agent running on the device.

  2. Define the authorization level for the community.

    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.

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

    For example:

  4. Define the clients that are not authorized within the community by specifying their IP address, followed by the restrict statement.

    The following statement defines all other hosts as being restricted from the public community.

  5. At the top level of the configuration, apply the configuration group.

    If you use a configuration group, you must apply it for it to take effect.

  6. Commit the configuration.

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, include the client-list statement followed by the IP addresses of the clients at the [edit snmp] hierarchy level:

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

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

Note:

The client list and prefix list must not have the same name.

The following example shows how to define a client list:

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

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

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, include the community statement at the [edit snmp] hierarchy level:

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

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

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

Note:

Community names must be unique within each SNMP system.

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:

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:

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:

Configure a Proxy SNMP Agent

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

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

Note:

If you have configured authentication and privacy methods and passwords for SNMPv3, those parameters are also specified in the query for SNMPv3 information.

To configure a proxy SNMP agent and specify devices to be managed by the proxy SNMP agent, see proxy (snmp).

Note:

Starting with Junos OS Release 15.2, you must configure the interface <interface-name> statement at the [edit snmp] hierarchy level for the proxy SNMP agent.

Note:

The community and security configurations for the proxy should match the corresponding configurations on the device that is to be managed.

Note:

The devices managed by the proxy SNMP agent send the traps directly to the network management system since the proxy SNMP agent does not have trap-forwarding capabilities.

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

Configure SNMP Traps

Traps are unsolicited messages sent from an SNMP agent to remote network management systems, or trap receivers. Enterprises use SNMP traps as part of a fault-monitoring solution in addition to system logging. In Junos OS, you must configure a trap-group if you wish to use SNMP traps.

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

To configure an SNMP trap:

  1. Create a single, consistent source address that Junos OS applies to all outgoing traps in your device.

    A source address is useful, because although most Junos OS devices have several outbound interfaces, using one source address helps a remote NMS to associate the source of the traps with an individual device

    This example uses the IP address of the loopback interface (lo0) as the source address for all the SNMP traps that originate from the device.

  2. Create a trap group in which you can list the types of traps to be forwarded and the targets (addresses) of the receiving remote management systems.

    This example creates a trap group called managers, allows SNMP version 2-formatted notifications (traps) to be sent to the host at address 192.168.1.15. This statement forwards all categories of traps.

  3. Define the specific subset of trap categories to be forwarded.

    For a list of categories, see Configuring SNMP Trap Groups.

    The following statement configures the standard MIB-II authentication failures on the agent (the device).

  4. At the top level of the configuration, apply the configuration group.

    If you use a configuration group, you must apply it for it to take effect.

  5. Commit the configuration.
  6. To verify the configuration, generate an authentication failure trap.

    This means that the SNMP agent received a request with an unknown community. Other traps types can also be spoofed as well.

    This feature enables you to trigger SNMP traps from routers and ensure that they are processed correctly within your existing network management infrastructure. This is also useful for testing and debugging SNMP behavior on the switch or NMS.

    Using the monitor traffic command, you can verify that the trap is sent to the network management system.

Configure SNMP Trap Options

Using SNMP trap options, you can set the source address of every SNMP trap packet sent by the router to a single address regardless of the outgoing interface. In addition, you can set the agent address of the SNMPv1 traps. For more information about the contents of SNMPv1 traps, see RFC 1157.

Note:

SNMP cannot be associated with any routing instances other than the master routing instance.

To configure SNMP trap options, see trap-options.

You must also configure a trap group for the trap options to take effect. For information about trap groups, see Configuring SNMP Trap Groups.

This topic contains the following sections:

Configure the Source Address for SNMP Traps

You can configure the source address of trap packets in many ways: lo0, a valid IPv4 address or IPv6 address configured on one of the router interfaces, a logical-system address, or the address of a routing-instance. The value lo0 indicates that the source address of the SNMP trap packets is set to the lowest loopback address configured on the interface lo0.

Note:

If the source address is an invalid IPv4 or IPv6 address or is not configured, SNMP traps are not generated.

You can configure the source address of trap packets in one of the following formats:

  • A valid IPv4 address configured on one of the router interfaces

  • A valid IPv6 address configured on one of the router interfaces

  • lo0; that is, the lowest loopback address configured on the interface lo0

  • A logical-system name

  • A routing-instance name

A Valid IPv4 Address As the Source Address

To specify a valid IPv4 interface address as the source address for SNMP traps on one of the router interfaces, include the source-address statement at the [edit snmp trap-options] hierarchy level:

address is a valid IPv4 address configured on one of the router interfaces.

A Valid IPv6 Address As the Source Address

To specify a valid IPv6 interface address as the source address for SNMP traps on one of the router interfaces, include the source-address statement at the [edit snmp trap-options] hierarchy level:

address is a valid IPv6 address configured on one of the router interfaces.

The Lowest Loopback Address As the Source Address

To specify the source address of the SNMP traps so that they use the lowest loopback address configured on the interface lo0 as the source address, include the source-address statement at the [edit snmp trap-options] hierarchy level:

To enable and configure the loopback address, include the address statement at the [edit interfaces lo0 unit 0 family inet] hierarchy level:

To configure the loopback address as the source address of trap packets:

In this example, the IP address 10.0.0.1 is the source address of every trap sent from this router.

Logical System Name as the Source Address

To specify a logical system name as the source address of SNMP traps, include the logical-system logical-system-name statement at the [edit snmp trap-options] hierarchy level.

For example, the following configuration sets logical system name ls1 as the source address of SNMP traps:

Routing Instance Name as the Source Address

To specify a routing instance name as the source address of SNMP traps, include the routing-instance routing-instance-name statement at the [edit snmp trap-options] hierarchy level.

For example, the following configuration sets the routing instance name ri1 as the source address for SNMP traps:

Configure the Agent Address for SNMP Traps

The agent address is only available in SNMPv1 trap packets (see RFC 1157). By default, the router’s default local address is not specified in the agent address field of the SNMPv1 trap. To configure the agent address, include the agent-address statement at the [edit snmp trap-options] hierarchy level. Currently, the agent address can only be the address of the outgoing interface:

To configure the outgoing interface as the agent address:

In this example, each SNMPv1 trap packet sent has its agent address value set to the IP address of the outgoing interface.

Add snmpTrapEnterprise Object Identifier to Standard SNMP Traps

The snmpTrapEnterprise object helps you identify the enterprise that has defined the trap. Typically, the snmpTrapEnterprise object appears as the last varbind in enterprise-specific SNMP version 2 traps. However, starting Release 10.0, Junos OS enables you to add the snmpTrapEnterprise object identifier to standard SNMP traps as well.

To add snmpTrapEnterprise to standard traps, include the enterprise-oid statement at the [edit snmp trap-options] hierarchy level. If the enterprise-oid statement is not included in the configuration, snmpTrapEnterprise is added only for enterprise-specific traps.

Configure SNMP Trap Groups

You can create and name a group of one or more types of SNMP traps and then define which systems receive the group of SNMP traps. You must configure the trap group for sending the SNMP traps. To create an SNMP trap group, see trap-group.

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

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

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

A trap group can receive the following categories:

  • authentication—Authentication failures

  • chassis—Chassis or environment notifications

  • chassis-cluster—Clustering notifications

  • configuration—Configuration notifications

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

    Note:

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

  • otn-alarms—OTN alarm trap subcategories

  • remote-operations—Remote operation notifications

  • rmon-alarm—Alarm for RMON events

  • routing—Routing protocol notifications

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

  • sonet-alarms—SONET/SDH alarms

    Note:

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

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

    • pll-lock—PLL lock alarm notification

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

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

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

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

    • path-ais—Path AIS alarm notification

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

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

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

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

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

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

    • unequipped—Unequipped alarm notification

    • path-mismatch—Path mismatch alarm notification

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

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

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

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

    • vt-unequipped—VT unequipped alarm notification

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

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

  • startup—System warm and cold starts

  • timing-events—Timing events and defects notification

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

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

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

Configure SNMP Trap Options and Groups on a Device Running Junos OS

Some carriers have more than one trap receiver that forwards traps to a central NMS. This allows more than one path for SNMP traps from a router to the central NMS through different trap receivers. You can configure a device running Junos OS to send the same copy of each SNMP trap to every trap receiver configured in the trap group.

The source address in the IP header of each SNMP trap packet is set to the address of the outgoing interface by default. When a trap receiver forwards the packet to the central NMS, the source address is preserved. The central NMS, looking only at the source address of each SNMP trap packet, assumes that each SNMP trap came from a different source.

In reality, the SNMP traps came from the same router, but each left the router through a different outgoing interface.

The statements discussed in the following sections are provided to allow the NMS to recognise the duplicate traps and distinguish SNMPv1 traps based on the outgoing interface.

To configure SNMP trap options and trap groups, include the trap-options and trap-group statements at the [edit snmp] hierarchy level:

Example: Configure SNMP Trap Groups

Set up a trap notification list named urgent-dispatcher for link and startup traps. This list is used to identify the network management hosts (1.2.3.4 and fe80::1:2:3:4) to which traps generated by the local router should be sent. The name specified for a trap group is used as the SNMP community string when the agent sends traps to the listed targets.

Configure the Interfaces on Which SNMP Requests Can Be Accepted

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

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

Example: Configure Secured Access List Checking

SNMP access privileges are granted to only devices on interfaces so-0/0/0 and at-1/0/1. The following example does this by configuring a list of logical interfaces:

The following example grants the same access by configuring a list of physical interfaces:

Filter Interface Information Out of SNMP Get and GetNext Output

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

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

  • interfaces—Interfaces that match the specified regular expressions.

  • all-internal-interfaces—Internal interfaces.

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

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

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

Note:

The ! mark is supported only as the first character of the regular expression. If it appears anywhere else in a regular expression, Junos OS considers the regular expression invalid, and returns an error.

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

Configure MIB Views

SNMPv3 defines the concept of MIB views in RFC 3415, View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP). MIB views provide an agent better control over who can access specific branches and objects within its MIB tree. A view consists of a name and a collection of SNMP object identifiers, which are either explicitly included or excluded. Once defined, a view is then assigned to an SNMPv3 group or SNMPv1/v2c community (or multiple communities), automatically masking which parts of the agent’s MIB tree members of the group or community can (or cannot) access.

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

To configure MIB views, see view (Configuring a MIB View).

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

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

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

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

To associate MIB views with a community, see view (SNMP Community).

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

See Also

Configure Ping Proxy MIB

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

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

See Also