Nothing is broken. Trapd
has always worked this way.
If the vendor defines n.n.n.n
extensions to their (vendor) Enterprise id, then you must define each as a separate enterprise.
Look at your Cisco definitions.... There
is more there than just 1.3.6.1.4.1.9
You must define an enterprise ID for every
variation the vendor has used.
Example:
Enterprise 1.3.6.1.4.1.2552.200.300.3 Netegrity
widget
Enterprise 1.3.6.1.4.1.2552.200.300.4 Netegrity
mousetraps
Enterprise 1.3.6.1.4.1.2552.200.300.5 Netegrity
thingamajigs
Then under each of these specific
enterprises Ids you must define the Generic and Specific traps.
Example
Enterprise 1.3.6.1.4.1.2552.200.300.3 Netegrity
widget
You must define Enterprise Specific (6)
Specific: 1 ----- means the smpolicysrv is ok
Specific: 4 ----- means the smpolicysrv is melting down
Etc...
Don Davis
-----Original Message-----
From: James Shanks
[mailto:jshanks@us.ibm.com]
Sent: Wednesday, September 22,
2004 2:08 PM
To: nv-l@lists.us.ibm.com
Subject: RE: [nv-l]
Mib2trap
Well, JT, I don't know what to tell you exactly.
When
you sent the FMTCHG event you should have seen an entry in trapd.log
that it was received. I've forgotten the exact text but it is something
like "format file changed." If the reload was successful, then you
would not see an indication of that, but if there's anything wrong with the
updated file, then you'd see an error message trap, sent by trapd
himself, about how it could not be loaded because of such-and-such error
on line so-and-so. It's very specific.
But
assuming that it loaded OK, it comes down to this: trapd
doesn't think that the incoming traps are defined, and you think they are.
All
I can suggest is that you gather some data and call Support.
If
trapd is running with the -x option already, then
toggle the trapd.trace on from the command line
("trapd -T") and after you have traced a
couple examples of the failure, pass that data to Support : your trapd.conf file, trapd.log, and trapd.trace, and let them see what sense they can make of
it. Also include the addtrap script you created
from the MIB just for good measure, and the MIB too. Might
as well be thorough. If trapd is not
running with -x (and "ps -ef
| grep trapd"
will tell you) then you can set that in serversetup
with hex dump all packets option. This gives us a hex version of the trap
when we trace, so we can follow through the formatting of it.
If Level 2 cannot figure this out, and they think trapd
is somehow broken, you can be sure they'll notify me and I'll be looking too. If
the code is broken, well, then eventually it will be my job to fix it
HTH
James Shanks
Level 3 Support for Tivoli NetView for UNIX and Windows
Tivoli Software / IBM Software Group