[Top] [All Lists]

Re: RE: Event Correlation

To: nv-l@lists.tivoli.com
Subject: Re: RE: Event Correlation
From: "Gavin Newman" <NEWMANGJ@banksa.com.au>
Date: Wed, 05 Jul 2000 15:16:45 +0930
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 cost.

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 TMNC.
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

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

Archive operated by Skills 1st Ltd

See also: The NetView Web