[Top] [All Lists]

Re: RE: Event Correlation

To: nv-l@lists.tivoli.com
Subject: Re: RE: Event Correlation
From: lclark@us.ibm.com
Date: Wed, 5 Jul 2000 09:15:47 -0400

Good assessment, Gavin. I would just add that in NV V6, netmon does
adjust the order in which it does its status polling in an attempt to
minimize the
number of down events generated before the suppression kicks in. It can do
this because it knows which routers have interfaces on the subnet that the
allegedly-down node is on and can check them asap, thus determining whether
it is the subnet that is unreachable, or only that node. This algorithm is
efficient.  And V6.0.1 will give some more options on how it actually


Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking

"Gavin Newman" <NEWMANGJ@banksa.com.au>@tkg.com on 07/05/2000 01:46:45 AM

Please respond to IBM NetView Discussion <nv-l@tkg.com>

Sent by:  owner-nv-l@tkg.com

To:   nv-l@tkg.com
Subject:  Re: RE: [NV-L] Event Correlation

The difference between 2 & 3 is $$$$$$$.

As I understand it RFI is indeed included in NV6.0 and able to be
"unlocked" by a script. As explained to me this works as follows...

If a device fails any events related to devices "behind" that (from
Netview's perspective) are dropped and polling of these devices is
suspended until the failed device recovers HOWEVER the results of any
polling for the "behind" devices takes place before the poll of the failed
device will be processed as normal. The outcome of this is that Netview and
Tivoli TEC may still get and display events for these devices before
Netview polls the real failed device and invokes RFI to suppress the
"falsely down" devices. Depending on the size and topology of the network
you may still receive a lot of false alarms before the real cause is
discovered and acted upon. This is not real Root Cause Analysis but is zero

On the other hand Root Cause Analysis is implemented by the TMNC
(previously known as TFNC) product (refer to the excellent red-book
SG24-585-xx). This product "tanks" all events for a pre-determind period of
time and analyses them in conjunction with a map of the topology it
extracts peridically from the NV databases. If this analysis resolves that
a failure of a device will cause false alarms from other devices due to the
topology of the network it will drop the false alarm events there and then
and only forward and process the event related to the real cause of the
mess - ie the failed device. The differences between this TMNC process and
the RFI process are as follows.
1) Events are held for a time to allow for analysis in TMNC - false alarms
arriving before the real alarm are still dropped as part of the analysis
whereas in RFI the false alarms that arrive before the real alarm are not
2) No false alarms are displayed, logged or sent to TEC (if used) under
3) The downside is that this tanking process may delay the display and
acting on the real error - refer to the red book mentioned above for a
really good explanation of the impact of this shortcoming.
4) Most importantly the TMNC product costs $$$$$$. It is tier based
dependant on a formula taking factoring in the number of routers, switches
and ports therein to arrive at a cost.
5) If you are using Netview to forward to TEC there will be baroc file and
rule changes required - these are explained in the red-book and the TMNC
user guide.

Hope this helps - Gavin Newman

>>> "SZEWCZYK, Jack" <jszewczyk@WESTPAC.COM.AU> 05/07/2000 13:17:46 >>>

The functionality you describe is implemented in Netview 6.0
    1) event suppression or
    2) RFI (router fault isolation)or
    3) root cause analysis

I think all these terms refer to the same thing - not generating the alarms
and relaxing polling interval for the devices which are in "unreachable"
part of
the network.

This feauture is not enabled in 6.0 by default, will be available in 6.0a
(by default)
and there is a script (contact your Tivoli rep.) to enable in NV6.0

Could someone explain the differences between 1 and 2 and 3 or
are they the same thing (just a different name)?

Hope this helps,


Jack Szewczyk                    |  email: jszewczyk@westpac.com.au
Network Systems Administrator    |
Westpac Banking Corporation      +---------------------------------
Level 2, 72 Christie Street      |   phone: +61 2 9902 6497
St Leonards NSW 2065/AUSTRALIA   |   fax:   +61 2 9902 5111

-----Original Message-----
From: Salinas Sangines Guillermo [mailto:gsalinas@SCANDA.COM.MX]
Sent: Wednesday, 5 July 2000 5:11
To: 'NetView'
Subject: [NV-L] Event Correlation

Hi, I'm configuring the event correlation feature on NetView 6.0 for Unix
As I understand, one of the primary function of an event correlator, is to
filter multiple alarms.
An example is: if nodes B, C and D, are switches connected to a router A,
and router A goes down. The event correlation functionality would filter
alarms from nodes B, C and D, and only take actions on the alarm from node

Well, does someone knows how to configure this on NetView 6.0 ?
I've seen the RuleSet Editor, with the default rulesets (NodeDown/NodeUp,
But it doesn't looks like this rules resolve the example I've posted.


Guillermo Salinas Sanginés
Omniscope - México DF
tel. 5422-2700 ext.6033

NV-L List information and Archives: http://www.tkg.com/nv-l
NV-L List information and Archives: http://www.tkg.com/nv-l

   *****   IMPORTANT INFORMATION    *****
This document should be read only by those persons to whom
it is addressed and its content is not intended for use by
any other persons. If you have received this message in
error, please notify us immediately. Please also destroy and
delete the message from your computer. Any unauthorised form
of reproduction of this message is strictly prohibited.
Bank SA is not liable for the proper and complete transmission
of the information contained in this communication, nor for any
delay in its receipt.
NV-L List information and Archives: http://www.tkg.com/nv-l

<Prev in Thread] Current Thread [Next in Thread>

Archive operated by Skills 1st Ltd

See also: The NetView Web