SNMP Configuration

Trap Management Overview

The sequence of events in using these tables is as follows:

1.An event occurs and the Notification Originator goes to work.

2.The Notification Originator uses the notify table to identify possible targets to which to send a message. These are only possible targets because there may be notification filters setup to identify a subset of these possible targets that will be sent the message.

3.If no filters are set up (that is, no entry is in the snmpNotifyFilterProfileTable corresponding to this target), the Notification Originator can create and send the PDU(s). The process is then done.

4.If filters are on but the Notification Originator cannot find an entry for any of the specific targets, no PDUs can be sent. The process is then done.

5.If filters on and we have a filter entry, the Notification Originator checks the filter to see if it is set to include or exclude this target. If the filter is set to exclude this target, then the message need not be sent to this target.

6.If filters are on and the filter associated with the target provides a mask, the mask is used to see if this trap event can be sent to this target. The mask allows the Notification Originator to check if the OID of the trap and snmpTrapOID.0 matches the subtree that is in the notify filter table. That way, it can check for a certain event to send to a target, such as a warmStart message only.

7.Finally, using information from the target params table that is accessed from the target address table, the Notification Originator checks the target address (user information) to see if the entity has view privileges for the object. If the view is okay, the PDU(s) are sent. Either way, the process is completed. Views are checked whether or not filters exist.

Broadmore 1750 - Release 4.6

12-31

Page 349
Image 349
Carrier Access user manual Broadmore 1750 Release 12-31