thank you for your answer.
why, though, would the trapd.log show binary characters, from DeviceA for
TrapA, yet the trapd.log for DeviceB, sending the same TrapA, receives hex
characters? shouldn't the same trap, being received, from two different
devices, look the same in the trapd.log *IF* the mib is loaded correctly?
thanks
becki kain
________________________________
From: nv-l-bounces AT lists.ca.ibm DOT com [mailto:nv-l-bounces AT lists.ca.ibm
DOT com] On Behalf Of James Shanks
Sent: Monday, February 26, 2007 5:28 PM
To: Tivoli NetView Discussions
Subject: Re: [NV-L] Mibs/traps/oh my
Your results are normal if not ideal. trapd always tries to make the best sense
of the octet string he's passed. To avoid the problem of what to do with real
ASCII strings that the agent has padded with nulls (x'00') rather than spaces
(x'20') or other such sloppiness, he uses an algorithm that says that if more
than half of the incoming characters are not printable ASCII, then dump it to
hex. That's how you get this:
cvVoIPCallHistoryConnectionId.30521 (OctetString): 0xbf 9c 85 5b c4 88 11 db be
1c 94 1d c1 05 69 8b
But the results are sometimes problematic with smaller strings,especially if
some of the characters are printable, which is how you got this
cvVoIPCallHistoryConnectionId.91781 (OctetString): o]z|ۀ<
As a short term solution, an environment variable was introduced in 7.1.4 FP04
for IY50373 called TRAPD_STRICT_HEX_FORMAT. The Release Notes for FP04 describe
how to set it.:
* On UNIX, create a /usr/OV/bin/netnmrc.pre file with the
following line, or add the following line to the existing
usr/OV/bin/netnmrc.pre file:
export TRAPD_STRICT_HEX_FORMAT=TRUE
Restart all the daemons so the daemons inherit this variable.
Either reboot the NetView machine or use the ovstop nvsecd command to stop all
the daemons. Then use the /etc/netnmrc command (AIX) or the /etc/init.d/netnmrc
command (Solaris or Linux) to enable this change.
It's available on Windows too, but you set it with the Control Panel-->System.
Once you have done this, and restarted all the daemons, then trapd will dump
all octet strings that contain unprintable characters to hex.
The downside to this is that this is an all-or-nothing fix. After you implement
it, there's no way to deal with agents that are just sloppy as opposed to those
that are really sending hex data. If you don't have any sloppy agents in your
network, then you won't notice a difference, of course.
The ideal way to handle this situation would have been to add a new format
specifier to trapd.conf which would allow the user to specify that a particular
variable was always to be printed in hex. That would be much more granular. In
fact there was an enhancement request for that function, but there was not time
to implement this in 7.1.4 or 7.1.5. So the APAR fix is the only thing I can
offer.
James Shanks
Level 3 Support for Tivoli NetView for UNIX and Windows
Network Availability Management
Network Management - Development
Tivoli Software, IBM Corp
"Kain, Becki \(B.\)" <bkain1 AT ford DOT com>
"Kain, Becki \(B.\)" <bkain1 AT ford DOT com>
Sent by: nv-l-bounces AT lists.ca.ibm DOT com
02/26/2007 04:34 PM
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
[NV-L] Mibs/traps/oh my
This is one of those questions that I think I know the answer to, but I need to
confirm. We're getting a bunch of the following, in our trapd.log:
trapd.log:1172454271 3 Mon Feb 26 01:44:31 2007 bob.fred.ford.com A
cvdcMIBNotificationPrefix 6 1 5 args: [1] cvVoIPCallHistoryConnectionId.99381
(OctetString): 0xab 18 ef e2 c4 71 11 db 94 00 cd 24 e1 d2 a4 b3
trapd.log:1172466260 3 Mon Feb 26 05:04:20 2007 wilma.fred.ford.com A
cvdcMIBNotificationPrefix 6 1 5 args: [1] cvVoIPCallHistoryConnectionId.30521
(OctetString): 0xbf 9c 85 5b c4 88 11 db be 1c 94 1d c1 05 69 8b
Fine, right?
Then, we get this:
trapd.log:1172459214 3 Mon Feb 26 03:06:54 2007 bad.fred.ford.com A
cvdcMIBNotificationPrefix 6 1 5 args: [1] cvVoIPCallHistoryConnectionId.91781
(OctetString): o]z|ۀ<
(where the ending is binary garbage characters)
I'm being told that obvious the cisco mibs that are loaded are wrong. I think
it's the data that I'm being sent is bad. Can someone else shed some light on
this? Thanks
_______________________________________________
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)
_______________________________________________
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)
|
