nv-l
[Top] [All Lists]

Re: [NV-L] Ruleset Editing Questions

To: Tivoli NetView Discussions <nv-l@lists.ca.ibm.com>
Subject: Re: [NV-L] Ruleset Editing Questions
From: sean.lawrence@cantire.com
Date: Tue, 24 Oct 2006 11:15:46 -0400
Delivery-date: Tue, 24 Oct 2006 16:19:57 +0100
Envelope-to: nv-l-archive@lists.skills-1st.co.uk
List-help: <mailto:nv-l-request@lists.ca.ibm.com?subject=help>
List-id: Tivoli NetView Discussions <nv-l.lists.ca.ibm.com>
List-post: <mailto:nv-l@lists.ca.ibm.com>
List-subscribe: <http://lists.ca.ibm.com/mailman/listinfo/nv-l>, <mailto:nv-l-request@lists.ca.ibm.com?subject=subscribe>
List-unsubscribe: <http://lists.ca.ibm.com/mailman/listinfo/nv-l>, <mailto:nv-l-request@lists.ca.ibm.com?subject=unsubscribe>
Reply-to: Tivoli NetView Discussions <nv-l@lists.ca.ibm.com>
Sender: nv-l-bounces@lists.ca.ibm.com
I fixed the leading . on the OID. That was an experiment.

Sean Lawrence
Systems Automation
Ext 5728




James Shanks <jshanks@us.ibm.com>
Sent by: nv-l-bounces@lists.ca.ibm.com
10/24/2006 10:49 AM
Please respond to Tivoli NetView Discussions

 
        To:     Tivoli NetView Discussions <nv-l@lists.ca.ibm.com>
        cc: 
        Subject:        Re: [NV-L] Ruleset Editing Questions


The answer to your first question is yes. In order to make a trap have the 
category "Log Only", you have to build a trap definition for it in 
trapd.conf. If you have MIBs which define these traps, then you can use 
mib2trap to help you do that. The current default in mib2trap is "Log 
Only".

But mib2trap is not the easiest tool in the world to use so don't feel bad 
about having to ask questions about it if you need to.

The answer to your second question is that nvcorrd is running different 
rulesets for different users. Each user can run only one at a time. Most 
likely the forwardall.rs is being run for an event window. What happens in 
the processing of each ruleset is independent of the others. If you run 
the full trace (nvcdebug -d all) you can see that.

ESE.automation usually has nothing to do with TEC forwarding, unless you 
are doing it using your own postemsg scripts. The internal TEC adapter is 
part of nvserverd. What he gets is determined by the ruleset listed in 
/usr/OV/conf/tecint.conf, not ESE.automation. 

If you uncomment the line NvserverdTraceTecEvents=YES in tecint.conf, and 
reload it, either by restarting the daemon or using nvtecia -reload, then 
you will get /usr/OV/log/nvserverd.log, which will show what ruleset 
nvserverd currently registered, and what events he is sending to TEC, as 
well as how he formatted them. The only thing that won't be in the 
nvserverd.log are the events or slots added by the TEC State Correlation 
Engine, so you will not see the fqhostname slot for example.

But the point is that between the nvcorrd.alog/blog when the full trace is 
on (nvcdebug -d all) and the nvserverd.log, you can track just what events 
your ruleset passes to nvserverd and just how nvserverd formats them for 
TEC before they get sent. That should give you everything you need to 
track down a problem when you have one. 

However, I think I can save you the trouble by looking at just what you 
have posted already. Your nvcorrd.alog says
+  +  +  EventAttributes (Attr='EnterpriseID'  ne 
Value='.1.3.6.1.4.1.9.1.502')
The proper OID value would be just Value='1.3.6.1.4.1.9.1.502' without the 
leading dot. I am guessing that when you built the ruleset 
you typed in the OID value rather than using the select button and pulling 
it out of trapd.conf. Doing it the latter way would prevent you from 
making a mistake, whish is all the more reason to define your important 
traps in trapd.conf.

HTH,

James Shanks
Level 3 Support for Tivoli NetView for UNIX and Windows
Network Availability Management
Network Management - Development
Tivoli Software, IBM Corp
sean.lawrence@cantire.com


sean.lawrence@cantire.com 
Sent by: nv-l-bounces@lists.ca.ibm.com 
10/24/2006 09:56 AM 

Please respond to
Tivoli NetView Discussions <nv-l@lists.ca.ibm.com>




To

Tivoli NetView Discussions <nv-l@lists.ca.ibm.com>

cc


Subject

Re: [NV-L] Ruleset Editing Questions





Ok I ran the "nvcdebug -n" command. The output is as follows

2006/24/10 09:46:38   CorrelationDef.C[562] :   Current running 
correlation:
CorrelationDefinition(0x30033b08)
+  RootDnode
+  +  RuleSet forwardall.rs
+  +  +  Forward(19) Corrnode application=0x303d2888
+  +  RuleSet test.rs
+  +  +  EventAttributes (Attr='EnterpriseID'  ne 
Value='.1.3.6.1.4.1.9.1.502')
+  +  +  +  EventAttributes (Attr='Origin'  ne  Value='42.231.8.3')
+  +  +  +  +  EventAttributes (Attr='Origin'  ne  Value='42.2.1.12')
+  +  +  +  +  +  EventAttributes (Attr='Origin'  ne  Value='42.2.1.13')
+  +  +  +  +  +  +  EventAttributes (Attr='Origin'  ne  Value='0.0.0.0')
+  +  +  +  +  +  +  +  Forward(130) Corrnode application=0x30062d18

