Configuring Traps

This section provides information for:

• Enabling trap generation
• Setting up filtering of traps by severity
• Configuring trap destinations
• Setting a source address for traps
• Enabling link status traps
• Specifying an egress point for 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 system (the server). Each entry in the table contains:

• IP address of the trap destination
• Community name (v1 or v2c) or user name (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 system supports the following trap categories:

• addrPool - local address pool
• atmPing - ERX system proprietary ATM ping
• bgp - BGP state change
• bulkstats - bulk statistics file full and nearly full
• cliSecurityAlert - security alert
• dvmrp - DVMRP
• dvmrpUni - ERX system proprietary DVMRP
• environment - power, temperature, fan, and memory utilization
• fileXfer - file transfer status change
• inventory - system inventory and status
• link - SNMP linkUp and linkDown
• log - system log capacity
• ntp - ERX system proprietary traps
• ospf - OSPF
• ping - ping operation (in disman remops MIB)
• radius - RADIUS servers fail to respond to accounting and authentication requests or servers return to active service
• snmp - SNMP coldstart, warmstart, authenticationFailure; the trap option. The snmp-server enable traps snmp authentication command allows customized treatment for SNMP authentication failure traps
• traceroute - traceroute operation (in disman remops MIB)

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 system provides a method of filtering traps according to severity. Table 3-7 describes the supported severity levels.

Table 3-7 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 a global filter to filter all traps and/or set up a filter for each host. Trap filters work as follows:

1. An event is posted to the SNMP agent.
2. The system checks whether the corresponding trap category is globally enabled and whether the trap meets the minimum global severity level.

1. If the trap does not meet these criteria, the system discards the trap.
2. If the trap does meet these criteria, the trap is handed to the trap host processor.

3. The trap host processor checks whether the trap category is enabled on the host and whether the trap meets the minimum severity level set for the host.

1. If the trap does not meet these criteria, the system discards the trap.
2. 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 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 earlier in this chapter.
• You can filter traps according to the trap severity levels described in Table 3-7.
• 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.

    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 earlier in this chapter.
• You can filter traps according to the trap severity levels described in Table 3-7.
• 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.

    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.

    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.

    snmp trap 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.

    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 ERX Routing Protocols Configuration Guide, Vol. 1, Chapter 8, Configuring OSPF.

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

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.

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.

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 ERX system. Clients can use the index to detect missing traps.

To configure trap notification logs:

1. Enable the snmpTrap log to severity level info.

host1(config)#log severity info snmpTrap

2. Configure the notification log.

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

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

host1(config)#snmp-server notificationlog ageout 5

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

host1(config)#snmp-server notificationlog entrylimit 210 

    log severity

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

Note: For more information on this command, see Chapter 11, Logging System Events.

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

    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.

    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.

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

Recovering Lost Traps

SNMP traps can be lost during startup of the ERX system 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 ERX system 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, you should 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).
• 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.