Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

ON THIS PAGE

Configuring Basic SNMP

 

Configuration Statements at the [edit snmp] Hierarchy Level

This topic shows all possible 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.

Configuring SNMP

SNMP is implemented 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, include the following statements at the [edit] hierarchy level of the configuration:

Optimizing 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:

Changing 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 has been proven that the 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 ensure that data for only one interface is polled in a request instead of a single request polling data for multiple interfaces, as is the case with column-by-column polling. Row-by-row polling also reduces the risk of requests timing out.

Reducing the Number of Variable Bindings per PDU

By reducing the number of variable bindings per protocol data unit (PDU), you can improve the response time for SNMP requests. A request that polls for data related to multiple objects, which are mapped to different index entries, translates into multiple requests at the device-end because the subagent might have to poll different modules to obtain data that are linked to different index entries. The recommended method is to ensure that a request has only objects that are 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.

Increasing 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 and reduce the number of throttle drops that occur because of the request timing out.

Reducing Incoming Packet Rate at the snmpd

By reducing the frequency of sending SNMP requests to a device, you can reduce the risk of SNMP requests piling up at any particular device. Apart from reducing the frequency of sending SNMP requests to a device, you can also increase the polling interval, control the use of GetNext requests, and reduce the number of polling stations per device.

Configuring 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:

Filtering 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:

Excluding Interfaces That Are Slow in Responding to SNMP Queries

An interface that is slow in responding to SNMP requests for interface statistics can delay 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 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.

Best Practices for Configuring 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:

Configuring Basic Settings for SNMPv1 and SNMPv2

By default, SNMP is not enabled on devices running Junos OS. 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

Configuring 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 set 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

Configuring System Name, Location, Description, and Contact Information

Junos OS enables you to include the name and location of the system, administrative contact information, and a brief description of the system in the SNMP configuration.

Note

Always keep the name, location, contact, and description information configured and updated for all your devices that are managed by SNMP.

The following example shows a typical configuration.

Tip

Use quotation marks to enclose the system name, contact, location, and description information that contain spaces.

Configuring 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:

Configuring the System Contact on a Device Running Junos OS

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

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

To define a system contact name that contains spaces:

Configuring the System Location for a Device Running Junos OS

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

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

To specify the system location:

Configuring the System Description on a Device Running Junos OS

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

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

To specify the system description:

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

To set the system contact details:

  1. 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:

  2. 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:

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

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

    user@host> show snmp mib walk system

Configuring a Different System Name

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

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

To specify the system name override:

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

Filtering Duplicate SNMP Requests

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

  • Source IP address of the SNMP request

  • Source UDP port of the SNMP request

  • Request ID of the SNMP request

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

Configuring SNMP Communities

Configuring the SNMP agent in Junos OS is a straightforward task that shares many familiar settings common to 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 which MIB objects are available, which operations (read-only or read-write) are valid for those objects, and which SNMP clients are authorized, based on their source IP addresses.

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

To create a read-only SNMP community:

  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.

Configuring the SNMP Community String

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

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

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

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

Note

Community names must be unique within each SNMP system.

Examples: Configuring 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:

Adding 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:

Configuring 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, you can include the following configuration statements at the [edit snmp] hierarchy level:

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

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

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

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

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

Note

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

Note

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

Note

Because the proxy SNMP agent does not have trap forwarding capabilities, the devices that are managed by the proxy SNMP agent send the traps directly to the network management system.

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.

See also

Configuring SNMP Traps

Traps are unsolicited messages sent from an SNMP agent to remote network management systems or trap receivers. Many enterprises use SNMP traps as part of a fault-monitoring solution, in addition to system logging. In Junos OS, SNMP traps are not forwarded by default, so 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 then define which systems receive the group of SNMP traps.. The name of the trap group is embedded in SNMP trap notification packets as one variable binding (varbind) known as the community name.

To configure an SNMP trap:

  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 a number of 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.

    user@host> request snmp spoof-trap authenticationFailure

Configuring 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 for more than one path for SNMP traps from a router to the central NMS through different trap receivers. A device running Junos OS can be configured 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 recognize the duplicate traps and to 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:

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

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:

Configuring 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:

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

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

Configuring 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. The trap group must be configured for SNMP traps to be sent. To create an SNMP trap group, include the trap-group statement at the [edit snmp] hierarchy level:

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

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

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

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

A trap group can receive the following categories:

  • authentication—Authentication failures

  • chassis—Chassis or environment notifications

  • chassis-cluster—Clustering notifications

  • configuration—Configuration notifications

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

    Note

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

  • otn-alarms—OTN alarm trap subcategories

  • remote-operations—Remote operation notifications

  • rmon-alarm—Alarm for RMON events

  • routing—Routing protocol notifications

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

  • sonet-alarms—SONET/SDH alarms

    Note

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

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

    • pll-lock—PLL lock alarm notification

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

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

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

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

    • path-ais—Path AIS alarm notification

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

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

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

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

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

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

    • unequipped—Unequipped alarm notification

    • path-mismatch—Path mismatch alarm notification

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

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

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

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

    • vt-unequipped—VT unequipped alarm notification

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

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

  • startup—System warm and cold starts

  • timing-events—Timing events and defects notification

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

  • startup—System warm and cold starts

  • 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).

SNMP Traps Support

The QFX Series standalone switches, QFX Series Virtual Chassis, and QFabric systems support standard SNMP traps and Juniper Networks enterprise-specific traps.

For more information, see:

SNMP Traps Supported on QFX Series Standalone Switches and QFX Series Virtual Chassis

QFX Series standalone switches and QFX Series Virtual Chassis support SNMPv1 and v2 traps. For more information, see:

SNMPv1 Traps

QFX Series standalone switches and QFX Series Virtual Chassis support both standard SNMPv1 traps and Juniper Networks enterprise-specific SNMPv1 traps. See:

  • Table 1 for standard SNMPv1 traps.

  • Table 2 for enterprise-specific SNMPv1 traps.

The traps are organized first by trap category and then by trap name. The system logging severity levels are listed for those traps that have them. Traps that do not have corresponding system logging severity levels are marked with an en dash (–).

Table 1: Standard SNMP Version 1 Traps Supported on QFX Series Standalone Switches and QFX Series Virtual Chassis

Defined in

Trap Name

Enterprise ID

Generic Trap Number

Specific Trap Number

System Logging Severity Level

Syslog Tag

Link Notifications

RFC 1215, Conventions for Defining Traps for Use with the SNMP

linkDown

1.3.6.1.4.1.2636

2

0

Warning

SNMP_ TRAP_ LINK_DOWN

linkUp

1.3.6.1.4.1.2636

3

0

Info

SNMP_TRAP_ LINK_UP

Remote Operations Notifications

RFC 2925, Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations

pingProbeFailed

1.3.6.1.2.1.80.0

6

1

Info

SNMP_TRAP _PING_ PROBE_ FAILED

pingTestFailed

1.3.6.1.2.1.80.0

6

2

Info

SNMP_TRAP_ PING_TEST _FAILED

pingTestCompleted

1.3.6.1.2.1.80.0

6

3

Info

SNMP_TRAP_ PING_TEST_ COMPLETED

traceRoutePathChange

1.3.6.1.2.1.81.0

6

1

Info

SNMP_TRAP_ TRACE_ROUTE_ PATH_CHANGE

traceRouteTestFailed

1.3.6.1.2.1.81.0

6

2

Info

SNMP_TRAP_ TRACE_ROUTE_ TEST_FAILED

traceRouteTestCompleted

1.3.6.1.2.1.81.0

6

3

Info

SNMP_TRAP_ TRACE_ROUTE_ TEST_COMPLETED

RMON Alarms

RFC 2819a, RMON MIB

fallingAlarm

1.3.6.1.2.1.16

6

2

risingAlarm

1.3.6.1.2.1.16

6

1

Routing Notifications

BGP 4 MIB

bgpEstablished

1.3.6.1.2.1.15.7

6

1

bgpBackwardTransition

1.3.6.1.2.1.15.7

6

2

OSPF TRAP MIB

ospfVirtIfStateChange

1.3.6.1.2.1.14.16.2

6

1

ospfNbrStateChange

1.3.6.1.2.1.14.16.2

6

2

ospfVirtNbrStateChange

1.3.6.1.2.1.14.16.2