I do not know why the forwardall.rs is being loaded. The ESE.automation 
file is as follows

#This file should contain a list of filenames
#that will be autmatically started by actionsvr.
#Each rule set name is on a separate line; the pund sign
#indicates a comment line.
#An example line, with the name commented out) is below:
#your_ruleset_here.rs

Am I correct in assuming that the forwardall.rs is forwarding everything 
before the test.rs even gets a look at it?



Sean Lawrence
Systems Automation
Ext 5728




James Shanks <jshanks@us.ibm.com>
Sent by: nv-l-bounces@lists.ca.ibm.com
10/24/2006 09:16 AM
Please respond to Tivoli NetView Discussions


       To:     Tivoli NetView Discussions <nv-l@lists.ca.ibm.com>
       cc: 
       Subject:        Re: [NV-L] Ruleset Editing Questions


If you use xnmtrap and set the trap to "Log Only" It will not be sent to 
TEC nor display in your event windows but it will be kept in trapd.log so 
that you can gauge how many you are getting. You can also set the trapd to 

"Don't Log or Display" and this will keep it from the log as well, but 
then you'll have no way of knowing what's going on if start having a 
performance problem because too many of these traps are arriving.

Cisco devices are highly configurable. You usually can configure just the 
traps you want and even the frequency that they are sent. Perhaps you 
should talk to your network guys about that and solve the problem at the 
source. Remember that getting a lot of unwanted traps isn't just a 
nuisance. It's a performance issue, not just for NetView, but for everyone 

else on the same subnet. That's their potential bandwidth you are eating 
and throwing away. 

As for your ruleset, I'm not sure what it is supposed to say. Greater than 

or less than the OID? Why not just "not equal to" ?

But in any case you can tell exactly what ruleset you are running in two 
ways. If you are keeping an nvserverd.log, then the name will be in there, 

as will evidence of the reload. But whether you are or are not keeping the 

nvserverd.log, you can issue "nvcdebug -n" which will cause nvcorrd to 
write out in detail to his log what rulesets he is running. You can see 
the contents of the ruleset there. You can also debug this way by sending 
"nvcdebug -d all" and then observing what happens to each event as it is 
evaluated. Everything between the eyecatcher "Received a trap" and 
"Finished with the event" is nvcorrd processing that event.

James Shanks
Level 3 Support for Tivoli NetView for UNIX and Windows
Network Availability Management
Network Management - Development
Tivoli Software, IBM Corp
sean.lawrence@cantire.com


sean.lawrence@cantire.com 
Sent by: nv-l-bounces@lists.ca.ibm.com 
10/24/2006 08:13 AM 

Please respond to
Tivoli NetView Discussions <nv-l@lists.ca.ibm.com>




To

Tivoli NetView Discussions <nv-l@lists.ca.ibm.com>

cc


Subject

[NV-L] Ruleset Editing Questions





I am trying to set up some rules to filter out traps coming for 
Ciscoworks. We are getting way to many now that the network guys have 
turned it on.

Is there a way to simply drop traps that have not been defined in the 
trapd.conf? I do not want to keep them in Netview or forward them to TEC.

On a side note I am having trouble setting up simple rules.

I am receiving a trap from Ciscoworks with the OID of 1.3.6.1.4.1.9.1.502 
I do not want this forwarded to TEC

In the ruleset defined in tecint.conf I created an Event Attributes rule. 
It looks like this:

Event Stream -> (EnterpriseOID <>  1.3.6.1.4.1.9.1.502) -> Forward

I ran the nvtecia -reload command to reload the ruleset and I am still 
getting these forwarded. Is there something else required to load modified 


rulesets?

Sean
_______________________________________________
NV-L mailing list
NV-L@lists.ca.ibm.com
Unsubscribe:NV-L-leave@lists.ca.ibm.com
http://lists.ca.ibm.com/mailman/listinfo/nv-l (Browser access limited to 
internal IBM'ers only)


*** eSafe scanned this email for malicious content ***
*** IMPORTANT: Do not open attachments from unrecognized senders  ***
_______________________________________________
NV-L mailing list
NV-L@lists.ca.ibm.com
Unsubscribe:NV-L-leave@lists.ca.ibm.com
http://lists.ca.ibm.com/mailman/listinfo/nv-l (Browser access limited to 
internal IBM'ers only)



_______________________________________________
NV-L mailing list
NV-L@lists.ca.ibm.com
Unsubscribe:NV-L-leave@lists.ca.ibm.com
http://lists.ca.ibm.com/mailman/listinfo/nv-l (Browser access limited to 
internal IBM'ers only)


*** eSafe scanned this email for malicious content ***
*** IMPORTANT: Do not open attachments from unrecognized senders  ***
_______________________________________________
NV-L mailing list
NV-L@lists.ca.ibm.com
Unsubscribe:NV-L-leave@lists.ca.ibm.com
http://lists.ca.ibm.com/mailman/listinfo/nv-l (Browser access limited to 
internal IBM'ers only)



_______________________________________________
NV-L mailing list
NV-L@lists.ca.ibm.com
Unsubscribe:NV-L-leave@lists.ca.ibm.com
http://lists.ca.ibm.com/mailman/listinfo/nv-l (Browser access limited to 
internal IBM'ers only)

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

Archive operated by Skills 1st Ltd

See also: The NetView Web