nv-l
[Top] [All Lists]

RE: [NV-L] trapd forwarding to tec

To: "Tivoli NetView Discussions" <nv-l@lists.ca.ibm.com>
Subject: RE: [NV-L] trapd forwarding to tec
From: "Senthil Kumar Mani" <Senthil.Mani@ust-global.com>
Date: Tue, 24 Feb 2009 19:46:34 +0530
Delivery-date: Tue, 24 Feb 2009 14:16:32 +0000
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
Thread-index: AcmWgzyHxR4vhEZwT+imTNeVe/RwlQAAOVeQAAFm0cAAAC16kA==
Thread-topic: RE: [NV-L] trapd forwarding to tec
Yes, that is true. 

So I presume if I add a 0 suffix to the enterprise ID may resolve the issue.

Moreover, I have enabled the nvcorrd debug (nvcdebug –d rules) but the logs are 
being written so fast that I am not able to follow it.

Would you please help me to get this sorted? 

Thanks
Senny

From: nv-l-bounces@lists.ca.ibm.com [mailto:nv-l-bounces@lists.ca.ibm.com] On 
Behalf Of Leslie Clark
Sent: Tuesday, February 24, 2009 6:53 PM
To: Tivoli NetView Discussions
Subject: RE: [NV-L] trapd forwarding to tec


Not so. The trap formatting is more forgiving. An enterprise of 1.3.6.1.4.1 in 
trapd.conf will match 1.3.6.1.4.1.* from a device.  So there is hope. 

Cordially,

Leslie A. Clark
IT Services Specialist, Network Mgmt
Information Technology Services Americas
IBM Global Services
(248) 552-4968 Voicemail, Fax, Pager
"Senthil Kumar Mani" <Senthil.Mani@ust-global.com> 
Sent by: nv-l-bounces@lists.ca.ibm.com 
02/24/2009 12:36 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] trapd forwarding to tec







Thanks Leslie! 
  
I shall definitely do that and try to trace where is the root cause. I have one 
more query, if the trapd.log is showing the message from device properly 
formatted, does that mean the trap format is proper and enterprise ID also 
matching. 
  
I assume if the enterprise ID the device is sending is not matching with the 
trap definition what we loaded on NetView, then the trapd.log will show unknown 
format. Please correct me if I am wrong. 
  
Thanks 
Senny 
  
From: nv-l-bounces@lists.ca.ibm.com [mailto:nv-l-bounces@lists.ca.ibm.com] On 
Behalf Of Leslie Clark
Sent: Monday, February 23, 2009 9:44 PM
To: Tivoli NetView Discussions
Subject: RE: [NV-L] trapd forwarding to tec 
  

The most likely cause is that the traps from the devices and the traps you are 
generating are not using the exact same enterprise, generic, and specific trap 
ids. Devices don't always send what you expect from looking at the MIB. 
Sometimes there is an extra 0 or something on the enterprise. To see what 
exactly is coming in from the devices. you need to turn on tracing. 

nvcdebug -d rules 

Then watch in /usr/OV/log/nvcorrd.alog and blog to see how it is deciding 
whether to forward or not. 

Cordially,

Leslie A. Clark
IT Services Specialist, Network Mgmt
Information Technology Services Americas
IBM Global Services
(248) 552-4968 Voicemail, Fax, Pager
"Senthil Kumar Mani" <Senthil.Mani@ust-global.com> 
Sent by: nv-l-bounces@lists.ca.ibm.com 
02/23/2009 10:24 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] trapd forwarding to tec

  








Thanks James! 
 
But I have the rule specified in my ruleset TEC_ITS.rs to forward the events to 
TEC. Moreover when I try to send a test trap with the same enterprise ID using 
SNMPTRAP utility, I can see these events are being forwarded to TEC. Here my 
issue is with the traps forwarded by the actual device those are not reaching 
TEC; though it manages to reach in trapd.log. 
 
Also I checked and all the event property under discussion is in “Status 
Events”. 
 
Still need help☺ 

Regards 
Senny 
 