6

3

ospfIfConfigError

1.3.6.1.2.1.14.16.2

6

4

ospfVirtIfConfigError

1.3.6.1.2.1.14.16.2

6

5

ospfIfAuthFailure

1.3.6.1.2.1.14.16.2

6

6

ospfVirtIfAuthFailure

1.3.6.1.2.1.14.16.2

6

7

ospfIfRxBadPacket

1.3.6.1.2.1.14.16.2

6

8

ospfVirtIfRxBadPacket

1.3.6.1.2.1.14.16.2

6

9

ospfTxRetransmit

1.3.6.1.2.1.14.16.2

6

10

ospfVirtIfTxRetransmit

1.3.6.1.2.1.14.16.2

6

11

ospfMaxAgeLsa

1.3.6.1.2.1.14.16.2

6

13

ospfIfStateChange

1.3.6.1.2.1.14.16.2

6

16

Startup Notifications

RFC 1215, Conventions for Defining Traps for Use with the SNMP

authenticationFailure

1.3.6.1.4.1.2636

4

0

Notice

SNMPD_ TRAP_ GEN_FAILURE

coldStart

1.3.6.1.4.1.2636

0

0

Critical

SNMPD_TRAP_ COLD_START

warmStart

1.3.6.1.4.1.2636

1

0

Error

SNMPD_TRAP_ WARM_START

VRRP Notifications

RFC 2787, Definitions of Managed Objects for the Virtual Router Redundancy Protocol

vrrpTrapNewMaster

1.3.6.1.2.1.68

6

1

Warning

VRRPD_NEW MASTER_TRAP

vrrpTrapAuthFailure

1.3.6.1.2.1.68

6

2

Warning

VRRPD_AUTH_ FAILURE_TRAP

Table 2: Enterprise-Specific SNMPv1 Traps Supported on QFX Series Standalone Switches and QFX Series Virtual Chassis

Defined in

Trap Name

Enterprise ID

Generic Trap Number

Specific Trap Number

System Logging Severity Level

System Log Tag

Chassis Notifications (Alarm Conditions)

Chassis MIB (jnx-chassis. mib)

jnxPowerSupplyFailure

1.3.6.1.4.1.2636.4.1

6

1

Warning

CHASSISD_ SNMP_ TRAP

jnxFanFailure

1.3.6.1.4.1.26361

6

2

Critical

CHASSISD_ SNMP_ TRAP

jnxOverTemperature

11.4.1.2636.4.1

6

3

Alert

CHASSISD_ SNMP_ TRAP

jnxFruRemoval

1.3.6.1.4.1.2636.4.1

6

5

Notice

CHASSISD_ SNMP_ TRAP

jnxFruInsertion

1.3.6.1.4.1.2636.4.1

6

6

Notice

CHASSISD_ SNMP_ TRAP

jnxFruPowerOff

1.3.6.1.4.1.2636.4.1

6

7

Notice

CHASSISD_ SNMP_ TRAP

jnxFruPowerOn

1.3.6.1.4.1.2636.4.1

6

8

Notice

CHASSISD_ SNMP_ TRAP

jnxFruFailed

1.3.6.1.4.1.2636.4.1

6

9

Warning

CHASSISD_ SNMP_ TRAP

jnxFruOffline

1.3.6.1.4.1.2636.4.1

6

10

Notice

CHASSISD_ SNMP_ TRAP

jnxFruOnline

1.3.6.1.4.1.2636.4.1

6

11

Notice

CHASSISD_ SNMP_ TRAP

jnxFruCheck

1.3.6.1.4.1.2636.4.1

6

12

Warning

CHASSISD_ SNMP_ TRAP

jnxPowerSupplyOk

1.3.6.1.4.1.2636.4.2

6

1

Critical

CHASSISD_ SNMP_ TRAP

jnxFanOK

1.3.6.1.4.1.2636.4.2

6

2

Critical

CHASSISD_ SNMP_ TRAP

jnxTemperatureOK

1.3.6.1.4.1.2636.4.2

6

3

Alert

CHASSISD_ SNMP_ TRAP

Configuration Notifications

Configuration Management MIB (jnx- configmgmt. mib)

jnxCmCfgChange

1.3.6.1.4.1.2636.4.5

6

1

jnxCmRescueChange

1.3.6.1.4.1.2636.4.5

6

2

Remote Operations

Ping MIB (jnx-ping.mib)

jnxPingRttThresholdExceeded

1.3.6.1.4.1.2636.4.9

6

1

jnxPingRttStdDevThreshold Exceeded

1.3.6.1.4.1.2636.4.9

6

2

jnxPingRttJitterThreshold Exceeded

1.3.6.1.4.1.2636.4.9

6

3

jnxPingEgressThreshold Exceeded

1.3.6.1.4.1.2636.4.9

6

4

jnxPingEgressStdDev ThresholdExceeded

1.3.6.1.4.1.2636.4.9

6

5

jnxPingEgressJitterThreshold Exceeded

1.3.6.1.4.1.2636.4.9

6

6

jnxPingIngressThreshold Exceeded

1.3.6.1.4.1.2636.4.9

6

7

jnxPingIngressStddevThreshold Exceeded

1.3.6.1.4.1.2636.4.9

6

8

jnxPingIngressJitterThreshold Exceeded

1.3.6.1.4.1.2636.4.9

6

9

RMON Alarms

RMON MIB (jnx-rmon. mib)

jnxRmonAlarmGetFailure

1.3.6.1.4.1.2636.4.3

6

1

jnxRmonGetOk

1.3.6.1.4.1.2636.4.3

6

2

SNMPv2 Traps

  • Table 3 lists the standard SNMP traps

  • Table 4 lists the Juniper Networks enterprise-specific traps

Table 3: Standard SNMPv2 Traps Supported on QFX Series Standalone Switches and QFX Series Virtual Chassis

Defined in

Trap Name

SNMP Trap OID

System Logging Severity Level

Syslog Tag

Link Notifications

RFC 2863, The Interfaces Group MIB

linkDown

1.3.6.1.6.3.1.1.5.3

Warning

SNMP_TRAP_ LINK_DOWN

linkUp

1.3.6.1.6.3.1.1.5.4

Info

SNMP_TRAP_ LINK_UP

Remote Operations Notifications

RFC 2925, Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations

pingProbeFailed

1.3.6.1.2.1.80.0.1

Info

SNMP_TRAP_ PING_PROBE_ FAILED

pingTestFailed

1.3.6.1.2.1.80.0.2

Info

SNMP_TRAP_PING_ TEST_FAILED

pingTestCompleted

1.3.6.1.2.1.80.0.3

Info

SNMP_TRAP_PING_ TEST_COMPLETED

traceRoutePathChange

1.3.6.1.2.1.81.0.1

Info

SNMP_TRAP_TRACE_ ROUTE_PATH_ CHANGE

traceRouteTestFailed

1.3.6.1.2.1.81.0.2

Info

SNMP_TRAP_TRACE_ ROUTE_TEST_FAILED

traceRouteTestCompleted

1.3.6.1.2.1.81.0.3

Info

SNMP_TRAP_TRACE_ ROUTE_TEST_ COMPLETED

RMON Alarms

RFC 2819a, RMON MIB

fallingAlarm

1.3.6.1.2.1.16.0.1

risingAlarm

1.3.6.1.2.1.16.0.2

Routing Notifications

BGP 4 MIB

bgpEstablished

1.3.6.1.2.1.15.7.1

bgpBackwardTransition

1.3.6.1.2.1.15.7.2

OSPF Trap MIB

ospfVirtIfStateChange

1.3.6.1.2.1.14.16.2.1

ospfNbrStateChange

1.3.6.1.2.1.14.16.2.2

ospfVirtNbrStateChange

1.3.6.1.2.1.14.16.2.3

ospfIfConfigError

1.3.6.1.2.1.14.16.2.4

ospfVirtIfConfigError

1.3.6.1.2.1.14.16.2.5

ospfIfAuthFailure

1.3.6.1.2.1.14.16.2.6

ospfVirtIfAuthFailure

1.3.6.1.2.1.14.16.2.7

ospfIfRxBadPacket

1.3.6.1.2.1.14.16.2.8

ospfVirtIfRxBadPacket

1.3.6.1.2.1.14.16.2.9

