SNMP Notification Receiver
NSO can act as an SNMP notification receiver (v1, v2c, v3) for
its managed
devices. The application can register notification handlers and
react on the notifications, for example by mapping SNMP
notifications to NSO alarms.
The notification receiver is started in the Java VM by
application code, as described below. The application code
registers the handlers, which are invoked when a notification is
received from a managed device. The NSO operator can enable and
disable the notification receiver as needed. The notification
receiver is configured in the
/snmp-notification-receiver
subtree.
By default nothing happens with SNMP Notifications. You need to
register a function to listen to traps and do something useful
with the traps. First of all SNMP var-binds are typically sparse
in information and in many cases you want to do enrichment of
the information and map the notification to some meaningful
state. Sometimes a notification indicates an alarm state change,
sometimes they indicate that the configuration of the device has
changed. The action based on the two above examples are very
different, in the first case you want to interpret the
notification for meaningful alarm information and submit a call
to the NSO Alarm Manager. In the second case you probably want
to initiate a check-sync, compare-config, sync action
sequence.
Configuring NSO to Receive SNMP Notifications
The NSO operator must enable the SNMP notification receiver, and
configure the addresses NSO will use to listen for
notifications.
The primary parameters for the Notification receiver are shown below.
The notification reception can be turned on and off using the
enabled lead. NSO will listen to notifications at the
end-points configured in listen
. There is no
need to manually configure the NSO engine-id
. NSO
will do this automatically using the algorithm described
in RFC 3411. However, it can be assigned an engine-id
manually by setting this leaf.
The managed devices must also be configured to
send notifications to the NSO addresses.
NSO silently ignores any notification received from unknown
devices. By default, NSO uses the
/devices/device/address
leaf, but this can be
overridden by setting
/devices/device/snmp-notification-address
.
There are some standard built-in filters for the SNMP notification
receiver which perform standard tasks.
Standard filter for suppression of received snmp events
which are not of type TRAP, NOTIFICATION or INFORM.
Standard filter for suppression of notifications
emanating from ip addresses outside defined set of addresses
This filter determines the source ip address first from the
snmpTrapAddress 1.3.6.1.6.3.18.1.3 varbind if this is set in the PDU,
or otherwise from the emanating peer ip address.
If the resulting ip address does not match either the
snmp-notification-address
or the address
leaf
of any device in the device-model this notification is discarded.
Standard filter that will acknowledge INFORM notification automatically.
NSO uses the Java package SNMP4J to parse the SNMP PDUs.
Notification Handlers are user supplied Java classes that
implement the
com.tailf.snmp.snmp4j.NotificationHandler
interface. The processPDU
method is expected to
react on the SNMP4J event, e.g. by mapping the PDU to an NSO
alarm. The handlers are registered in the
NotificationReceiver
. The
NotificationReceiver
is the main class that in
addition to maintain the handlers also has responsibility to
read the NSO SNMP notification configuration, and setup SNMP4J
listeners accordingly.
An example of a notification handler can be found at
$NCS_DIR/examples.ncs/snmp-notification-receiver
.
This example handler receives notifications and sets an alarm text
if the notification is an IF-MIB::linkDown trap.
The instantiation and start of the
NotificationReceiver
as well as registration of
notification handlers are all expected to be done in the same
application component of some NSO package. The following is an example
of such an application component: