nv-l
[Top] [All Lists]

Re: [NV-L] Mibs/traps/oh my

To: Tivoli NetView Discussions <nv-l@lists.ca.ibm.com>
Subject: Re: [NV-L] Mibs/traps/oh my
From: James Shanks <jshanks@us.ibm.com>
Date: Mon, 26 Feb 2007 17:28:04 -0500
Delivery-date: Mon, 26 Feb 2007 22:29:05 +0000
Envelope-to: nv-l-archive@lists.skills-1st.co.uk
In-reply-to: <4B7EE6C5FCFF304D9A1880844C82AE46013801E8@na1fcm08.dearborn.ford.com>
List-help: <mailto:nv-l-request@lists.ca.ibm.com?subject=help>
List-id: Tivoli NetView Discussions <nv-l.lists.ca.ibm.com>
List-post: <mailto:nv-l@lists.ca.ibm.com>
List-subscribe: <http://lists.ca.ibm.com/mailman/listinfo/nv-l>, <mailto:nv-l-request@lists.ca.ibm.com?subject=subscribe>
List-unsubscribe: <http://lists.ca.ibm.com/mailman/listinfo/nv-l>, <mailto:nv-l-request@lists.ca.ibm.com?subject=unsubscribe>
Reply-to: Tivoli NetView Discussions <nv-l@lists.ca.ibm.com>
Sender: nv-l-bounces@lists.ca.ibm.com

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
Inactive hide details for "Kain, Becki \(B.\)" <bkain1@ford.com>"Kain, Becki \(B.\)" <bkain1@ford.com>


          "Kain, Becki \(B.\)" <bkain1@ford.com>
          Sent by: nv-l-bounces@lists.ca.ibm.com

          02/26/2007 04:34 PM
          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] 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@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)

GIF image

_______________________________________________
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)
<Prev in Thread] Current Thread [Next in Thread>

Archive operated by Skills 1st Ltd

See also: The NetView Web