ospfTxRetransmit

1.3.6.1.2.1.14.16.2.10

ospfVirtIfTxRetransmit

1.3.6.1.2.1.14.16.2.11

ospfMaxAgeLsa

1.3.6.1.2.1.14.16.2.13

ospfIfStateChange

1.3.6.1.2.1.14.16.2.16

Startup Notifications

RFC 1907, Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)

coldStart

1.3.6.1.6.3.1.1.5.1

Critical

SNMPD_TRAP_ COLD_START

warmStart

1.3.6.1.6.3.1.1.5.2

Error

SNMPD_TRAP_ WARM_START

authenticationFailure

1.3.6.1.6.3.1.1.5.5

Notice

SNMPD_TRAP_ GEN_FAILURE

VRRP Notifications

RFC 2787, Definitions of Managed Objects for the Virtual Router Redundancy Protocol

vrrpTrapNewMaster

1.3.6.1.2.1.68.0.1

Warning

VRRPD_ NEWMASTER_ TRAP

vrrpTrapAuthFailure

1.3.6.1.2.1.68.0.2

Warning

VRRPD_AUTH_ FAILURE_ TRAP

Table 4: Enterprise-Specific SNMPv2 Traps Supported on QFX Series Standalone Switches and QFX Series Virtual Chassis

Source MIB

Trap Name

SNMP Trap OID

System Logging Severity Level

System Log Tag

Chassis (Alarm Conditions) Notifications

Chassis MIB (mib-jnx-chassis)

jnxPowerSupplyFailure

1.3.6.1.4.1.2636.4.1.1

Alert

CHASSISD_ SNMP_ TRAP

 

jnxFanFailure

1.3.6.1.4.1.2636.4.1.2

Critical

CHASSISD_ SNMP_ TRAP

 

jnxOverTemperature

1.3.6.1.4.1.2636.4.1.3

Critical

CHASSISD_ SNMP_ TRAP

 

jnxFruRemoval

1.3.6.1.4.1.2636.4.1.5

Notice

CHASSISD_ SNMP_ TRAP

 

jnxFruInsertion

1.3.6.1.4.1.2636.4.1.6

Notice

CHASSISD_ SNMP_ TRAP

 

jnxFruPowerOff

1.3.6.1.4.1.2636.4.1.7

Notice

CHASSISD_ SNMP_ TRAP

 

jnxFruPowerOn

1.3.6.1.4.1.2636.4.1.8

Notice

CHASSISD_ SNMP_ TRAP

 

jnxFruFailed

1.3.6.1.4.1.2636.4.1.9

Warning

CHASSISD_ SNMP_ TRAP

 

jnxFruOffline

1.3.6.1.4.1.2636.4.1.10

Notice

CHASSISD_ SNMP_ TRAP

 

jnxFruOnline

1.3.6.1.4.1.2636.4.1.11

Notice

CHASSISD_ SNMP_ TRAP

 

jnxFruCheck

1.3.6.1.4.1.2636.4.1.12

Notice

CHASSISD_ SNMP_ TRAP

 

jnxPowerSupplyOK

1.3.6.1.4.1.2636.4.2.1

Critical

CHASSISD_ SNMP_ TRAP

 

jnxFanOK

1.3.6.1.4.1.2636.4.2.2

Critical

CHASSISD_ SNMP_ TRAP

 

jnxTemperatureOK

1.3.6.1.4.1.2636.4.2.3

Alert

CHASSISD_ SNMP_ TRAP

Configuration Notifications

Configuration Management MIB (mib-jnx-cfgmgmt)

jnxCmCfgChange

1.3.6.1.4.1.2636.4.5.0.1

jnxCmRescueChange

1.3.6.1.4.1.2636.4.5.0.2

Remote Operations Notifications

Ping MIB (mib-jnx-ping)

jnxPingRttThreshold Exceeded

1.3.6.1.4.1.2636.4.9.0.1

jnxPingRttStdDevThreshold Exceeded

1.3.6.1.4.1.2636.4.9.0.2

jnxPingRttJitterThreshold Exceeded

1.3.6.1.4.1.2636.4.9.0.3

jnxPingEgressThreshold Exceeded

1.3.6.1.4.1.2636.4.9.0.4

jnxPingEgressStdDevThreshold Exceeded

1.3.6.1.4.1.2636.4.9.0.5

jnxPingEgressJitterThreshold Exceeded

1.3.6.1.4.1.2636.4.9.0.6

jnxPingIngressThreshold Exceeded

1.3.6.1.4.1.2636.4.9.0.7

jnxPingIngressStddevThreshold Exceeded

1.3.6.1.4.1.2636.4.9.0.8

jnxPingIngressJitterThreshold Exceeded

1.3.6.1.4.1.2636.4.9.0.9

RMON Alarms

RMON MIB (mib-jnx-rmon)

jnxRmonAlarmGetFailure

1.3.6.1.4.1.2636.4. 3.0.1

jnxRmonGetOk

1.3.6.1.4.1.2636.4. 3.0.2

SNMP Traps Supported on QFabric Systems

QFabric systems support standard SNMPv2 traps and Juniper Networks enterprise-specific SNMPv2 traps.

Note

QFabric systems do not support SNMPv1 traps.

For more information, see:

  • Table 5 for standard SNMPv2 traps

  • Table 6 for Juniper Networks enterprise-specific SNMPv2 traps

Table 5: Standard SNMPv2 Traps Supported on QFabric Systems

Defined in

Trap Name

SNMP Trap OID

System Logging Severity Level

Syslog Tag

Link Notifications

RFC 2863, The Interfaces Group MIB

linkDown

1.3.6.1.6.3.1.1.5.3

Warning

SNMP_TRAP_ LINK_DOWN

linkUp

1.3.6.1.6.3.1.1.5.4

Info

SNMP_TRAP_ LINK_UP

Startup Notifications

RFC 1907, Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)

coldStart

1.3.6.1.6.3.1.1.5.1

Critical

SNMPD_TRAP_ COLD_START

warmStart

1.3.6.1.6.3.1.1.5.2

Error

SNMPD_TRAP_ WARM_START

authenticationFailure

1.3.6.1.6.3.1.1.5.5

Notice

SNMPD_TRAP_ GEN_FAILURE

Table 6: Enterprise-Specific SNMPv2 Traps Supported on QFabric Systems

Source MIB

Trap Name

SNMP Trap OID

System Logging Severity Level

System Log Tag

Fabric Chassis MIB (mib-jnx-fabric- chassis)

Fabric Chassis (Alarm Conditions) Notifications

jnxFabricPowerSupplyFailure

1.3.6.1.4.1.2636.4.19.1

Warning

jnxFabricFanFailure

1.3.6.1.4.1.2636.4.19.2

Critical

jnxFabricOverTemperature

1.3.6.1.4.1.2636.4.19.3

Alert

jnxFabricRedundancySwitchover

1.3.6.1.4.1.2636.4.19.4

Notice

jnxFabricFruRemoval

1.3.6.1.4.1.2636.4.19.5

Notice

jnxFabricFruInsertion

1.3.6.1.4.1.2636.4.19.6

Notice

jnxFabricFruPowerOff

1.3.6.1.4.1.2636.4.19.7

Notice

jnxFabricFruPowerOn

1.3.6.1.4.1.2636.4.19.8

Notice

jnxFabricFruFailed

1.3.6.1.4.1.2636.4.19.9

Warning

jnxFabricFruOffline

1.3.6.1.4.1.2636.4.19.10

Notice

jnxFabricFruOnline

1.3.6.1.4.1.2636.4.19.11

Notice

jnxFabricFruCheck

1.3.6.1.4.1.2636.4.19.12

Warning

jnxFabricFEBSwitchover

1.3.6.1.4.1.2636.4.19.13

Warning

jnxFabricHardDiskFailed

1.3.6.1.4.1.2636.4.19.14

Warning

jnxFabricHardDiskMissing

1.3.6.1.4.1.2636.4.19.15

Warning

jnxFabricBootFromBackup

1.3.6.1.4.1.2636.4.19.16

Warning

Fabric Chassis (Alarm Cleared Conditions) Notifications

jnxFabricPowerSupplyOK

1.3.6.1.4.1.2636.4.20.1

Critical

jnxFabricFanOK

