Configuring Traps

This section provides information for:

• IP Hosts
• Trap Categories
• Trap Severity Levels
• Specifying an Egress Point for SNMP Traps
• Configuring Trap Queues
• Configuring Trap Notification Logs
• Recovering Lost Traps

The system generates SNMP traps according to operating specifications defined in supported MIBs.

IP Hosts

Traps are sent to IP hosts. The IP hosts are configured in a proprietary trap host table maintained by the router (the server). Each entry in the table contains:

• IP address of the trap destination
• Community name (v1 or v2c) or username (v3) to send in the trap message
• SNMP format (v1 or v2) of the notification (trap) PDU to use for that destination
• Types of traps enabled to be sent to that destination
• Trap filters configured for the destination

The maximum number of entries in the SNMP trap host table in each virtual router is eight.

Trap Categories

The router supports the following trap categories:

• addrPool—Local address pool traps
• atmPing—E-series router proprietary ATM ping traps
• bfdmib—BFD MIB traps
• bgp—BGP state change traps
• bulkstats—Bulk statistics file full and nearly full traps
• cliSecurityAlert—Security alert traps
• dhcp—Dynamic Host Configuration Protocol traps
• dismanEvent—Distributed management (disman) event traps
• dosProtectionPlatform—DoS protection platform traps
• dvmrp—Distance Vector Multicast Routing Protocol traps
• dvmrpProp—E-series router proprietary DVMRP traps
• environment—Power, temperature, fan, and memory utilization traps
• fileXfer—File transfer status change traps
• haRedundancy—High availability and redundancy traps
• inventory—System inventory and status traps
• ip—Internet Protocol traps
• ldp—LDP traps
• link—SNMP linkUp and linkDown traps
• log—System log capacity traps
• mobileIpv4—Mobile IPv4 traps
• mplste—Mplste traps
• mrouter—Mrouter traps
• ntp—E-series router proprietary traps
• ospf—Open Shortest Path First traps
• packetMirror—Packet mirroring traps; packet mirroring–related SNMP categories and traps are visible only to authorized users. See JUNOSe Policy Management Configuration Guide for information about using secure packet mirroring traps.
• pim—Protocol Independent Multicast traps
• ping—Ping operation traps in disman remops (remote operations) MIB
• radius—RADIUS servers fail to respond to accounting and authentication requests traps, or servers return to active service traps
• routeTable—Maximum route limit and warning threshold traps; when this trap is generated, the actual value of the exceeded warning threshold is displayed.
• snmp—SNMP coldStart, warmStart, authenticationFailure; the trap option. The snmp-server enable traps snmp authentication command allows customized treatment for SNMP authentication failure traps.
• sonet—SONET traps
• traceroute—Traceroute operation traps (in disman remops MIB)
• trapFilters—Global filters for SNMP trap recipients
• vrrp—Virtual Router Redundancy Protocol traps

To enable global trap categories, use the snmp-server enable traps command. To enable trap categories for a specific host, use the snmp-server host command.

Trap Severity Levels

The router provides a method of filtering traps according to severity. Table 22 describes the supported severity levels.

Table 22: Trap Severity Descriptions

You can set up one or more of the following types of trap filters:

• Global—Filters traps by type and severity level across all trap categories
• Per-category—Filters traps for a specific category by type and severity level
• Host-specific—Filters traps on a specific host by type and severity level

Trap filters work as follows:

1. An event is posted to the SNMP agent.
2. The system determines whether the corresponding trap category is globally enabled and whether the trap meets the minimum severity level for the trap category. If the per-category filter is not defined for this trap, the global trap severity applies.
   • If the trap does not meet these criteria, the system discards the trap.
   • If the trap does meet these criteria, the trap goes to the trap host processor.
3. The trap host processor determines whether the trap category is enabled on the host and whether the trap meets the minimum severity level set for the host.
   • If the trap does not meet these criteria, the system discards the trap.
   • If the trap does meet these criteria, the trap is sent to the trap recipient.

To set up global severity filters, use the snmp-server enable traps command. To specify the trap severity level for a particular category, use the snmp-server enable traps per-category-trapFilters command. To set up a severity filter for a specific host, use the snmp-server host command.

snmp-server enable traps

• Use to enable and configure SNMP trap generation on a global basis.
• Traps are unsolicited messages sent from an SNMP server (agent) to an SNMP client (manager).
• You can enable the traps listed in Trap Categories .
• You can filter traps according to the trap severity levels described in Table 22.
• If you do not specify a trap option, all options are enabled or disabled for the trap type.
• Example

  host1(config)#snmp-server enable traps atmPing trapfilters critical

• Use the no version to disable SNMP trap generation.
• See snmp-server enable traps.

snmp-server enable traps per-category-trapFilters

• Use to specify the trap severity level for a particular category without overwriting the existing global severity level, which applies to all enabled categories configured on the router.
• If you change the global trap severity level (which applies to all enabled categories) after you set the per-category trap severity level, the global severity level takes precedence over the per-category severity level.
• If you do not configure the per-category severity level, the global trap severity level (which applies to all enabled categories) takes effect for that category.

  Note: This command does not modify the severity level set for specific hosts using the snmp-server host command.

