|
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@lists.ca.ibm.com [mailto:nv-l-bounces@lists.ca.ibm.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:
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@ford.com>
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@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) |