1.3.6.1.4.1.2636.4.20.2

Critical

jnxFabricTemperatureOK

1.3.6.1.4.1.2636.4.20.3

Alert

jnxFabricFruOK

1.3.6.1.4.1.2636.4.20.4

QFabric MIB (mib-jnx-qf-smi)

QFabric MIB Notifications

jnxQFabricDownloadIssued

1.3.6.1.4.1.2636.3.42.1.0.1

jnxQFabricDownloadFailed

1.3.6.1.4.1.2636.3.42.1.0.2

jnxQFabricDownloadSucceeded

1.3.6.1.4.1.2636.3.42.1.0.3

jnxQFabricUpgradeIssued

1.3.6.1.4.1.2636.3.42.1.0.4

jnxQFabricUpgradeFailed

1.3.6.1.4.1.2636.3.42.1.0.5

jnxQFabricUpgradeSucceeded

1.3.6.1.4.1.2636.3.42.1.0.6

Configuration Notifications

Configuration Management MIB (mib-jnx-cfgmgmt)

jnxCmCfgChange

1.3.6.1.4.1.2636.4.5.0.1

jnxCmRescueChange

1.3.6.1.4.1.2636.4.5.0.2

Remote Operations Notifications

Ping MIB (mib-jnx-ping)

jnxPingRttThreshold Exceeded

1.3.6.1.4.1.2636.4.9.0.1

jnxPingRttStdDevThreshold Exceeded

1.3.6.1.4.1.2636.4.9.0.2

jnxPingRttJitterThreshold Exceeded

1.3.6.1.4.1.2636.4.9.0.3

jnxPingEgressThreshold Exceeded

1.3.6.1.4.1.2636.4.9.0.4

jnxPingEgressStdDevThreshold Exceeded

1.3.6.1.4.1.2636.4.9.0.5

jnxPingEgressJitterThreshold Exceeded

1.3.6.1.4.1.2636.4.9.0.6

jnxPingIngressThreshold Exceeded

1.3.6.1.4.1.2636.4.9.0.7

jnxPingIngressStddevThreshold Exceeded

1.3.6.1.4.1.2636.4.9.0.8

jnxPingIngressJitterThreshold Exceeded

1.3.6.1.4.1.2636.4.9.0.9

Example: Configuring 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.

Configuring 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: Configuring 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:

Filtering 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 performed on interface-related MIBs such as IF MIB, ATM MIB, RMON MIB, and the Juniper Networks enterprise-specific IF MIB.

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

  • interfaces—Interfaces that match the specified regular expressions.

  • all-internal-interfaces—Internal interfaces.

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

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

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

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 limited to SNMP operations, and the users can continue to access information related to the interfaces (including those hidden using the filter-interfaces options) using the appropriate Junos OS command-line interface (CLI) commands.

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

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

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

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

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

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

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

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

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

Understanding the Integrated Local Management Interface

The Integrated Local Management Interface (ILMI) provides a mechanism for Asynchronous Transfer Mode (ATM)-attached devices, such as hosts, routers, and ATM switches, to transfer management information. ILMI provides bidirectional exchange of management information between two ATM interfaces across a physical connection. ILMI information is exchanged over a direct encapsulation of SNMP version 1 (RFC 1157, A Simple Network Management Protocol) over ATM Adaptation Layer 5 (AAL5) using a virtual path identifier/virtual channel identifier (VPI/VCI) value (VPI=0, VCI=16).

Junos OS supports only two ILMI MIB variables: atmfMYIPNmAddress and atmfPortMyIfname. For ATM1 and ATM2 intelligent queuing (IQ) interfaces, you can configure ILMI to communicate directly with an attached ATM switch to enable querying of the switch’s IP address and port number.

For more information about the ILMI MIB, see atmfMYIPNmAddress or atmfPortMyIfname in the SNMP MIB Explorer.

Utility MIB

The Juniper Networks enterprise-specific Utility MIB, whose object ID is {jnxUtilMibRoot 1}, defines objects for counters, integers, and strings. The Utility MIB contains one table for each of the following five data types:

  • 32-bit counters

  • 64-bit counters

  • Signed integers

  • Unsigned integers

  • Octet strings

Each data type has an arbitrary ASCII name, which is defined when the data is populated, and a timestamp that shows the last time when the data instance was modified. For a downloadable version of this MIB, see Routing Policies, Firewall Filters, and Traffic Policers User Guide.

For information about the enterprise-specific Utility MIB objects, see the following topics:

SNMP MIBs Support

The QFX Series standalone switches, QFX Series Virtual Chassis, and QFabric systems support standard MIBs and Juniper Networks enterprise-specific MIBs.

Note

For information about enterprise-specific SNMP MIB objects, see the SNMP MIB Explorer. You can use SNMP MIB Explorer to view information about various MIBs, MIB objects, and SNMP notifications supported on Juniper Networks devices

For more information, see:

MIBs Supported on QFX Series Standalone Switches and QFX Series Virtual Chassis

The QFX Series standalone switches and QFX Series Virtual Chassis support both standard MIBs and Juniper Networks enterprise-specific MIBs. For more information, see:

  • Table 7 for standard MIBs.

  • Table 8 for Juniper Networks enterprise-specific MIBs.

Table 7: Standard MIBs Supported on QFX Series Standalone Switches and QFX Series Virtual Chassis

RFC

Additional Information

IEEE 802.1ab section 12.1, Link Layer Discovery Protocol (LLDP) MIB

Supported tables and objects:

  • lldpRemManAddrOID

  • lldpLocManAddrOID

  • lldpReinitDelay

  • lldpNotificationInterval

  • lldpStatsRxPortFramesDiscardedTotal

  • lldpStatsRxPortFramesError

  • lldpStatsRxPortTLVsDiscardedTotal

  • lldpStatsRxPortTLVsUnrecognizedTotal

  • lldpStatsRxPortAgeoutsTotal

IEEE 802.3ad, Aggregation of Multiple Link Segments

The following tables and objects are supported:

  • dot3adAggPortTable, dot3adAggPortListTable, dot3adAggTable, and dot3adAggPortStatsTable

  • dot3adAggPortDebugTable (only dot3adAggPortDebugRxState, dot3adAggPortDebugMuxState, dot3adAggPortDebugActorSyncTransitionCount, dot3adAggPortDebugPartnerSyncTransitionCount, dot3adAggPortDebugActorChangeCount, and dot3adAggPortDebugPartnerChangeCount)

  • dot3adTablesLastChanged

RFC 1155, Structure and Identification of Management Information for TCP/IP-based Internets

RFC 1157, A Simple Network Management Protocol (SNMP)

RFC 1212, Concise MIB Definitions

RFC 1213, Management Information Base for Network Management of TCP/IP-Based Internets: MIB-II

The following areas are supported:

  • MIB II and its SNMP version 2 derivatives, including:

    • Statistics counters

    • IP, except for ipRouteTable, which has been replaced by ipCidrRouteTable (RFC 2096, IP Forwarding Table MIB)

    • ipAddrTable

    • SNMP management

    • Interface management

  • SNMPv1 Get, GetNext requests, and SNMPv2 GetBulk request

  • Junos OS-specific secured access list

  • Master configuration keywords

  • Reconfigurations upon SIGHUP

RFC 1215, A Convention for Defining Traps for use with the SNMP

Support is limited to MIB II SNMP version 1 traps and version 2 notifications.

RFC 1286, Definitions of Managed Objects for Bridges

RFC 1657, Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2

RFC 1850, OSPF Version 2 Management Information Base

The following table, objects, and traps are not supported:

  • Host Table

  • ospfOriginateNewLsas and ospfRxNewLsas objects

  • ospfOriginateLSA, ospfLsdbOverflow, and ospfLsdbApproachingOverflow traps

RFC 1901, Introduction to Community-based SNMPv2

RFC 1905, Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)

RFC 1907, Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)

RFC 2011, SNMPv2 Management Information Base for the Internet Protocol Using SMIv2

RFC 2012, SNMPv2 Management Information Base for the Transmission Control Protocol Using SMIv2

RFC 2013, SNMPv2 Management Information Base for the User Datagram Protocol Using SMIv2

RFC 2233, The Interfaces Group MIB Using SMIv2

Note: RFC 2233 has been replaced by RFC 2863. However, Junos OS supports both RFC 2233 and RFC 2863.

