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
dropped.
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 >>>
Guillermo,
The functionality you describe is implemented in Netview 6.0
as:
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
-------------------------------------------------------------------
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
(AIX).
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
A.
Well, does someone knows how to configure this on NetView 6.0 ?
I've seen the RuleSet Editor, with the default rulesets (NodeDown/NodeUp,
InterfaceDown/InterfaceUp).
But it doesn't looks like this rules resolve the example I've posted.
Regards
Guillermo Salinas Sanginés
Omniscope - México DF
tel. 5422-2700 ext.6033
mailto:gsalinas@scanda.com.mx
_________________________________________________________________________
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
|