• If you configure global severity levels for different categories in succession, the last global severity level you configure is applied to all categories.
• Example 1—Configuring the per-category severity level without changing the global severity level
  1. Configure the global severity level as critical for all enabled trap categories by specifying the SONET trap category.

     host1(config)#snmp-server enable traps sonet trapFilters critical

  2. Configure the global severity level as notice for all enabled trap categories by specifying the BGP trap category.

     host1(config)#snmp-server enable traps bgp trapFilters notice

  3. Configure the per-category severity level as debug for the SONET trap category.

     host1(config)#snmp-server enable traps sonet per-category-trapFilters debug

  In this example, although you configure the category-specific severity level as debug for the SONET category in Step , the global severity level remains unchanged as notice. This behavior occurs because only the category-specific severity level was configured in the last operation.

• Example 2—Overwriting the global severity level to the last-configured setting
  1. Configure the global severity level as critical for all enabled trap categories by specifying the SONET trap category.

     host1(config)#snmp-server enable traps sonet trapFilters critical

  2. Configure the global severity level as notice for all enabled trap categories by specifying the BGP trap category.

     host1(config)#snmp-server enable traps bgp trapFilters notice

  Although you specify the type of SNMP trap category when you configure the global severity level, it takes effect for all enabled trap categories on the router. In this example, after you issue the second command, the global severity level is set as notice for all enabled trap categories.

• Example 3—Overriding the global severity level for a category with the per-category severity level
  1. Configure the global severity level as critical for the SONET trap category in the command.

     host1(config)#snmp-server enable traps sonet trapFilters critical

  2. Change the global severity level to notice for all enabled trap categories.

     host1(config)#snmp-server enable traps bgp trapFilters notice

  3. Configure the per-category severity level as debug for the SONET trap category. This setting overrides the notice trap severity level that was applicable for the SONET trap category.

     host1(config)#snmp-server enable traps sonet per-category-trapFilters debug

  The global severity level is configured as notice for all enabled trap categories except SONET, whose severity level is set as debug. This configuration occurs because the global severity level is overwritten to the last configured value and the per-category severity level takes precedence over the global severity level.

• There is no no version.
• See snmp-server enable traps.

snmp-server host

• Use to configure an SNMP trap host to refine the type and severity to traps that the host receives.
• A trap destination is the IP address of a client (network management station) that receives the SNMP traps.
• You can configure up to eight trap hosts on each virtual router.
• You can enable the traps listed in Trap Categories .
• You can filter traps according to the trap severity levels described in Table 22.
• Example

  host1(config)# snmp-server host 126.197.10.5 version 2c westford udp-port 162 snmp link trapfilters alert

• Use the no version to remove the specified host from the list of recipients.
• See snmp-server host.

snmp-server trap-source

• Use to specify the interface whose IP address is used as the source address for all SNMP traps.

  Note: When there are multiple IP addresses configured on the IP interface that is chosen as the SNMP trap source, the SNMP agent automatically uses the primary IP address of the interface as the SNMP source address on SNMP traps.

• Example

  host1(config)#snmp-server trap-source fastethernet 0/0

• Use the no version to remove the interface from the trap configuration.
• See snmp-server trap-source.

snmp trap ip link-status

• Use to enable link-status traps on an IP interface.
• Example

  host1(config-if)#snmp trap ip link-status

• Use the no version to disable link-status traps on an IP interface.
• See snmp trap ip link-status.

snmp trap ip link-status

• Use to configure the SNMP link-status traps on a particular interface.
• A link-up trap recognizes that a previously inactive link in the network has come up.
• A link-down trap recognizes a failure in one of the communication links represented in the server’s configuration.
• Example

  host1(config-controll)#snmp trap link-status

• Use the no version to disable these traps for the interface.

  Note: This command operates in Controller Configuration mode. It is supported only by the DS3, DS1, and FT1 interface layers.

• See snmp trap ip link-status.

traps

• Use to specify traps for OSPF.
• Example

  host1(config-router-rn)#traps all

• Use the no version to delete the specified trap, group of traps, or all traps.

  Note: For additional information about configuring OSPF-specific traps, see JUNOSe IP, IPv6, and IGP Configuration Guide.

• See traps.

Specifying an Egress Point for SNMP Traps

You can enable SNMP trap proxy, which allows you to specify a single SNMP agent as the egress point for SNMP traps from all other virtual routers. This feature removes the need to configure a network path from each virtual router to a single trap collector.

You can enable SNMP trap proxy from either SNMP or the CLI. Only one SNMP trap proxy can exist for a physical router.

The SNMP trap proxy does not forward global traps that it receives from other virtual routers. The corresponding SNMP agent handles global traps locally and does not forward them to the SNMP trap proxy.

To configure the SNMP trap proxy:

1. Access the virtual router context.
2. Enable or disable the SNMP trap proxy.

