Configuring Traps

This section provides information for:

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

Severity Number	Severity Name	System Response
0	Emergency	System unusable
1	Alert	Immediate action needed
2	Critical	Critical conditions exist
3	Error	Error conditions exist
4	Warning	Warning conditions exist
5	Notice	Normal but significant conditions exist
6	Informational	Informational messages
7	Debug	Debug messages

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:

An event is posted to the SNMP agent.
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.
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 3, 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:

Access the virtual router context.
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:

Configure the notification log.
host1(config)snmp-server notificationlog log 10.10.4.4 adminStatus includeVarbinds
(Optional) Specify when the notification log ages out.
host1(config)#snmp-server notificationlog ageout 5
(Optional) Specify the maximum number of entries kept in the notification log.
host1(config)#snmp-server notificationlog entrylimit 210
(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:

The SNMP agent begins sending SNMP traps to the host before the line module is initialized.
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.