Stephen -
I don't have the Altiga MIB's so I cannot do it for you. But I posted a
general procedure for determining the enterprise id yesterday. You work
backwards from the trap definition to the "enterprises" clause which
identifies Altiga as 3076. It is clear that there must be more to these
enterprise ids because as you have noted, they are both specific 3. Notice
that with NetView the basic enterprise id is ".1.3.6.1.4.1.2.6" (the "2"
means "IBM" and the "6" means NetView) but that most of the traps come in
with ".1.3.6.1.4.1.2.6.3", and those from trapgend are
".1.3.6.1.4.1.2.6.4"? The same kid of thing is likely to be the case here.
Pull up my append from yesterday about how to work backward from the trap
to the enterprise id, or else concatenate the predecessor MIBs to the one
which defines the traps, and run mib2trap again.
Hope this helps
James Shanks
Team Leader, Level 3 Support
Tivoli NetView for UNIX and NT
Stephen Elliott <selliott@epicrealm.com> on 10/27/2000 03:59:18 PM
Please respond to IBM NetView Discussion <nv-l@tkg.com>
To: "'IBM NetView Discussion'" <nv-l@tkg.com>
cc: (bcc: James Shanks/Tivoli Systems)
Subject: RE: [NV-L] Re: Addtrap problem.
Ray,
Thanks for the info below. It will come in handy when I get the trap def's
compiled. My immediate problem, tho, is to determine what the OID for each
trap should actually be. There are trap def's embedded in several of the
Altiga mib files, but none of them have their respective enterprise ID's
and
all are spec'd as general type with specific numbers, some of which overlap
with other def's. Obviously, each trap must have it's own unique OID, but
without them in the mib file, how does one reverse engineer the mib file to
determine that unique OID? Is it even possible to do this or do I simply
need to contact the vendor?
Here are 2 examples of the overlap I'm talking about. The base enterprise
OID should be .1.3.6.1.4.1.3076 based on the SNMP database (the 'should'
here is an assumption on my part), but each trap below is spec'd as generic
6, specific 3. I added the -i OID as it's the only one I know for Altiga.
/usr/OV/bin/addtrap -l vrrpTrapNewMaster -g 6 -s 3 \
-n altiga_traps \
-i 1.3.6.1.4.1.3076 \
-o A -c "LOGONLY" -t 0 \
-S 1 \
-D "The newMaster trap indicates that the sending agent
has transitioned from 'Backup' state to 'Master' state." \
-e vrrpTrapNewMaster \
-F '$E $G $S $# args: $*'
/usr/OV/bin/addtrap -l ospfVirtNbrStateChange -g 6 -s 3 \
-n altiga_traps \
-i 1.3.6.1.4.1.3076 \
-o A -c "LOGONLY" -t 0 \
-S 1 \
-D "An ospfIfStateChange trap signifies that there
has been a change in the state of an OSPF vir-
tual neighbor. This trap should be generated
when the neighbor state regresses (e.g., goes
from Attempt or Full to 1-Way or Down) or
progresses to a terminal state (e.g., Full)." \
-e ospfVirtNbrStateChange \
-F '$E $G $S $# args: $*'
Regards,
Steve Elliott
Sr. Network Mgmt. Engineer
epicRealm, Inc.
214-570-4560
-----Original Message-----
From: Ray Westphal [mailto:rwestphal@erac.com]
Sent: Thursday, October 26, 2000 6:41 AM
To: NV List (E-mail)
Subject: [NV-L] Re: Addtrap problem.
Steve,
I'm not proud of my solution to get the 8272 Mibs to load. It was reverse
engineering. I have three NetView servers. One of the three that has no
8272
devices on the net it monitors had all the MIBs and trap definitions. It
was
NV for Unix 6.0. The "broken" server was a newly rebuilt NV for Unix 6.0.1.
I checked the xnmtrap GUI for the Enterprise Name and Enterprise ID on the
working server for the OID (e-ID).
To get the MIBs loaded I copied the snmpmib, snmpmib.bin, snmpv2mib and
snmpv2mib.bin files to the "broken" server from the working server. Then I
added all the now missing Cisco stuff added by 6.0.1. I merged the
trapd.conf files between the boxes.
Of course - I made backups and more backups before experimenting.
> Ray,
> I am experiencing similar problems with Altiga traps as you did with the
> 8272 system noted in your email below. The addtrap script generated by
> mib2trap also lacks the -i option specifying the enterprise ID. Looking
at
> the MIB file, tho, I am at a loss how to proceed tracking it back to it's
> root. Could you please pass on how you tracked down the e-ID for the
8272?
> Thank You & Regards,
> Steve Elliott
> Sr. Network Mgmt. Engineer
> epicRealm, Inc.
> 214-570-4560
Ray Westphal
Enterprise Rent-A-Car
_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l
_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l
|