RFC 2287, Definitions of System-Level Managed Objects for Applications

The following objects are supported:

  • sysApplInstallPkgTable

  • sysApplInstallElmtTable

  • sysApplElmtRunTable

  • sysApplMapTable

RFC 2570, Introduction to Version 3 of the Internet-standard Network Management Framework

RFC 2571, An Architecture for Describing SNMP Management Frameworks (read-only access)

Note: RFC 2571 has been replaced by RFC 3411. However, Junos OS supports both RFC 2571 and RFC 3411.

RFC 2572, Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) (read-only access)

Note: RFC 2572 has been replaced by RFC 3412. However, Junos OS supports both RFC 2572 and RFC 3412.

RFC 2576, Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework

Note: RFC 2576 has been replaced by RFC 3584. However, Junos OS supports both RFC 2576 and RFC 3584.

RFC 2578, Structure of Management Information Version 2 (SMIv2)

RFC 2579, Textual Conventions for SMIv2

RFC 2580, Conformance Statements for SMIv2

RFC 2665, Definitions of Managed Objects for the Ethernet-like Interface Types

RFC 2787, Definitions of Managed Objects for the Virtual Router Redundancy Protocol

Support does not include row creation, the Set operation, and the vrrpStatsPacketLengthErrors object.

RFC 2790, Host Resources MIB

Support is limited to the following objects:

  • Only hrStorageTable. The file systems /, /config, /var, and /tmp always return the same index number. When SNMP restarts, the index numbers for the remaining file systems might change.

  • Only the objects of the hrSystem and hrSWInstalled groups.

RFC 2819, Remote Network Monitoring Management Information Base

The following objects are supported:

  • etherStatsTable (for Ethernet interfaces only), alarmTable, eventTable, and logTable.

  • historyControlTable and etherHistoryTable (except the etherHistoryUtilization object).

RFC 2863, The Interfaces Group MIB

Note: RFC 2233 has been replaced by RFC 2863. However, Junos OS supports both RFC 2233 and RFC 2863.

RFC 2932, IPv4 Multicast Routing MIB

RFC 2933, Internet Group Management Protocol (IGMP) MIB

RFC 2934, Protocol Independent Multicast MIB for IPv4

In Junos OS, RFC 2934 is implemented based on a draft version, pimmib.mib, of the now standard RFC.

RFC 3410, Introduction and Applicability Statements for Internet Standard Management Framework

RFC 3411, An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks

Note: RFC 3411 replaces RFC 2571. However, Junos OS supports both RFC 3411 and RFC 2571.

RFC 3412, Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)

Note: RFC 3412 replaces RFC 2572. However, Junos OS supports both RFC 3412 and RFC 2572.

RFC 3413, Simple Network Management Protocol (SNMP) Applications

All MIBs are supported except for the Proxy MIB.

RFC 3414, User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)

RFC 3415, View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)

RFC 3416, Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)

Note: RFC 3416 replaces RFC 1905, which was supported in earlier versions of Junos OS.

RFC 3417, Transport Mappings for the Simple Network Management Protocol (SNMP)

RFC 3418, Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)

Note: RFC 3418 replaces RFC 1907, which was supported in earlier versions of Junos OS.

RFC 3584, Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework

RFC 3826, The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model

RFC 4188, Definitions of Managed Objects for Bridges

The QFX3500 and QFX3600 switches support 802.1D STP (1998) and the following subtrees and objects only:

  • dot1dTp subtree—dot1dTpFdbAddress, dot1dTpFdbPort, and dot1dTpFdbStatus objects from the dot1dTpFdbTable table.

  • dot1dBase subtree—dot1dBasePort and dot1dBasePortIfIndex objects from the dot1dBasePortTable table.

Note: On QFX3500 and QFX3600 switches, the dot1dTpFdbTable table is populated only with MAC addresses learned on the default VLAN. To see the MAC addresses of all VLANs, specify the dot1qTpFdbTable table (RFC 4363b, Q-Bridge VLAN MIB) when you issue the show snmp mib walk command.

Not supported on OCX Series devices.

RFC 4293, Management Information Base for the Internet Protocol (IP)

Supports the ipAddrTable table only.

RFC 4318, Definitions of Managed Objects for Bridges with Rapid Spanning Tree Protocol

Supports 802.1w and 802.1t extensions for RSTP.

Not supported on OCX Series devices.

RFC 4363b, Q-Bridge VLAN MIB

Note: On QFX3500 and QFX3600 switches, the dot1dTpFdbTable table (RFC 4188, Definitions of Managed Objects for Bridges) is populated only with MAC addresses learned on the default VLAN. To see the MAC addresses of all VLANs, specify the dot1qTpFdbTable table (in this MIB) when you issue the show snmp mib walk command.

Not supported on OCX Series devices.

RFC 4444, IS-IS MIB

Internet Assigned Numbers Authority, IANAiftype Textual Convention MIB (referenced by RFC 2233)

See http://www.iana.org/assignments/ianaiftype-mib .

Internet draft draft-reeder-snmpv3-usm-3desede-00.txt, Extension to the User-Based Security Model (USM) to Support Triple-DES EDE in ‘Outside’ CBC Mode

Internet draft draft-ietf-idmr-igmp-mib-13.txt, Internet Group Management Protocol (IGMP) MIB

ESO Consortium MIB

Note: The ESO Consortium MIB has been replaced by RFC 3826. See http://www.snmp.com/eso/.

Table 8: Juniper Networks Enterprise-Specific MIBs Supported on QFX Series Standalone Switches and QFX Series Virtual Chassis

MIB

Description

Alarm MIB (mib-jnx-chassis-alarm)

Provides support for alarms from the switch.

Analyzer MIB (mib-jnx-analyzer)

Contains analyzer and remote analyzer data related to port mirroring.

Not supported on OCX Series devices.

Chassis MIB (mib-jnx-chassis)

Provides support for environmental monitoring (power supply state, board voltages, fans, temperatures, and airflow) and inventory support for the chassis, Flexible PIC Concentrators (FPCs), and PICs.

Note: The jnxLEDTable table has been deprecated.

Chassis Definitions for Router Model MIB (mib-jnx-chas-defines)

Contains the object identifiers (OIDs) that are used by the Chassis MIB to identify routing and switching platforms and chassis components. The Chassis MIB provides information that changes often, whereas the Chassis Definitions for Router Model MIB provides information that changes less often.

Class-of-Service MIB (mib-jnx-cos)

Provides support for monitoring interface output queue statistics per interface and per forwarding class.

Configuration Management MIB (mib-jnx-cfgmgmt)

Provides notification for configuration changes and rescue configuration changes in the form of SNMP traps. Each trap contains the time at which the configuration change was committed, the name of the user who made the change, and the method by which the change was made.

A history of the last 32 configuration changes is kept in jnxCmChgEventTable.

Ethernet MAC MIB (mib-jnx-mac)

Monitors media access control (MAC) statistics on Gigabit Ethernet intelligent queuing (IQ) interfaces. It collects MAC statistics; for example, inoctets, inframes, outoctets, and outframes on each source MAC address and virtual LAN (VLAN) ID for each Ethernet port.

Not supported on OCX Series devices.

Event MIB (mib-jnx-event)

Defines a generic trap that can be generated using an operations script or event policy. This MIB provides the ability to specify a system log string and raise a trap if that system log string is found.

In Junos OS release 13.2X51-D10 or later, if you configured an event policy to raise a trap when a new SNMP trap target is added, the SNMPD_TRAP_TARGET_ADD_NOTICE trap is generated with information about the new target.

Firewall MIB (mib-jnx-firewall)

Provides support for monitoring firewall filter counters.

Host Resources MIB (mib-jnx-hostresources)

Extends the hrStorageTable object, providing a measure of the usage of each file system on the switch as a percentage. Previously, the objects in the hrStorageTable measured the usage in allocation units—hrStorageUsed and hrStorageAllocationUnits—only. Using the percentage measurement, you can more easily monitor and apply thresholds on usage.

Interface MIB (Extensions) (mib-jnx-if-extensions)

Extends the standard ifTable (RFC 2863) with additional statistics and Juniper Networks enterprise-specific chassis information in the ifJnxTable and ifChassisTable tables.

L2ALD MIB (mib-jnx-l2ald)

