Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

SNMP Traps

Configure SNMP Traps

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

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

To configure an SNMP trap:

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

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

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

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

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

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

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

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

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

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

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

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

Configure SNMP Trap Options

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

Note:

You can associate SNMP with only master routing instance.

To configure SNMP trap options, see trap-options.

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

This topic contains the following sections:

Configure the Source Address for SNMP Traps

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

Note:

You can generate SNMP Traps only if the source address is a valid IPv4 or IPv6 address or is configured.

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

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

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

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

  • A logical-system name

  • A routing-instance name

A Valid IPv4 Address As the Source Address

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

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

A Valid IPv6 Address As the Source Address

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

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

The Lowest Loopback Address As the Source Address

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

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

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

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

Logical System Name as the Source Address

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

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

Routing Instance Name as the Source Address

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

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

Configure the Agent Address for SNMP Traps

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

To configure the outgoing interface as the agent address:

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

Add snmpTrapEnterprise Object Identifier to Standard SNMP Traps

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

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

Configure SNMP Trap Groups

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

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

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

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

A trap group can receive the following categories:

  • authentication—Authentication failures

  • chassis—Chassis or environment notifications

  • chassis-cluster—Clustering notifications

  • configuration—Configuration notifications

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

    Note:

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

  • otn-alarms—OTN alarm trap subcategories

  • remote-operations—Remote operation notifications

  • rmon-alarm—Alarm for RMON events

  • routing—Routing protocol notifications

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

  • sonet-alarms—SONET/SDH alarms

    Note:

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

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

    • pll-lock—PLL lock alarm notification

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

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

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

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

    • path-ais—Path AIS alarm notification

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

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

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

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

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

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

    • unequipped—Unequipped alarm notification

    • path-mismatch—Path mismatch alarm notification

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

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

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

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

    • vt-unequipped—VT unequipped alarm notification

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

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

  • startup—System warm and cold starts

  • timing-events—Timing events and defects notification

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

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

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

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

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

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

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

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

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

Example: Configure SNMP Trap Groups

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

Manage Traps

The following provide details on managing SNMP notifications:

  • Generate Traps Based on SysLog Events:

    Event policies can include an action that raises traps for events based on system log messages. This feature enables notification of an SNMP trap-based application when an important system log message occurs. You can convert any system log message, for which there is no corresponding trap, into a trap. If you are using network management system traps rather than system log messages to monitor your network, you can use this feature to ensure that you are notified of all the major events.

    To configure a policy that raises a trap on receipt of an event, include the following statements at the [edit event-options policy policy-name] hierarchy level:

    The following example shows the sample configuration for raising a trap for the event ui_mgd_terminate:

  • Filter Traps Based on the Trap Category:

    SNMP traps are categorized into many categories. The Junos OS provides a configuration option, categories at the [edit snmp trap-group trap-group] hierarchy level, that enables you to specify categories of traps that you want to receive on a particular host. You can use this option when you want to monitor only specific modules of the Junos OS.

    The following example shows a sample configuration for receiving only link, vrrp-events, services, and otn-alarms traps:

  • Filter Traps Based on the Object Identifier:

    The Junos OS also provides a more advanced filter option that enables you to filter out specific traps based on their object identifiers. You can use the notify-filter option to filter out a specific trap or a group of traps.

    The following example shows the sample configuration for excluding Juniper Networks enterprise-specific configuration management traps (note that the SNMPv3 configuration also supports filtering of SNMPv1 and SNMPv2 traps as is shown in the following example):