|
Are you sure that there is only one entry in trapd.conf for this trap and that it is NOT set to "Log Only"? Then tracing is your only option.
>"This entry in trapd is from the device and never makes it to nvserverd.log"
If you are sure that it is not in the nvserverd.log then you'll need to turn on nvcorrd tracing to see whether it was ever delivered to nvserverd. Use nvcdebug -d all. The nvcorrd.alog and nvcorrd.blog will alternate every thousand lines o tracing so you don't have to worry about them getting to large but you will have to vigilant to catch the problem so the data is not lost. You can reset the trace at any time with nvcdebug -r .
That's the only way to determine whether this is true or not:
>"I wonder if the device is passing hidden params or characters that trapd’s fine with, but cause the ruleset to drop it. "
You should also make plans to get current. FP03 has been out for quite some time and it provides fixes to trapd and nvserverd to better handle hex nulls (0x"00") when these are used as padding in octet strings. That doesn't sound like your problem however.
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
 "Van Order, Drew (US - Hermitage)" <dvanorder@deloitte.com>
"Van Order, Drew (US - Hermitage)" <dvanorder@deloitte.com>
Sent by: nv-l-bounces@lists.ca.ibm.com
12/02/2008 10:38 AM
Please respond to
Tivoli NetView Discussions <nv-l@lists.ca.ibm.com> |
|
|
Hi folks,
Wondering if someone has a suggestion for why a trap from the Dialogic device itself that reads fine in trapd.log would not make it through nvserverd processing, yet a test trap I send using the trapgen commandline tool will? At first I wondered if the brackets were causing trouble, but testing proved that’s not the case. Looking for ideas before I start turning on tracing/opening a PMR.
The ruleset is very simple, traps are filtered by Enterprise ID, and forwarded to TEC.
This entry in trapd is from the device and never makes it to nvserverd.log:
1228138568 3 Mon Dec 01 07:36:08 2008 10.15.0.22 A Dialogic DMG
Alarm Trap: Alarm Index = 27, Alarm ID = 64, Severity = 2 (1 = most severe), Des
cription = Gateway Warning, Device = 0, Message = VoIP[10.27.8.58] In-Service
This entry in trapd is from the trapgen tool, and makes it to nvserverd/TEC with no problem
1228229728 3 Tue Dec 02 08:55:28 2008 10.30.15.120 A Dialogic DMG
Alarm Trap: Alarm Index = Test, Alarm ID = Test1, Severity = Test2 (1 = most severe),
Description = Test3, Device = Test4, Message = Test[In Brackets] message
Thanks!--Drew
This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message.
Any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. [v.E.1]_______________________________________________
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)
|
