Thanks James—that’s what I was looking for. Looks like it’s time
to turn tracing on and work with Dialogic. Also have FP03 installing in the
lab.
From: James Shanks
[mailto:jshanks@us.ibm.com]
Sent: Tuesday, December 02, 2008 10:28 AM
To: Tivoli NetView Discussions
Subject: Re: [NV-L] 7.1.5 FP2 AIX Traps from Dialogic device formatted
OK in trapd.log but being dropped in ruleset
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>
|
|
|
To
|
Tivoli NetView Discussions
<nv-l@lists.ca.ibm.com>
|
|
cc
|
|
|
Subject
|
[NV-L] 7.1.5 FP2 AIX Traps from Dialogic
device formatted OK in trapd.log but being dropped in ruleset
|
|
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)