snmp-server trap-proxy

• Use to enable or disable the SNMP trap proxy.
• Example

  host1(config)#snmp-server trap-proxy enable

• Use the no version to disable the SNMP trap proxy.
• See snmp-server trap-proxy.

Configuring Trap Queues

You can control the SNMP trap egress rate, specify the method of handling a full queue, and specify the maximum number of traps kept in the queue.

snmp-server host

• Use to control the SNMP trap egress rate for the host that is receiving SNMP traps. Use one or more of the following keywords:
  • drainRate—Specifies the maximum number of traps per second sent to the host
  • full—Specifies the method for handling the queue full condition
  • size—Specifies the maximum number of traps kept in the queue
• Example

  host1(config)#snmp-server host 10.10.10.10 trapqueue drainrate 600 full droplastin size 50

• Use the no version to remove the SNMP host.
• See snmp-server host.

Configuring Trap Notification Logs

SNMP uses the User Datagram Protocol (UDP) to send traps. Because UDP does not guarantee delivery or provide flow control, some traps can be lost in transit to a destination address. The Notification Log MIB provides flow control support for UDP datagrams.

You should set up your management applications to periodically request the recorded traps to ensure that the host is up and the management applications have received all the generated traps.

To identify the location of traps logged in the notification log, the system assigns a consecutive index number to each SNMP trap message transmitted from the E-series router. Clients can use the index to detect missing traps.

To configure trap notification logs:

1. Configure the notification log.

   host1(config)snmp-server notificationlog log 10.10.4.4 adminStatus includeVarbinds

2. (Optional) Specify when the notification log ages out.

   host1(config)#snmp-server notificationlog ageout 5

3. (Optional) Specify the maximum number of entries kept in the notification log.

   host1(config)#snmp-server notificationlog entrylimit 210

4. (Optional) Enable the snmpTrap log to severity level info.

   host1(config)#log severity info snmpTrap

   Note: Enabling the snmpTrap log provides the same information in the router log as appears in the snmp-server notification log. However, long trap strings may appear truncated.

log severity

• Use to set the severity level for a selected category or for systemwide logs.

  Note: For more information about this command, see the JUNOSe System Event Logging Reference Guide.

• Example

  host1(config)#log severity info snmptrap

• Use the no version to return to the default severity value (error) for the selected category. To return all logs to their default severity setting, include an * (asterisk) with the no version.
• See log severity.

snmp-server notificationLog ageOut

• Use to set the ageout for traps in the notification log tables. The range is 0–214748364 minutes.
• Example

  host1(config)#snmp-server notificationLog ageout 5

• Use the no version to return the ageout limit to the default value, 1440 minutes.
• See snmp-server notificationLog ageOut.

snmp-server notificationLog entryLimit

• Use to set the maximum number of notifications kept in all notification log tables.
• The range is 1–500, which means that you can allocate up to 500 notifications across all virtual routers on the router. As you allocate the entry limits for virtual routers, the available range changes to reflect the number of notifications that you have allocated.
• Example

  host1(config)#snmp-server notificationLog entrylimit 210

• Use the no version to return the limit to the default value, 500.
• See snmp-server notificationLog entryLimit.

snmp-server notificationLog log

• Use to configure SNMP notification log tables.
• Use the adminStatus keyword to enable administrative status.
• Use the includeVarbinds keyword to include log names and log indexes in the trap’s variable bindings.
• Example

  host1(config)snmp-server notificationLog log 10.10.4.4 adminStatus includeVarbinds

• Use the no version to remove the notification log configuration.
• See snmp-server notificationLog log.

Recovering Lost Traps

SNMP traps can be lost during startup of the E-series router for one of the following reasons:

1. The SNMP agent begins sending SNMP traps to the host before the line module is initialized.
2. If the SNMP proxy virtual router is initialized after other virtual routers, traps generated by the other virtual routers and sent to the proxy router are lost.

To recover SNMP traps that are lost during system startup, the SNMP agent pings the configured trap host to identify that there is a communication path between E-series router and host. On successful ping acknowledgment, the lost traps are reconstructed for each virtual router. In the case of scenario 1, the reconstructed traps are sent to the proxy virtual router to be routed to the appropriate hosts. In the case of scenario 2, the traps are sent directly to the appropriate hosts.

You can configure the ping timeout window with the snmp-server host command. The following are guidelines for setting the maximum ping window:

• If you are losing traps because of scenario 1, base the maximum ping window time on the estimated time that it takes to establish connectivity in a particular network. (For some configurations it can take more than 30 minutes to establish connectivity.)
• If you are losing traps because of scenario 2, we recommend that you use the default value for the maximum ping window time, which is one minute.

snmp-server host

• Use to set the ping timeout for the host that is receiving SNMP traps.
• Use the pingtimeout keyword to set the ping timeout window; the range is 1–90 minutes.
• Example

  host1(config)#snmp-server host 10.10.4.4 pingtimeout 2

• Use the no version to remove the SNMP host.
• See snmp-server host.