RE: [TEC] snmp adapter problems

John:

No the order of things in the .oid file shouldn't matter.

It doesn't look like a full trace of the adapter below because I don't see 
"Trap End" from DRVSPEC. Are you able to separate DRVSPEC and TECIO to 
separate log files in tecad_snmp.err, restart the snmp adapter, and have 
someone send another cpqDa6LogDrvStatusChange trap to the adapter?

For example, I don't see cpqDaCntlrHwLocation, cpqDaLogDrvCntlrIndex, 
cpqDaLogDrvIndex or cpqDaLogDrvStatus varbinds in the DRVSPEC trace, so I 
question whether DRVSPEC ever received those varbinds in the actual trap, 
if not, it will fail to send it to TEC at the first SELECT that it 
couldn't match to a varbind, which would be cpqDaCntlrHwLocation .

If  you can't reconfig the debugging on the adapter, do you have any more 
of the trace you could forward? The full DRVSPEC module trace tells you 
what varbinds were in the raw trap as it came into the adapter, and TECIO 
tells you what was then send to TEC. My guess is that a varbind is not 
being received in DRVSPEC from the raw trap, and the adapter is expecting 
it in the SELECT portion of the .cds config, so it's not being forwarded 
by TECIO.

Justin Eagleson
Enterprise Systems Management, JPMorganChase
office: 614-213-9017
pager: 877-864-2056
cell: 614-226-1148



Justin Eagleson

"John Guadagnino" <John_Guadagnino-/ycjK0B6GM4@xxxxxxxxxxxxxxxx>
Sent by: owner-tme10-XtjxT7Vmt5b1ENwx4SLHqw@xxxxxxxxxxxxxxxx
11/30/2004 04:41 PM
Please respond to tme10
 
        To:     tme10-XtjxT7Vmt5b1ENwx4SLHqw@xxxxxxxxxxxxxxxx
        cc: 
        Subject:        RE: [tme10] [TEC] snmp adapter problems


Hi Justin,

I sent all modules to the same file ... the trace below is from my single 
output file.  As luck would have it, I can't get to that particular box 
today to retrieve the entire logfile.  However, I can tell you that the 
conf file has no exclusions or other filters in it.  Here is the specific 
event definition from my cds file:

CLASS cpqDa6LogDrvStatusChange
  SELECT
    1: ATTR(=,$ENTERPRISE), VALUE(PREFIX, "1.3.6.1.4.1.232") ;
    2: $SPECIFIC = 3034 ;
    3: ATTR(=,"sysName") ;
    4: ATTR(=,"cpqHoTrapFlags") ;
    5: ATTR(=,"cpqDaCntlrHwLocation") ;
    6: ATTR(=,"cpqDaLogDrvCntlrIndex") ;
    7: ATTR(=,"cpqDaLogDrvIndex") ;
    8: ATTR(=,"cpqDaLogDrvStatus") ;
  MAP
    sysName = $V3 ;
    cpqHoTrapFlags = $V4 ;
    cpqDaCntlrHwLocation = $V5 ;
    cpqDaLogDrvCntlrIndex = $V6 ;
    cpqDaLogDrvIndex = $V7 ;
    cpqDaLogDrvStatus = $V8 ;
    msg = PRINTF("Logical Drive Status Change: Status is now %d.",$V8);
    severity = CRITICAL;
END


And here is the definition of this trap from the Compaq mib file:

    cpqDa6LogDrvStatusChange TRAP-TYPE
        ENTERPRISE compaq
        VARIABLES  { sysName, cpqHoTrapFlags, cpqDaCntlrHwLocation,
                     cpqDaLogDrvCntlrIndex, cpqDaLogDrvIndex,
                     cpqDaLogDrvStatus }
        DESCRIPTION
            "Logical Drive Status Change.

            This trap signifies that the agent has detected a change in 
the
            status of a drive array logical drive.  The variable
            cpqDaLogDrvStatus indicates the current logical drive status."

        --#TYPE "Logical Drive Status Change"
        --#SUMMARY "Status is now %d."
        --#ARGUMENTS {5}
        --#SEVERITY CRITICAL
        --#TIMEINDEX 99

        ::= 3034

I am no expert at snmp in general, nor the snmp adapter in specific, but 
it looks to me that my cds definition fits the mib definition properly. I 
am very unclear on what the .oid file does, though.  I can see that the 
oid file does not list the specific traps, but seems to be identifying the 
individual arguments of the traps ... e.g, 

"cpqDaCntlrHwLocation"          "1.3.6.1.4.1.232.3.2.2.1.1.20"
"cpqDaLogDrvCntlrIndex"         "1.3.6.1.4.1.232.3.2.3.1.1.1"
"cpqDaLogDrvIndex"              "1.3.6.1.4.1.232.3.2.3.1.1.2"
"cpqDaLogDrvStatus"             "1.3.6.1.4.1.232.3.2.3.1.1.4"


