Traps and Logging

Traps represent a far more timely and efficient mechanism for detecting and isolating faults. The drawback is that they are not reliable. If a router malfunctions, it may not send traps; if network connectivity is completely broken as a result of a failure, the trap may never be received. As a result, the typical arrangement for fault management primarily relies on traps, but is backed up by "slow" polling, on the order of a minute or more.

On Cisco routers, if you use the snmp-server enable traps [notification-type] in global configuration mode without specifying a [notification-type], all traps are enabled. By listing particular notification types after the traps keyword, you may limit the type of traps sent. Use the snmp-server host command to send traps to a particular host. You can also tune the type of traps received by each host on an individual basis using snmp-server host host community-string [notification-type].

It is useful to monitor and record at the NMS all traps/notifications, with particular emphasis on the following notification-type options:

bgp

BGP state change traps

config

SNMP config traps

entity

SNMP entity traps

envmon

SNMP environmental monitor traps

frame-relay

SNMP Frame Relay traps

isdn

SNMP isdn traps

snmp

SNMP traps

syslog

SYSLOG messages sent as traps

A full description of these can be found at ftp://ftpeng.cisco.com/pub/mibs/traps.

A full description of these can be found at ftp://ftpeng.cisco.com/pub/mibs/traps.

The Cisco logging facility can also be used to great effect. It offers an even wider selection of state-change information, particularly relating to routing protocols. The Cisco IOS Software System Error Messages, as well as the Debug Command Reference, serve as the definitive sources of information on the types, reasons, and recommended operator responses to each logging message. Table 15-4 lists the eight levels of error messages generated by Cisco routers.

Was this article helpful?

0 0

Post a comment