From: nv-l-bounces@lists.ca.ibm.com [mailto:nv-l-bounces@lists.ca.ibm.com] On 
Behalf Of James Shanks
Sent: Monday, February 23, 2009 8:45 PM
To: Tivoli NetView Discussions
Subject: RE: [NV-L] trapd forwarding to tec 
  
On Unix, only those traps selected by the TEC ruleset specified in 
/usr/OV/conf/tecint.conf will be forwarded to TEC. The flow is like this:

trapd gets all traps --> sends all traps to nvcorrd --> nvcorrd selects traps 
to forward to TEC using the ruleset specified in tecint.conf --> selected traps 
are sent to nvserverd for formatting and sending to TEC --> nvserverd formats 
the trap, logs it, and gives it to the TEC EEIF library for sending.

If your trap is trapd.log but not in nvserverd.log, then it never made it 
through the ruleset specified for TEC. The standard ruleset is TEC_ITS.rs. It 
only selects a basic subset of NetView events to send to TEC. If you want to 
add others, then you have to edit the ruleset. 

Note that some users select forwardall.rs as their TEC ruleset but this can be 
prone to problems, especially performance ones because it sends a lot of stuff 
to TEC. TEC is not designed to handle large volumes of worthless information. 
Using forwardall.rs is not officially supported. 

James Shanks
Tivoli Network Availability Management Level Three 
Network Availability Management
Tivoli Software, IBM Corp
1-919-224-1642 | T/L 687-1642 | ITN 26871642
"Senthil Kumar Mani" <Senthil.Mani@ust-global.com> 
"Senthil Kumar Mani" <Senthil.Mani@ust-global.com> 
Sent by: nv-l-bounces@lists.ca.ibm.com 
02/23/2009 09:57 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] trapd forwarding to tec


  
  





Hi,

I have this issue too. 

I have all the events are being forwarded to TEC from NetView but the recently 
added Trap definition is not being forwarded to TEC. I enabled NVServerd Trace 
but no luck (No event seen inside the log).

My problem here is the same. I mean I can see the event sent by the device in 
trapd.log, but not been seen in nververd.log and TEC.

If I manually send a test trap with the help of snmptrap command, I am 
receiving this event on TEC. What other thing could raise this kind of issue?

Need help!

Thank
Senny

From: nv-l-bounces@lists.ca.ibm.com [mailto:nv-l-bounces@lists.ca.ibm.com] On 
Behalf Of JaneTaylor@HBOSplc.com
Sent: Thursday, February 19, 2009 9:22 PM
To: nv-l@lists.ca.ibm.com
Subject: RE: [NV-L] trapd forwarding to tec

Thanks. The traps appear in trapd.log so I'm assuming it's a rulesest issue. 
I'll give nvcdebug a try and may raise this with support. We have fix pack 5 in 
plan for second half of the year so maybe I can push to get this brought 
forward.

Thanks for you help.

Jane 

  
________________________________________


From: nv-l-bounces@lists.ca.ibm.com [mailto:nv-l-bounces@lists.ca.ibm.com] On 
Behalf Of James Shanks
Sent: 19 February 2009 15:37
To: Tivoli NetView Discussions
Subject: Re: [NV-L] trapd forwarding to tec 
Tracking down missing events is not something I recommend customers do on their 
own without help from Support, but I will explain how to do it.

The first thing I would do is start running the nvserverd trace. nvserverd is 
the daemon who send events to TEC. You can trace his activities by editing 
/usr/OV/conf/tecint.conf and uncommenting the line
#NvserverdTraceTecEvents=YES
Then you can get nvserverd to reload the file with the command
nvtecia -reload

This will cause nvserverd to write every event he processes to a new file, 
/usr/OV/log/nvserverd.log. When you think you have missed an event in TEC, look 
in this file and see whether it was logged. If you see it logged then nvserverd 
gave it to the TEC library code for forwarding but the adapter suppressed it 
for some reason. In that case, you'll have to open a problem to the TEC folks 
to get them to help you trace the adapter code. After nvserverd write the event 
to his log, he is blind to what happens to it after that. You will need to 
monitor the growth of the nvserverd.log. There is no size limit and no code to 
restart it after it grows to a certain size. If you delete or rename it while 
nvserverd is running, he will simply start writing to a new copy.