Provides information about Layer 2 Address Learning and related traps, such as the routing instance MAC limit trap and interface MAC limit trap. This MIB also provides VLAN information in the jnxL2aldVlanTable table for Enhanced Layer 2 Software (ELS) EX Series and QFX Series switches.

Note: Non-ELS EX Series switches use the VLAN MIB (jnxExVlanTable) for VLAN information instead of this MIB.

MPLS MIB (mib-jnx-mpls)

Provides MPLS information and defines MPLS notifications.

Note: This MIB is not supported on the QFX5100 switch.

MPLS LDP MIB (mib-jnx-mpls-ldp)

Contains object definitions as described in RFC 3815, Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP).

Note: This MIB is not supported on the QFX5100 switch.

Ping MIB (mib-jnx-ping)

Extends the standard Ping MIB control table (RFC 2925). Items in this MIB are created when entries are created in pingCtlTable of the Ping MIB. Each item is indexed exactly as it is in the Ping MIB.

RMON Events and Alarms MIB (mib-jnx-rmon)

Supports Junos OS extensions to the standard Remote Monitoring (RMON) Events and Alarms MIB (RFC 2819). The extension augments the alarmTable object with additional information about each alarm. Two additional traps are also defined to indicate when problems are encountered with an alarm.

Structure of Management Information MIB (mib-jnx-smi)

Explains how the Juniper Networks enterprise-specific MIBs are structured.

System Log MIB (mib-jnx-syslog)

Enables notification of an SNMP trap-based application when an important system log message occurs.

Utility MIB (mib-jnx-util)

Provides you with SNMP MIB container objects of the following types: 32-bit counters, 64-bit counters, signed integers, unsigned integers, and octet strings. You can use these objects to store data that can be retrieved using other SNMP operations.

VLAN MIB (mib-jnx-vlan)

Contains information about prestandard IEEE 802.10 VLANs and their association with LAN emulation clients.

Note: For ELS EX Series switches and QFX Series switches, VLAN information is available in the L2ALD MIB in the jnxL2aldVlanTable table instead of in the VLAN MIB For non-ELS EX Series switches, VLAN information is provided in the VLAN MIB in the jnxExVlanTable table.

Not supported on OCX Series devices.

MIBs Supported on QFabric Systems

The QFabric systems support both standard MIBs and Juniper Networks enterprise-specific MIBs. For more information, see:

Table 9: Standard MIBs Supported on QFabric Systems

RFC

Additional Information

RFC 1155, Structure and Identification of Management Information for TCP/IP-based Internets

RFC 1157, A Simple Network Management Protocol (SNMP)

RFC 1212, Concise MIB Definitions

RFC 1213, Management Information Base for Network Management of TCP/IP-Based Internets: MIB-II

The following areas are supported:

  • MIB II and its SNMP version 2 derivatives, including:

    • Statistics counters

    • IP, except for ipRouteTable, which has been replaced by ipCidrRouteTable (RFC 2096, IP Forwarding Table MIB)

    • ipAddrTable

    • SNMP management

    • Interface management

  • SNMPv1 Get, GetNext requests, and version 2 GetBulk request

  • Junos OS-specific secured access list

  • Master configuration keywords

  • Reconfigurations upon SIGHUP

RFC 1215, A Convention for Defining Traps for use with the SNMP

Support is limited to MIB II SNMP version 1 traps and version 2 notifications.

RFC 1286, Definitions of Managed Objects for Bridges

RFC 1901, Introduction to Community-based SNMPv2

RFC 1905, Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)

RFC 1907, Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)

RFC 2011, SNMPv2 Management Information Base for the Internet Protocol Using SMIv2

Note: On the QFabric system, for the SNMP mibwalk request to work, you must configure the IP address of at least one interface besides the management Ethernet interfaces (me0 and me1) in the Director group.

RFC 2012, SNMPv2 Management Information Base for the Transmission Control Protocol Using SMIv2

RFC 2013, SNMPv2 Management Information Base for the User Datagram Protocol Using SMIv2

RFC 2233, The Interfaces Group MIB Using SMIv2

Note: RFC 2233 has been replaced by RFC 2863. However, Junos OS supports both RFC 2233 and RFC 2863.

Note: The QFabric system supports the following objects only: ifNumber, ifTable, and ifxTable.

RFC 2571, An Architecture for Describing SNMP Management Frameworks (read-only access)

Note: RFC 2571 has been replaced by RFC 3411. However, Junos OS supports both RFC 2571 and RFC 3411.

RFC 2572, Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) (read-only access)

Note: RFC 2572 has been replaced by RFC 3412. However, Junos OS supports both RFC 2572 and RFC 3412.

RFC 2576, Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework

Note: RFC 2576 has been replaced by RFC 3584. However, Junos OS supports both RFC 2576 and RFC 3584.

RFC 2578, Structure of Management Information Version 2 (SMIv2)

RFC 2579, Textual Conventions for SMIv2

RFC 2580, Conformance Statements for SMIv2

RFC 2665, Definitions of Managed Objects for the Ethernet-like Interface Types

The QFabric system supports the following tables only:

  • dot3StatsTable—There is one row with statistics for each Ethernet-like interface in the QFabric system. The dot3StatsIndex is an interface index that is unique across the system.

  • dot3ControlTable—There is one row in this table for each Ethernet-like interface in the QFabric system that implements the MAC control sublayer. OIDs supported are dot3ControlFunctionsSupported and dot3ControlInUnknownOpcode.

  • dot3PauseTable—There is one row in this table for each Ethernet-like interface in the QFabric system that supports the MAC control PAUSE function. OIDs supported are dot3PauseAdminMode, dot3PauseOperMode, dot3InPauseFrames, and dot3OutPauseFrames.

Note: Scalar variables are not supported on the QFabric system.

RFC 2863, The Interfaces Group MIB

Note: RFC 2233 has been replaced by RFC 2863. However, Junos OS supports both RFC 2233 and RFC 2863.

Note: The QFabric system supports the following objects only: ifNumber, ifTable, and ifxTable.

RFC 2933, Internet Group Management Protocol (IGMP) MIB

RFC 3410, Introduction and Applicability Statements for Internet Standard Management Framework

RFC 3411, An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks

Note: RFC 3411 replaces RFC 2571. However, Junos OS supports both RFC 3411 and RFC 2571.

RFC 3412, Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)

Note: RFC 3412 replaces RFC 2572. However, Junos OS supports both RFC 3412 and RFC 2572.

RFC 3416, Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)

Note: RFC 3416 replaces RFC 1905, which was supported in earlier versions of Junos OS.

RFC 3417, Transport Mappings for the Simple Network Management Protocol (SNMP)

RFC 3418, Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)

Note: RFC 3418 replaces RFC 1907, which was supported in earlier versions of Junos OS.

RFC 3584, Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework

RFC 4188, Definitions of Managed Objects for Bridges

The QFabric system support is limited to the following objects:

  • Under the dot1dBase OID, the dot1dBasePortTable table supports only the first two columns in the table: dot1dBasePort and dot1dBasePortIfIndex.

  • The system does not implement the optional traps supporting dot1dNotifications (dot1dBridge 0).

  • Under the dot1dStp OID, supports only the dot1dStpPortTable table. Does not support the scalar variables under dot1dStp.

  • The system does not support scalar variables under dot1dTp, but under that, the dot1dTpFdbTable table is supported (dot1dBridge 4).

  • For OIDS with tables support only, scalar values that are returned by the SNMP agent may not be meaningful and are therefore not recommended for use.

Not supported on OCX Series devices.

RFC 4293, Management Information Base for the Internet Protocol (IP)

Supports the ipAddrTable table only.

On the QFabric system, supported objects in the ipAddrTable table include: ipAdEntAddr, ipAdEntIfIndex, ipAdEntNetMask, ipAdEntBcastAddr, and ipAdEntReasmMaxSize.

Note: On the QFabric system, for the SNMP mibwalk request to work, you must configure the IP address of at least one interface besides the management Ethernet interfaces (me0 and me1) in the Director group.

RFC 4363b, Q-Bridge VLAN MIB

The QFabric system supports the following tables only:

  • dot1qTpFdbTable

  • dot1qVlanStaticTable

  • dot1qPortVlanTable

  • dot1qFdbTable

Not supported on OCX Series devices.

