Scott -
I am sorry if you thought I was patronizing you but when you are trying to
diagnose someone else's problem remotely you have to ask dumb queations
since you cannot be sure what has been done otherwise. It is no reflection
on you. It is just the nature of the process.
This trapd.conf you included the excerpt from is the one in /usr/OV/conf/C,
correct? And when you run xnmtrap, you can find these traps in there,
correct? And trapd has been restarted since you added them, correct? Then
the only thing I can see which might be the problem is that according to
the definitions, the trap OID should be 1.3.6.1.4.1.1569.2.9.0, but what we
got was 1.3.6.1.4.1.1569.2.9. Now if it were reversed, and the trap
contaiined more places than the defined OID, then we would assign it to the
lesser one with the closest fit. But I don't think we can recognize the
".0" as being unimportant. Is the enterprise id in the first part of the
file the same way? If so, then my advice is to use xnmtrap to take the
trailing ".0" off all the places where it occurs, click 'OK" and see if
that solves the problem.
James Shanks
Team Leader, Level 3 Support
Tivoli NetView for UNIX and NT
"Scott Hammons" <s.hammons@ais-nms.com>@tkg.com on 03/08/2001 04:57:15 PM
Please respond to IBM NetView Discussion <nv-l@tkg.com>
Sent by: owner-nv-l@tkg.com
To: "IBM NetView Discussion" <nv-l@tkg.com>
cc:
Subject: RE: [NV-L] Unknown Trap
James,
Yes, I am confused because I did use the script that was created by the
mib2trap command to add the trap into the trapd.conf file. I even verified
that the Enterprise ID and trap definitions were in the file manually by
using the vi editor. I just didn't include that in my original post as I
assumed everyone would have known that when you use the mib2trap command
you
have to run the script that is created.
Here is a copy of the portions of the trapd.conf file where the script
added
the definitions
###################
#
# enterprises:
#
extender {1.3.6.1.4.1.1569.2.9.0}
EDESC
extAlarmFatal {1.3.6.1.4.1.1569.2.9.0} 6 1 A 4 0 "Log Only Events"
$E $1
EVENT_CLASS extAlarmFatal
SDESC
An Extender fatal event has occurred.
IfIndex: index of communication link in MIB-2 Interfaces table.
extAlarm: a DisplayString containing a textual description of
the current fatal alarm.
EDESC
extAlarmError {1.3.6.1.4.1.1569.2.9.0} 6 2 A 5 0 "Log Only Events"
$E $1
EVENT_CLASS extAlarmError
SDESC
An Extender error condition has occurred.
IfIndex: index of communication link in MIB-2 Interfaces table.
extAlarm: a DisplayString containing a textual description of
the current Error alarm.
EDESC
extAlarmWarning {1.3.6.1.4.1.1569.2.9.0} 6 3 A 2 0 "Log Only Events"
$E $1
EVENT_CLASS extAlarmWarning
SDESC
An Extender event has occurred which generates a warning.
IfIndex: index of communication link in MIB-2 Interfaces table.
extAlarm: a DisplayString containing a textual description of
the current Warning alarm.
EDESC
extAlarmInfo {1.3.6.1.4.1.1569.2.9.0} 6 4 A 3 0 "Log Only Events"
$E $1
EVENT_CLASS extAlarmInfo
SDESC
An Extender event has occurred which generates an informational message.
IfIndex: index of communication link in MIB-2 Interfaces table.
extAlarm: a DisplayString containing a textual description of
the current Informational alarm.
Now here is a copy of the actual trap:
'Trap found with no known format in trapd.conf(4) Enterprise ENTERPRISES
(1.3.6.1.4.1.1569.2.9) community
proxy@v2@public@10.176.67.56@162 generic trap:6 specific trap:2 '
Scott
-----Original Message-----
From: owner-nv-l@tkg.com [mailto:owner-nv-l@tkg.com]On Behalf Of
James_Shanks@tivoli.com
Sent: Thursday, March 08, 2001 4:21 PM
To: IBM NetView Discussion
Subject: Re: [NV-L] Unknown Trap
Scott -
You are confused about something but I am not sure exactly what. If the
trap is coming in and you see one of those unknown format messages in the
trapd.log then it is not defined in trapd.conf, no matter what you did with
MIBs and mib2trap. Some part of the trap is therefore different from what
was extracted from the MIB by mib2trap or the addtrap script was not run.
Remember that when you do run mib2trap, what it creates is an addtrap
script you must run to actually update trapd.conf. Could you have missed
that step? In any case, my advice is to use the entry in trapd.log as a
guide and run xnmtrap to manually add the correct trap or to modify the
entry that is already there. All the information such as enterprise id,
specific trap number and variable content will be in the log.
And you are correct about "Browse MIB" from the events panel. it does not
work if you have an SNMPV2 MIB you loaded. It only shows you what is in
the V1 database.
James Shanks
Team Leader, Level 3 Support
Tivoli NetView for UNIX and NT
"Scott Hammons" <s.hammons@ais-nms.com>@tkg.com on 03/08/2001 02:02:18 PM
Please respond to IBM NetView Discussion <nv-l@tkg.com>
Sent by: owner-nv-l@tkg.com
To: <nv-l@tkg.com>
cc:
Subject: [NV-L] Unknown Trap
Hello all,
I have a trap I'm receiving from a device that has been showing up as
unknown. After talking to the owner of the equipment, who assured me that
the software revision was at the current level, I was able to obtain the
MIB
from the vendor. The MIB was in version 2 format, so I loaded it up and
added the definitions to the trapd.conf file using the LOAD/UNLOAD MIB and
the mib2trap process.
The problem is that the traps are still coming in as unknown. What is
weird
about the situation is I issued the trap myself with the snmptrap command
and when the trap came in as unknown, I selected browse MIB and it is
attempting to go to the SNMP MIB file location not the SNMPV1/SNMPV2
location, where I loaded the MIB. I can't load the MIB under SNMP because
the format is in V2. So has anyone encountered this before?
Thanks in advance for the help.
Scott Hammons, Consultant
Tivoli Certified Consultant
Advanced Integrated Solutions, Inc.
www.ais-nms.com
Email s.hammons@ais-nms.com
Voice Pager (888) 520-0517
Cellular (210) 378-8229
_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l
_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l
_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l
|