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 AT lists.ca.ibm DOT com [mailto:nv-l-bounces AT lists.ca.ibm 
DOT 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 AT ust-global DOT com> 
Sent by: nv-l-bounces AT lists.ca.ibm DOT com 
02/24/2009 12:36 AM 
Please respond to
Tivoli NetView Discussions <nv-l AT lists.ca.ibm DOT com>

To
"Tivoli NetView Discussions" <nv-l AT lists.ca.ibm DOT 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 AT lists.ca.ibm DOT com [mailto:nv-l-bounces AT lists.ca.ibm 
DOT 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 AT ust-global DOT com> 
Sent by: nv-l-bounces AT lists.ca.ibm DOT com 
02/23/2009 10:24 AM 

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


To
"Tivoli NetView Discussions" <nv-l AT lists.ca.ibm DOT 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 
 

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