Can anyone tell me if the order of the entries in the oid file is 
important?  I found nothing in the adapters guide to help me here ... when 
I compiled/combined all the mibs into one and ran it through the mib2tec 
script, the oid file had a lot of duplicate entries, and they were in no 
particular order -- actually they were in order of the definitions by mib, 
but not in alphabetical or numerical order by arg name or oid value.  I 
manually edited that oid file to eliminate duplicate entries, and I 
reordered everything to be in oid order. These attributes are not in the 
same order as they appear in the event definition in either the cds or 
mib.


thx,

John Guadagnino
Gap Inc.


-----Original Message-----
From: owner-tme10-XtjxT7Vmt5b1ENwx4SLHqw@xxxxxxxxxxxxxxxx
[mailto:owner-tme10-XtjxT7Vmt5b1ENwx4SLHqw@xxxxxxxxxxxxxxxx]On Behalf Of
justin_eagleson-n1yi7zhirBtBDgjK7y7TUQ@xxxxxxxxxxxxxxxx
Sent: Tuesday, November 30, 2004 12:56 PM
To: tme10-XtjxT7Vmt5b1ENwx4SLHqw@xxxxxxxxxxxxxxxx
Subject: Re: [tme10] [TEC] snmp adapter problems


John:

I should have clarified below that in my experience it makes 
troubleshooting the adapter easier if tecad_snmp.err is setup to send the 
debug output for each module to a separate file (e.g. here I setup TECIO 
module to output to /tmp/snmp_tecio.log, DRVSPEC goes to 
/tmp/snmp_drvspec.log, etc.). Not sure if you were already doing that also 

or sending them all to the same file...

Regards,

Justin Eagleson
Enterprise Systems Management, JPMorganChase
office: 614-213-9017
pager: 877-864-2056
cell: 614-226-1148



Justin Eagleson

justin_eagleson-n1yi7zhirBtBDgjK7y7TUQ@xxxxxxxxxxxxxxxx
Sent by: owner-tme10-XtjxT7Vmt5b1ENwx4SLHqw@xxxxxxxxxxxxxxxx
11/30/2004 02:55 PM
Please respond to tme10
 
        To:     tme10-XtjxT7Vmt5b1ENwx4SLHqw@xxxxxxxxxxxxxxxx
        cc: 
        Subject:        Re: [tme10] [TEC] snmp adapter problems


Hi John. 

Can you post the DRVSPEC and TECIO debug (set these modules to output to a 


file in tecad_snmp.err if you haven't already), along with the 
corresponding .cds  and .conf definitions for cpqDa6LogDrvStatusChange? 

If it's making it into DRVSPEC, but not TECIO, then it could be 1) 
tecad_snmp.conf filtering has this Event Class filtered out or 2) there is 


a varbind defined in the SELECT in the .cds that is not being passed in 
the actual trap, which you can check by comparing DRVSPEC with the .cds 
definition and see what's different. 

There may be other scenarios I'm not thinking of right now, but that's a 
good place to start looking.

Regards,

Justin Eagleson
Enterprise Systems Management, JPMorganChase
office: 614-213-9017
pager: 877-864-2056
cell: 614-226-1148



Justin Eagleson

"John Guadagnino" <John_Guadagnino-/ycjK0B6GM4@xxxxxxxxxxxxxxxx>
Sent by: owner-tme10-XtjxT7Vmt5b1ENwx4SLHqw@xxxxxxxxxxxxxxxx
11/30/2004 02:25 PM
Please respond to tme10
 
        To:     "Tme10list (E-mail)" 
<tme10-XtjxT7Vmt5b1ENwx4SLHqw@xxxxxxxxxxxxxxxx>
        cc: 
        Subject:        [tme10] [TEC] snmp adapter problems


fwk 411
tec 39
ep 41104
interp linux-ix86

I am trying to use the Tivoli SNMP adapter to pick up Insight Manager 
traps on some linux boxes.  I originally installed the HP-provided 
components (the OID & CDS files) but soon discovered that they were in 
fact missing a lot of traps that IM was throwing.  I had the IM admin here 


send me his mibs, and then I used the mib2tec script to convert them ... 
all told, his mibs contain about 1100 traps whereas the HP-provided IM 
definitions contained only about 700 traps.  We ran a test where an admin 
pulled a disk (broke the mirror) which generated a 3034 trap ... 
'cpqDa6LogDrvStatusChange' as defined in the MIBs.  But this trap did not 
generate a Tivoli Event.  I reviewed the CDS & OID files, and found that 
this trap is not defined in the HP-provided integration files.

Great.

So I merged all the mibs, ran it through mib2tec and manually edited the 
results as needed just to make it run, but it is not working properly. 
I've got every trap from the MIBs clearly defined in the CDS file, but the 


adapter still won't generate a Tivoli event when we test it.  Again, we 
pulled a disk, generated a 3034 trap, and it failed to process properly 
... here's my trace ( I set everything in the tecad_snmp.err file to write 


to a log):


 849852 Trying Class "cpqDa6LogDrvStatusChange"
 849853 Wed Nov 24 10:45:54 2004  NORMAL: SELECT , err 00, 
