If you believe that NetView is broken, then you should call IBM Support.
This forum is just a user exchange.
Your trace data is interesting, but the real question is not what a third
party trace tells you, but what comes to trapd's socket.
I would get a trapd.trace and call Support. They'll wan to see the MIB
and the addtrap script too, and probably your trapd.conf file
You do that by using serversetup to set the "hex dump all packets" option
for trapd so that he starts and runs with the -x operand.
Then you can toggle the trace on and off from the command line with "trapd
-T".
If the trapd.trace confirms the issue, then IBM Support will take an APAR
(Authorized Program Analysis Request) and get you a fix, though you have
to get in the queue behind prior problems, of course.
Might I suggest a possible work around? trapd formats an incoming trap
to the best of his ability, using a "best fit" methodology. He only
reports "no known format" when he has no other options. If the full OID
is not found, he will drop back to the closest one, unless there are no
others. So if you change your enterprise id in for VCS in trapd.conf to
be less than 1.3.6.1.4.1.1302.3.8.10.2.6, by dropping the last digit or even
the last couple, it will be found.
I realize that is not what you want but it might reduce the clutter while
Support pursues your problem.
Regards
James Shanks
Level 3 Support for Tivoli NetView for UNIX and NT
Tivoli Software / IBM Software Group
"Jerald Jackson" <Jerald.Jackson@bcbsnc.com>
10/08/2002 05:08 PM
To: "<"
cc:
Subject: [nv-l] trapd dropping last digit from incoming snmpv2
traps?
Using: Netview 7.1.2 and AIX 4.3.3
I have seen quite a few posts that hint at this, but am just experiencing
the pain for myself.
I am attempting to catch events generated from a veritas cluster server
(VCS). The VCS
product will only send traps in snmpv2 format.
I formated addtrap lines using the mib2trap command on the vcs.mib file
distributed by Veritas
and modified the result to forward to another NetView server, then ran the
resulting addtrap
commands.
The /usr/OV/conf/C/trapd.conf file contains the following configuration
for the trap I then sent
as a test:
/usr/OV/conf/C/trapd.conf
===============================================================================
clusterGUIUserLoginTrap {1.3.6.1.4.1.1302.3.8.10.2.6} 6 2 A 2 0
"Application Alert Events"
VCS user has logged in
FORWARD
EVENT_CLASS clusterGUIUserLoginTrap
BEGIN_SLOT_MAPPING
severityId $V1
eventTime $V2
entityName $V3
entityType $V4
entitySubType $V5
entityState $V6
trapOrigin $V7
systemName $V8
systemLocation $V9
entityContainer $V10
entityOwner $V11
message $V12
END_SLOT_MAPPING
SDESC
The VCS GUI user log in.
EDESC
================================================================================
The result of sending that trap displayed the following in the nvevents
window.
nvevents
================================================================================
? Trap found with no known format in trapd.conf(4)
Enterprise Veritas-VCS (1.3.6.1.4.1.1302.3.8.10.2) community public
generic trap:6 specific trap:2
Timestamp:35540000 Agentaddr:svcah02 args(10):
[1] private.enterprises.1302.3.8.10.1.15 (Integer): 0
[2] private.enterprises.1302.3.8.10.1.14 (OctetString): Tue Oct 8
16:44:31 2002
[3] private.enterprises.1302.3.8.10.1.4 (OctetString): hostname1
[4] private.enterprises.1302.3.8.10.1.2 (OctetString): VCS
[5] private.enterprises.1302.3.8.10.1.3 (OctetString): user1
[6] private.enterprises.1302.3.8.10.1.8 (OctetString): User has logged
into VCS
[7] private.enterprises.1302.3.8.10.1.1 (OctetString):
Veritas_Cluster_Server
[8] private.enterprises.1302.3.8.10.1.6 (OctetString): hostname1
[9] private.enterprises.1302.3.8.10.1.10 (OctetString): BFDBcluster1
[10] private.enterprises.1302.3.8.10.1.9 (OctetString): VCS
SPECIFIC : 2 (hex: 2)
GENERIC : 6
CATEGORY : Status Events
ENTERPRISE : ENTERPRISES 1.3.6.1.4.1.1302.3.8.10.2
SOURCE : Source not known (?)
HOSTNAME : hostname1
SEVERITY : Indeterminate
LOGGEDTIME : 10/08/02 16:43:47
================================================================================
It appears to me that the trapd for NetView is dropping the "6" from the
end of the OID.
It should be 1.3.6.1.4.1.1302.3.8.10.2.6 with a specific of "2".
The VCS cluster is sending the correct trap info as seen below. I
basically used snmptrapd -P from the Net-SNMP
open source package to verify the following:
Output from Net-SNMP snmptrapd -P
================================================================================
2002-10-08 16:48:43 2002-10-08 16:48:43 NET-SNMP version 5.0.5 Started.
2002-10-08 16:48:51 2002-10-08 16:48:51 svcah02 [192.168.22.114]:
SNMPv2-MIB::sysUpTime.0 = Timeticks: (35580000) 4 days, 2:50:00.00
SNMPv2-MIB::snmpTrapOID.0 = OID:
SNMPv2-SMI::enterprises.1302.3.8.10.2.6.2
SNMPv2-SMI::enterprises.1302.3.8.10.1.15 = INTEGER: 0
SNMPv2-SMI::enterprises.1302.3.8.10.1.14 = STRING: "Tue Oct 8 16:49:34
2002." SNMPv2-SMI::enterprises.1302.3.8.10.1.4 = STRING: "hostname1"
SNMPv2-SMI::enterprises.1302.3.8.10.1.2 = STRING: "VCS"
SNMPv2-SMI::enterprises.1302.3.8.10.1.3 = STRING: "user1"
SNMPv2-SMI::enterprises.1302.3.8.10.1.8 = STRING: "User has logged into
VCS" SNMPv2-SMI::enterprises.1302.3.8.10.1.1 = STRING:
"Veritas_Cluster_Server" SNMPv2-SMI::enterprises.1302.3.8.10.1.6 =
STRING: "hostname1" SNMPv2-SMI::enterprises.1302.3.8.10.1.10 = STRING:
"BFDBcluster1" SNMPv2-SMI::enterprises.1302.3.8.10.1.9 = STRING:
"VCS"
SNMPv2-MIB::sysUpTime.0 4:2:50:00.00
4:2:50:00.00
SNMPv2-MIB::snmpTrapOID.0 SNMPv2-SMI::enterprises.1302.3.8.10.2.6.2
SNMPv2-SMI::enterprises.1302.3.8.10.2.6.2
SNMPv2-SMI::enterprises.1302.3.8.10.1.15 0
0
SNMPv2-SMI::enterprises.1302.3.8.10.1.14 "Tue Oct 8 16:49:34 2002."
"Tue Oct 8 16:49:34 2002."
SNMPv2-SMI::enterprises.1302.3.8.10.1.4 "hostname1"
"hostname1"
SNMPv2-SMI::enterprises.1302.3.8.10.1.2 "VCS"
"VCS"
SNMPv2-SMI::enterprises.1302.3.8.10.1.3 "user1"
"user1"
SNMPv2-SMI::enterprises.1302.3.8.10.1.8 "User has logged into VCS"
"User has logged into VCS"
SNMPv2-SMI::enterprises.1302.3.8.10.1.1 "Veritas_Cluster_Server"
"Veritas_Cluster_Server"
SNMPv2-SMI::enterprises.1302.3.8.10.1.6 "hostname1"
"hostname1"
SNMPv2-SMI::enterprises.1302.3.8.10.1.10 "BFDBcluster1"
"BFDBcluster1"
SNMPv2-SMI::enterprises.1302.3.8.10.1.9 "VCS"
"VCS"
=====================================================================================
This isn't the only case where I have had this problem. We also use an
IBM 3584 which is connected to our network and has the
ability to send snmpv2 events to a console. After I loaded its mib
information (which I did by hand through the xnmtrap gui), I
experienced the same result, though I haven't the output to show right
now.
Am I loading these traps incorrectly? I have noticed a few other posts
with similar problems, but no one really stating that there
was a resolution.
Regards,
Jerald Jackson
---------------------------------------------------------------------
To unsubscribe, e-mail: nv-l-unsubscribe@lists.tivoli.com
For additional commands, e-mail: nv-l-help@lists.tivoli.com
*NOTE*
This is not an Offical Tivoli Support forum. If you need immediate
assistance from Tivoli please call the IBM Tivoli Software Group
help line at 1-800-TIVOLI8(848-6548)
|