Note

QFabric-specific MIBs are not supported on OCX Series devices.

Table 10: Juniper Networks Enterprise-Specific MIBs Supported on QFabric Systems

MIB

Description

Analyzer MIB (mib-jnx-analyzer)

Contains analyzer and remote analyzer data related to port mirroring.

The QFabric system supports:

  • Analyzer table—jnxAnalyzerName, jnxMirroringRatio, jnxLossPriority.

  • Analyzer input table—jnxAnalyzerInputValue, jnxAnalyzerInputOption, jnxAnalyzerInputType.

  • Analyzer output table—jnx AnalyzerOutputValue, jnxAnalyzerOutputType.

Chassis MIB (mib-jnx-chassis)

Note: The Chassis MIB has been deprecated for the QFabric system. We recommend that you use the Fabric Chassis MIB (mib-jnx-fabric-chassis) for information about the QFabric system.

Class-of-Service MIB (mib-jnx-cos)

Provides support for monitoring interface output queue statistics per interface and per forwarding class.

The QFabric system supports the following tables and objects:

  • Jnxcosifstatflagtable—jnxCosIfstatFlags and jnxCosIfIndex.

  • Jnxcosqstattable—jnxCosQstatTxedPkts, jnxCosQstatTxedPktRate, jnxCosQstatTxedBytes, and jnxCosQstatTxedByteRate.

  • Jnxcosfcidtable—jnxCosFcIdToFcName.

  • Jnxcosfctable—jnxCosFcQueueNr.

The QFabric system does not support any traps for this MIB.

Configuration Management MIB (mib-jnx-cfgmgmt)

Provides notification for configuration changes and rescue configuration changes in the form of SNMP traps. Each trap contains the time at which the configuration change was committed, the name of the user who made the change, and the method by which the change was made.

A history of the last 32 configuration changes is kept in jnxCmChgEventTable.

Note: On the QFabric system, these conditions apply:

  • All scalar variables under the jnxCmCfgChg table are supported.

  • Supported scalar OIDs are jnxCmCfgChgLatestIndex, jnxCmCfgChgLatestTime, jnxCmCfgChgLatestDate, jnxCmCfgChgLatestSource, jnxCmCfgChgLatestUser, and jnxCmCfgChgMaxEventEntries.

  • Scalar variables under the jnxCmRescueChg table are not supported.

Fabric Chassis MIB (mib-jnx-fabric-chassis)

Provides hardware information about the QFabric system and its component devices. This MIB is based on the Juniper Networks enterprise-specific Chassis MIB but adds another level of indexing that provides information for QFabric system component devices.

Interface MIB (Extensions) (mib-jnx-if-extensions)

Extends the standard ifTable (RFC 2863) with additional statistics and Juniper Networks enterprise-specific chassis information in the ifJnxTable and ifChassisTable tables.

Note: On the QFabric system, scalar variables are not supported.

Power Supply Unit MIB (mib-jnx-power-supply-unit)

Provides support for environmental monitoring of the power supply unit for the Interconnect device of the QFabric system.

Note: On the QFabric system, scalar variables for the jnxPsuObjects 1 object ID in the jnxPsuScalars table are not supported.

QFabric MIB (jnx-qf-smi)

Explains how the Juniper Networks enterprise-specific QFabric MIBs are structured. Defines the MIB objects that are reported by the QFabric system and the contents of the traps that can be issued by the QFabric system.

Utility MIB (mib-jnx-util)

Provides you with SNMP MIB container objects of the following types: 32-bit counters, 64-bit counters, signed integers, unsigned integers, and octet strings. You can use these objects to store data that can be retrieved using other SNMP operations.

MIB Objects for the QFX Series

This topic lists the Juniper Networks enterprise-specific SNMP Chassis MIB definition objects for the QFX Series:

QFX Series Standalone Switches

QFabric Systems

QFabric System QFX3100 Director Device

QFabric System QFX3008-I Interconnect Device

QFabric System QFX3600-I Interconnect Device

QFabric System Node Devices

Fabric Chassis MIB

The Juniper Networks enterprise-specific SNMP Fabric Chassis MIB (mib-jnx-fabric-chassis) provides hardware information about the QFabric system and its component devices in a single MIB. The Fabric Chassis MIB is based on the Juniper Networks enterprise-specific Chassis MIB that provides information for individual devices. Unlike the Chassis MIB, the Fabric Chassis MIB represents the QFabric system component devices as part of the QFabric system. Only the information from the Fabric Chassis MIB (and not from individual Chassis MIBs) is available to SNMP management clients of the QFabric system.

The Fabric Chassis MIB uses the basic information structure of the Chassis MIB, but adds another level of indexing that provides detailed information about QFabric system devices. Each physical device in a QFabric system (such as a Node device or an Interconnect device) is represented with its hardware components, including the power supply, fans, and front and rear cards.

As in other SNMP systems, the SNMP manager resides on the network management system (NMS) of the network to which the QFabric system belongs. The SNMP agent (snmpd) resides in the QFabric system Director software and is responsible for receiving and distributing all traps as well as responding to all queries from the SNMP manager. In addition, there is an SNMP subagent running in the Routing Engine of each Node group and Interconnect device. The SNMP subagent manages the information about the component device, and that information is communicated to the SNMP agent in the Director software as needed. Traps that are generated by a Node device are sent to the SNMP agent in the Director software, which in turn processes and sends them to the target IP addresses that are defined in the SNMP configuration.

Table 11 describes the tables and objects in the Fabric Chassis MIB.

Table 11: Fabric Chassis MIB Tables and Objects

Table or Object Name

Root OID

Description

Tables with Counterparts in the Chassis MIB

jnxFabricContainersTable

1.3.6.1.4.1.2636.3.42.2.2.2

Provides information about different types of containers in QFabric system devices.

  • Containers for Interconnect devices include fan trays, power supply units, control boards, and so on.

  • Containers for Node devices include fan trays, power supply units, Flexible PIC Concentrator (FPC), PICs, and so on.

  • Containers for the Director devices include CPU, memory, fan trays, power supply units, and hard disks. The containers have a non-hierarchical or flat structure, and components in them are organized as siblings to each other.

jnxFabricContentsTable

1.3.6.1.4.1.2636.3.42.2.2.3

Contains contents that are present across all devices represented in the jnxFabricDeviceTable object. This table includes all field replaceable units (FRUs) and non-FRUs for QFabric system devices.

  • Contents in the Interconnect devices include fan trays and control boards.

  • Contents in the Node devices include fan trays and power supply units.

  • Contents in the Director devices include CPUs, memory, fan trays, power supply units, and hard disks, but do not include network interface cards (NICs).

jnxFabricFilledTable

1.3.6.1.4.1.2636.3.42.2.2.4

Shows the status of containers in QFabric devices. The jnxFabricFilledState object represents the state of the component: (1) unknown, (2) empty, or (3) filled.

Note: The jnxFabricFilledTable object does not contain information about the Director group.

jnxFabricOperatingTable

1.3.6.1.4.1.2636.3.42.2.2.5

Represents different operating parameters for the contents that are populated in the jnxFabricContentsTable object.

  • Contents in each Node device and Interconnect device include fan trays, power supply units, FPC, PIC, and Routing Engine.

  • Contents in the Director device include CPUs, memory, fan trays, power supply units, and hard disks, but do not include network interface cards (NICs).

The jnxFabricOperatingState object provides the state of the device: (1) unknown, (2) running, (3) ready, (4) reset, (5) runningAtFullSpeed (for fans only), (6) down, (6) off (for power supply units), or (7) standby.

jnxFabricRedundancyTable

1.3.6.1.4.1.2636.3.42.2.2.6

Represents the redundancy information that is available at different subsystem levels across the QFabric system. Information about the Routing Engines in Node devices is included, but there are no corresponding entries for Interconnect devices in this table. The jnxFabricRedundancyState object indicates the state of the subsystem: (1) unknown, (2) primary, (3) backup, or (4) disabled.

Note: Information about redundant Director devices, virtual machines (VMs) within Director groups, and Virtual Chassis devices is not available at this time.

jnxFabricFruTable

1.3.6.1.4.1.2636.3.42.2.2.7