ibtecad/select.c line 0067: Entered TECAD_EvalSelect
 849854  Name: TECAD_TYPE 1     11      "ENTERPRISE"    <--- testing for 
the 'enterprise' string of the received trap ...
 849855   Key: TECAD_TYPE 4     0       NULL
 849856 Value: TECAD_TYPE 1     15      "1.3.6.1.4.1.232"     <--- the 
value of the enterprise string, in this case the Compaq/HP enterprise 
string 
 849857
 849858 Wed Nov 24 10:45:54 2004 VERBOSE: KERNEL , err 00, 
cad/evaluation.c line 0094: TECAD_GetConstantEntry Index <976>
 849859 Wed Nov 24 10:45:54 2004  NORMAL: SELECT , err 00, 
ibtecad/select.c line 0510: Enter TECAD_TestSelectValue 1 1 15 15 
775106097 775106097
 849860 Wed Nov 24 10:45:54 2004  NORMAL: SELECT , err 00, 
ibtecad/select.c line 0513: Test_Value: 135105288
 849861 Wed Nov 24 10:45:54 2004  NORMAL: SELECT , err 00, 
ibtecad/select.c line 0516: Value: 137766040
 849862 Wed Nov 24 10:45:54 2004  NORMAL: SELECT , err 00, 
ibtecad/select.c line 0221: Correct is TRUE              <--- this says 
the trap matched our definition, so far so good
 849863  Name: TECAD_TYPE 1     8       "SPECIFIC"     <--- testing for 
the 'specific' trap type
 849864   Key: TECAD_TYPE 4     0       NULL
 849865 Value: TECAD_TYPE 2     4       "3034"     <--- the trap 
"specific" id is 3034 which matches the 'cpqDa6LogDrvStatusChange' trap as 


defined in the Compaq mib
 849866
 849867 Wed Nov 24 10:45:54 2004 VERBOSE: KERNEL , err 00, 
cad/evaluation.c line 0094: TECAD_GetConstantEntry Index <977>
 849868 Wed Nov 24 10:45:54 2004  NORMAL: SELECT , err 00, 
ibtecad/select.c line 0510: Enter TECAD_TestSelectValue 2 2 4 4 3034 3034
 849869 Wed Nov 24 10:45:54 2004  NORMAL: SELECT , err 00, 
ibtecad/select.c line 0513: Test_Value: 135105400
 849870 Wed Nov 24 10:45:54 2004  NORMAL: SELECT , err 00, 
ibtecad/select.c line 0516: Value: 137765864
 849871 Wed Nov 24 10:45:54 2004  NORMAL: SELECT , err 00, 
ibtecad/select.c line 0221: Correct is TRUE              <--- this says 
that the 'specific' trap id matched our definition, again this is good.
 849872 Wed Nov 24 10:45:54 2004 VERBOSE: KERNEL , err 00, 
cad/evaluation.c line 0094: TECAD_GetConstantEntry Index <978>
 849873  Name: TECAD_TYPE 1     7       "sysName"     <-- the sysName 
variable
 849874   Key: TECAD_TYPE 1     0       ""
 849875 Value: TECAD_TYPE 1     8       "tlrcc005"     <-- contains the 
hostname 
 849876
 849877 Wed Nov 24 10:45:54 2004  NORMAL: SELECT , err 00, 
ibtecad/select.c line 0221: Correct is TRUE              <-- matches our 
definition
 849878 Wed Nov 24 10:45:54 2004 VERBOSE: KERNEL , err 00, 
cad/evaluation.c line 0094: TECAD_GetConstantEntry Index <979>
 849879  Name: TECAD_TYPE 1     14      "cpqHoTrapFlags"     <--- the 
cpqHoTrapFlags variable
 849880   Key: TECAD_TYPE 1     0       ""
 849881 Value: TECAD_TYPE 2     4       "0"                      <--- 
contains this value 
 849882
 849883 Wed Nov 24 10:45:54 2004  NORMAL: SELECT , err 00, 
ibtecad/select.c line 0221: Correct is TRUE              <-- matches our 
definition
 849884 Wed Nov 24 10:45:54 2004 VERBOSE: KERNEL , err 00, 
cad/evaluation.c line 0094: TECAD_GetConstantEntry Index <980>
 849885 Wed Nov 24 10:45:54 2004  NORMAL: SELECT , err 00, 
ibtecad/select.c line 0277: Finished TECAD_EvalSelect, returning FALSE 
<--- WHAT FAILED???? I have no idea why it failed at this point.



I cannot see anything to indicate why this trap failed ("returning FALSE" 
... line 849885) ... can anybody offer some hints or tips on how to debug 
this or otherwise figure out what is going on?


tia,

John Guadagnino
Gap Inc.








This transmission may contain information that is privileged, confidential 
and/or exempt from disclosure under applicable law. If you are not the intended 
recipient, you are hereby notified that any disclosure, copying, distribution, 
or use of the information contained herein (including any reliance thereon) is 
STRICTLY PROHIBITED. If you received this transmission in error, please 
immediately contact the sender and destroy the material in its entirety, 
whether in electronic or hard copy format. Thank you.