NINO uses a SNMP trapd proces to receive all traps. If a device sends a SNMP trap, then NINO will store this event into the database. In the status window a list of categories will be displayed with the severity level. In the event function the eventlog can be displayed. Also the device list and Node map will show the severity status per device.
NINO uses the trapd.conf file to define all possible events with the right severity level. This trapd.conf file can be downloaded from www.cisco.com or www.hp.com and is compatible with HP Openview. Additional event actions and event recovery definitions can be created into text files. In the NINO install procedure this files will be stored into the database. After installation the database is created and all NINO processes can be started. The event configuration can also be altered after installation using the NINO user interface. This includes event severity level, description, event action, sound alerts, event filters etc.
If a SNMP trap is received the next steps are taken:
NINO has several event functions available to display the events. The main functions will display the status (categories, devices and 3D Map) or the eventlog (eventlog/userlog, summary, SQL). If additional customizing of events is needed an event edit function is available in NINO. The next event functions are available:
The event function is able to show the eventlog in many ways. Events can be filtered by category, user defined filters, severity or host. Also a search string can be enetered to view only events that match the search string. More advanced is the Summary and SQL option in Function. The Summary option will categorize all events by Host, EventOID, Event and count the number of events. The SQL option will enable SQL queries to be entered in the search field. This SQL queries will be fired upon the database, even beyond the eventlog table. So every kind of information can be customized. The example below shows the event function and the standard eventlog.
The default event filters can filter events per category. However it is also possible to create user defined filters. Press the Filter button to edit or create your own event filters. The filter can combine multiple severity levels and categories. User defined filters are stored as SQL query in the database (see also Save Query). In the example below the filter will only show high severity alerts on specific categories.
To view the eventlog, press the GO button.
Id | EventName | EventOID | Nodes |
---|---|---|---|
1 | RMON_Rise_Alarm | .1.3.6.1.2.1.16.0.1 | |
2 | RMON_Falling_Alarm | .1.3.6.1.2.1.16.0.2 | |
3 | RMON_Packet_Match | .1.3.6.1.2.1.16.0.3 | |
4 | EnterpriseDefault | .1.3.6.1.4.1.* | |
5 | OV_Default | .1.3.6.1.4.1.11.2.17.1.* | |
6 | OV_IF_Marginal | .1.3.6.1.4.1.11.2.17.1.0.40000000 | |
7 | OV_IF_IP_Addr_Chg | .1.3.6.1.4.1.11.2.17.1.0.40000001 | |
8 | OV_Network_SubMskChg | .1.3.6.1.4.1.11.2.17.1.0.40000002 | |
9 | OV_Connection_Up | .1.3.6.1.4.1.11.2.17.1.0.40000003 | |
10 | OV_Connection_Down | .1.3.6.1.4.1.11.2.17.1.0.40000004 | |
11 | OV_Connection_Marg | .1.3.6.1.4.1.11.2.17.1.0.40000005 | |
12 | OV_DataCollect_Check | .1.3.6.1.4.1.11.2.17.1.0.40000006 | |
13 | OV_IF_Disconnected_Segs | .1.3.6.1.4.1.11.2.17.1.0.40000007 |
The next screen can be used to edit the event definitions, such as Severity, Category, Action and the textfields to edit the name, description, OID and Recovery OID. Use the Submit button to update the event definitions or the New button to create a new event. The Delete button deletes the event.
The recovery OID is used in the eventaction proces to auto-acknowledge this event if a recovery event occurs. An example is the LinkDown and LinkUp trap. If an interface goes down, a LinkDown trap is send. The recovery OID is the LinkUp OID, so the LinkDown event is auto-recovered when a LinkUp trap is received.
The Nodes field is empty by default, so traps of all nodes are stored into the eventlog. Fill in the nodes field if specific actions or definitions are required for a node/device. An event may be duplicated to respond in a different way on several nodes, e.g. a serial link down on a router can be Major severity, but a link down on a hub with PC's can be normal severity. Also event actions may be different on several nodes.
The next event actions are available:
It is also possible to link several event actions. An example is to check an non recovered event in a time window, this will send a new trap. The next step is to define a SMS or e-mail notification on this new trap. This could be a LinkDown trap of a FrameRelay connection with e-mail notification. The simple solution is to configure an e-mail notification on a LinkDown event. But what should you do if the link just has a dip for one second and the link recoveres without any problems ? In most cases a network administrator only wants to have a notification (or SMS in the middle of the night...) if the link is really down and not for a minor dip of one or two seconds. The LinkDown events are logged in the eventlog, so the information is never lost. Example flowchart:
EVENT A IS RECEIVED | WAIT 5 MINUTES UNTIL EVENT IS RECOVERED | EVENT A NOT RECOVERED IN 5 MINUTES | SEND TRAP B, BECASUE A IS NOT RECOVERED | EVENT B IS RECEIVED | SEND MAIL TO ADMINISTRATOR |
All event configuration input windows are displayed below with an OSPF event as example.
Event 7 | ospfNbrStateChange |
---|---|
EventName: | |
EventOID: | |
RecoveryOID: | |
Nodes: | |
Format description: |
Severity | Category | Action | Change | New | Delete |
---|---|---|---|---|---|
The e-mail notification properties can be filled in here:
Event 7 | ospfNbrStateChange |
---|---|
EventOID: | .1.3.6.1.2.1.14.16.2.2 |
Format description: | ospfNbrStateChange trap received from enterprise $E |
Category: | LOGONLY |
Severity: | Normal |
Action: | |
Send e-mail to: | |
Apply: |
The forward trap action properties can be filled in here:
Event 7 | ospfNbrStateChange |
---|---|
EventOID: | .1.3.6.1.2.1.14.16.2.2 |
Format description: | ospfNbrStateChange trap received from enterprise $E |
Category: | LOGONLY |
Severity: | Minor |
Action: | forward |
SNMP trap OID: | |
SNMP trap specific: | |
Apply: |
The command properties can be filled in here:
Event 7 | ospfNbrStateChange |
---|---|
EventOID: | .1.3.6.1.2.1.14.16.2.2 |
Format description: | ospfNbrStateChange trap received from enterprise $E |
Category: | LOGONLY |
Severity: | Normal |
Action: | command |
Command: | |
Apply: |
The count action properties can be filled in here:
Event 7 | ospfNbrStateChange |
---|---|
EventOID: | .1.3.6.1.2.1.14.16.2.2 |
Format description: | ospfNbrStateChange trap received from enterprise $E |
Category: | LOGONLY |
Severity: | Minor |
Action: | count |
Timewindow (minutes): | |
Count events: | |
SNMP trap OID: | |
SNMP trap specific: | |
Apply: |
The no_recovery action properties can be filled in here:
Event 7 | ospfNbrStateChange |
---|---|
EventOID: | .1.3.6.1.2.1.14.16.2.2 |
Format description: | ospfNbrStateChange trap received from enterprise $E |
Category: | LOGONLY |
Severity: | Minor |
Action: | no_recovery |
Timewindow (minutes): | |
SNMP trap OID: | |
SNMP trap specific: | |
Apply: |
The count_or_no_recovery action properties can be filled in here:
Event 7 | ospfNbrStateChange |
---|---|
EventOID: | .1.3.6.1.2.1.14.16.2.2 |
Format description: | ospfNbrStateChange trap received from enterprise $E |
Category: | LOGONLY |
Severity: | Minor |
Action: | count_or_no_recovery |
Timewindow (minutes): | |
Count events: | |
SNMP trap OID: | |
SNMP trap specific: | |
Apply: |