Contains all FRUs for the QFabric system in the jnxFabricDeviceTable table. The FRUs are listed regardless of whether or not they are installed or online. The jnxFabricFruState object represents the state of the FRU, including online, offline, or empty, and so on. This table also contains information about each FRU, such as name, type, temperature, time last powered on, and time last powered off.

Note: The jnxFabricFruTable table does not include network interface cards (NICs) on Director devices.

Table Specific to the Fabric Chassis MIB

jnxFabricDeviceTable

1.3.6.1.4.1.2636.3.42.2.2.1

Contains information about all devices in the QFabric system. This table organizes scalar variables represented in the Chassis MIB into a table format for the QFabric system component devices. Columns in this table include device information such as model, device alias, and serial number. The jnxFabricDeviceIndex identifies each QFabric system device (Node device, Interconnect device, and Director device).

Note: At this time, information about the Virtual Chassis is not available.

Note: The following objects are not supported:

  • jnxFabricDeviceEntryRevision

  • jnxFabricDeviceEntryFirmwareRevision

  • jnxFabricDeviceEntryKernelMemoryUsedPercent

Scalar Variables

The following scalar variables are supported:

  • jnxFabricClass

  • jnxFabricDescr

  • jnxFabricSerialNo

  • jnxFabricRevision

  • jnxFabricLastInstalled

  • jnxFabricContentsLastChange

  • jnxFabricFilledLastChange

1.3.6.1.4.1.2636.3.42.2.1

Describe the QFabric system as a whole.

Note: The jnxFabricFirmwareRevision scalar variable is not supported at this time.

Table 12 describes the SNMPv2 traps that are defined in the Fabric Chassis MIB.

Note

Only SNMPv2 traps are supported on the QFabric system.

Table 12: Fabric Chassis MIB SNMPv2 Traps

Trap Group and Name

Root OID

Description

jnxFabricChassisTraps group—Includes the following traps:

  • jnxFabricPowerSupplyFailure

  • jnxFabricFanFailure

  • jnxFabricOverTemperature

  • jnxFabricRedundancySwitchover

  • jnxFabricFruRemoval

  • jnxFabricFruInsertion

  • jnxFabricFruPowerOff

  • jnxFabricFruPowerOn

  • jnxFabricFruFailed

  • jnxFabricFruOffline

  • jnxFabricFruOnline

  • jnxFabricFruCheck

  • jnxFabricFEBSwitchover

  • jnxFabricHardDiskFailed

  • jnxFabricHardDiskMissing

  • jnxFabricBootFromBackup

  • jnxFabricHighPower

1.3.6.1.4.1.2636.4.19

Indicates an alarm condition.

Note: Hardware events on the Director group are detected by scanning. As a result, a trap may not be generated until up to 30 seconds after the event has occurred.

Note: The software does not distinguish between the fan removal and fan failure events on the Director group. In each case, both the jnxFabricFanFailure and jnxFabricFruFailed traps are generated.

jnxFabricChassisOKTraps group—Includes the following traps:

  • jnxFabricPowerSupplyOK

  • jnxFabricFanOK

  • jnxFabricTemperatureOK

  • jnxFabricFruOK

  • jnxFabricHighPowerCleared

1.3.6.1.4.1.2636.4.20

Indicates an alarm cleared condition.

For more information, see the Fabric Chassis MIB at:

https://www.juniper.net/documentation/en_US/junos13.1/topics/reference/mibs/mib-jnx-fabric-chassis.txt

Monitoring RMON MIB Tables

Purpose

Monitor remote monitoring (RMON) alarm, event, and log tables.

Action

To display the RMON tables:

user@switch> show snmp rmon

Meaning

The display shows that an alarm has been defined to monitor jnxRmon MIB object jnxOperatingCPU, which represents the CPU utilization of the Routing Engine. The alarm is configured to generate an event that sends an SNMP trap and adds an entry to the logTable in the RMON MIB. The log table shows that two occurrences of the event have been generated—one for rising above a threshold of 90 percent, and one for falling below a threshold of 75 percent.

Using the Enterprise-Specific Utility MIB to Enhance SNMP Coverage

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

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

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

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

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

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

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

Event Policy Configuration

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

check-mbufs.slax Script

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

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

user@host> show snmp mib walk jnxUtilData ascii jnxUtilIntegerValue."current-mbufs" = 0 jnxUtilIntegerTime."current-mbufs" = 07 da 05 0c 03 14 2c 00 2d 07 00 user@caramels>
Note

The show snmp mib walk command is not available on the QFabric system, but you can use external SNMP client applications to perform this operation.

Example: Configuring SNMP

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.

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

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.

Configuring RMON Alarms and Events

The Junos OS supports the Remote Network Monitoring (RMON) MIB (RFC 2819), which allows a management device to monitor the values of MIB objects, or variables, against configured thresholds. When the value of a variable crosses a threshold, an alarm and its corresponding event are generated. The event can be logged and can generate an SNMP trap.

To configure RMON alarms and events using the CLI, perform these tasks:

  1. Configuring SNMP

  2. Configuring an Event

  3. Configuring an Alarm

Configuring SNMP

To configure SNMP:

  1. Grant read-only access to all SNMP clients:
    [edit snmp]

    user@switch# set community community-name authorization authorization

    For example:

    [edit snmp]

    user@switch# set community public authorization read-only
  2. Grant read-write access to the RMON and jnx-rmon MIBs:
    [edit snmp]

    user@switch# set view view-name oid object-identifier include

    user@switch# set view view-name oid object-identifier include

    user@switch# set community community-name authorization authorization view view-name

    For example:

    [edit snmp]

    user@switch# set view rmon-mib-view oid .1.3.6.1.2.1.16 include

    user@switch# set view rmon-mib-view oid .1.3.6.1.4.1.2636.13 include

    user@switch# set community private authorization read-write view rmon-mib-view

    OIDs 1.3.6.1.2.1.16 and 1.3.6.1.4.1.2636.13 correspond to the RMON and jnxRmon MIBs.

  3. Configure an SNMP trap group:
    [edit snmp]

    user@switch# set trap-group group-name categories category

    user@switch# set trap-group group-name targets address

    For example:

    [edit snmp]

    user@switch# set trap-group rmon-trap-group categories rmon-alarm

    user@switch# set trap-group rmon-trap-group targets 192.168.5.5

    The trap group rmon-trap-group is configured to send RMON traps to 192.168.5.5.

Configuring an Event

To configure an event:

  1. Configure an event index, community name, and type:
    [edit snmp rmon]

    user@switch# set event index community community-name typetype

    For example:

    [edit snmp rmon]

    user@switch# set event 1 community rmon-trap-group type log-and-trap

    The event community corresponds to the SNMP trap group and is not the same as an SNMP community. This event generates an SNMP trap and adds an entry to the logTable in the RMON MIB.

  2. Configure a description for the event:
    [edit snmp rmon]

    user@switch# set event index description description

    For example:

    [edit snmp rmon]

    user@switch# set event 1 description “rmon event”

Configuring an Alarm

To configure an alarm:

  1. Configure an alarm index, the variable to monitor, the rising and falling thresholds, and the corresponding rising and falling events:
    [edit snmp rmon]

    user@switch# set alarm index variable oid-variable falling-threshold integer rising-threshold integer rising-event-index index falling-event-index index

    For example:

    [edit snmp rmon]

    user@switch# set alarm 5 variable .1.3.6.1.4.1.2636.3.1.13.1.8.9.1.0.0 falling-threshold 75 rising-threshold 90 rising-event-index 1 falling-event-index 1

    The variable .1.3.6.1.4.1.2636.3.1.13.1.8.9.1.0.0 corresponds to the jnxRmon MIB object jnxOperatingCPU, which represents the CPU utilization of the Routing Engine. The falling and rising threshold integers are 75 and 90. The rising and falling events both generate the same event (event index 1).

  2. Configure the sample interval and type and the alarm type:
    [edit snmp rmon]

    user@switch# set alarm index interval seconds sample-type (absolute-value | delta-value) startup-alarm (falling-alarm | rising-alarm | rising-or-falling-alarm)

    For example:

    [edit snmp rmon]

    user@switch# set alarm 5 interval 30 sample-type absolute-value startup-alarm rising-or-falling-alarm

    The absolute value of the monitored variable is sampled every 30 seconds. The initial alarm can occur because of rising above the rising threshold or falling below the falling threshold.