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 AT erac DOT 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