I don't know the specifics on this particular device, but from a trap troubleshooting perspective, you might try compiling the same MIB with a 3rd party MIB compiler and send some test traps to NV using expected values for the varbinds. Then you can at least narrow it down to good MIB/bad varbind values in which case most likely a vendor agent issue. Just a thought.

 

hth,

 

--
Justin Eagleson
Gulf Breeze Software
www.gulfsoft.com

 

On 2/26/07, Kain, Becki (B.) <bkain1 AT ford DOT com> wrote:

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)