If you are missing the event in TEC, and it's in the trapd.log but you don't 
see it in the nvserverd.log, then I would suspect a ruleset problem. To 
diagnose that you can start running the nvcorrd trace. nvcorrd is the daemon 
who gets events from trapd and correlates them before passing them on to 
nvserverd for display or forward. To do that you would issue
nvcdebug -d all
This will cause nvcorrd to start writing what he is doing to the nvcorrd.alog. 
After he has written a 1000 lines, he switches to the nvcorrd.blog. After a 
another 1000 lines there, he switches back to the alog again and so it goes, 
alternating between the logs so that they don't get too big. But on a busy 
system they fill up fast, so as soon as you notice a problem you might want to 
shut him down or copy the logs so they don't get overwritten. Alternatively you 
could edit the /usr OV/conf/ovsuf file and edit it
0:nvcorrd:/usr/OV/bin/nvcorrd:OVs_YES_START:nvsecd,trapd::OVs_WELL_BEHAVED::/usr/OV/conf/FFDC/scripts/nvcorrd_FFDC:5:
to add a log file parameter to nvserverd's definition, like this
0:nvserverd:/usr/OV/bin/nvserverd:OVs_YES_START:nvsecd,nvcorrd:-l/usr/OV/log/mynvcorrd.log:OVs_WELL_BEHAVED:30:/usr/OV/conf/FFDC/scripts/nvserverd_FFDC:5:

If you do this nvcorrd will only write to that log rather than switch. But you 
will have to manage it, just as you do with nvserverd.log.

That's about all I can tell you except that when nvcorrd gets an event you will 
see a "received an event" eyecatcher in the log. Immediately thereafter you 
will see him try to match it to one of the rulesets he is running. If the match 
is successful he'll write out all the parameters of that event. Then you will 
see him process any actions for that event and finally forward it on. He'll do 
this for each ruleset in turn and when he's down with each of them you will see 
another eyecatcher in the log which reads "finished with the event".

Now having said all that, I would urge you to get help from Support with this. 
And I would also urge you to get current first. FixPack5 has been available 
since December 2006 and there have been fixes made to TEC forwarding. You are 
so far behind on maintenance that it is difficult to guess where the problem 
lies. Do your missing Compaq traps have null data in them? Long strings of hex 
zeros? We fixed a problem like that some time ago. And that's why you should 
get current before trying to figure this out. Your problem might already be 
solved. 

James Shanks
Tivoli Network Availability Management Level Three 
Network Availability Management
Tivoli Software, IBM Corp
1-919-224-1642 | T/L 687-1642 | ITN 26871642
JaneTaylor@HBOSplc.com 
JaneTaylor@HBOSplc.com 
Sent by: nv-l-bounces@lists.ca.ibm.com 
02/19/2009 07:20 AM 
  

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

  

To

nv-l@lists.ca.ibm.com 
cc

Subject

[NV-L] trapd forwarding to tec
  
  





Hi

In my forwarding rule set I have the compaq enterprise selected and then a 
number of specific traps selected to forward to tec. Some of these get 
forwarded and other don't. As far as I can see the traps are all set up in the 
same way with the event category set to Status Event.

If I generate one using serversetup, that gets straight through to tec so I'm 
assuming this doesn't go through the ruleset. Is this correct and can anyone 
offer any suggestions as to how I can track down the problem? I'm running on 
AIX, with Netview 7.14 FP4

Thanks

Jane 

-----------------------------------------------------------------------------------------------------
HBOS plc, Registered in Scotland No. SC218813. Registered Office: The Mound, 
Edinburgh EH1 1YZ. HBOS plc is a holding company, subsidiaries of which are 
authorised and regulated by the Financial Services Authority.
==============================================================================
_______________________________________________
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)

-----------------------------------------------------------------------------------------------------
HBOS plc, Registered in Scotland No. SC218813. Registered Office: The Mound, 
Edinburgh EH1 1YZ. HBOS plc is a holding company, subsidiaries of which are 
authorised and regulated by the Financial Services Authority.
==============================================================================_______________________________________________
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)_______________________________________________
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