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 state change traps


SNMP config traps


SNMP entity traps


SNMP environmental monitor traps


SNMP Frame Relay traps


SNMP isdn traps


SNMP traps


SYSLOG messages sent as traps

A full description of these can be found at

A full description of these can be found at

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