Thanks James, looks like I'll have to change my script to chop off extra
subtrees, I suppose I should be able to gte a valid list from the
enterprise from enterprises section of trapd.conf, store see if there is a
partial match.
Actually, since the only product which causes this issue so far is the
Netview, I might just treat it as an exception. All my
cisco,empire,netware,netfinity,arcserve etc trapd all send with the exact
enterprise id defined in trapd.conf
The main reason why I was going to change the enterprise id in trapd.conf
is so my perl script will then match the correct enterprise and
generic/specific ids so it can send out a meaningful alert.
Thanks again.
Mark :-)
James_Shanks@
tivoli.com To: IBM NetView Discussion
<nv-l@tkg.com>
Sent by: cc:
owner-nv-l@tk Subject: Re: [NV-L] Traps coming
from 1.3.6.1.4.1.2.6.3.1
g.com
17/11/2000
08:11 PM
Please
respond to
IBM NetView
Discussion
Mark -
We are getting closer but I still not sure I know exactly which error has
you concerned here, nor just why you think that defining a new enterprise
id will fix anything.
Let me see if I can clarify a few things.
(1) All NetView traps sent by netmon on UNIX have an enterprise id of
1.3.6.1.4.1.2.6.3.1. This is normal and standard
(2) trapd.conf on UNIX defines the NetView enterprise as
1.3.6.1.4.1.2.6.3. This is normal and standard.
(3) All NetView events which come into trapd.log or nvevents should format
fine despite both (1) and (2).
This is normal and standard. There is no need to define a more specific
NetView enterprise and if you do, it will require that you duplicate all
the NetView specific traps as well. Not a good idea.
(4) The problem with garbage appended to a community name longer than the 5
characters in "public" is IY11761. It will be part of 5.1.4 and 6.0.2
Is there still more here that I can help with? Except for my item (4)
everything looks fine and normal to me. I think rather the problem is
that you made an assumption about how traps would be sent that isn't true,
when you wrote your perl script . That's not your fault, it is a natural
assumption, but it is just not the case. The way this works is that if a
specific trap is not defined under an enterprise id, then the next closest,
less specific one is used. So for an OID of 1.3.6.1.4.1.2.6.3.1. the next
closest one is 1.3.6.1.4.1.2.6.3, and things display as they should. The
code should work this way, else you could not have "enterprise default"
settings which apply to all traps from that enterprise. And many vendors
send more specific traps than just their nominal enterprise id. I think
you need to change your perl script so that anything beyond
1.3.6.1.4.1.2.6.3 is treated as if it were just 1.3.6.1.4.1.2.6.3, since
that is how trapd treats it and how the RFC's tell us to regard it.
If I have misunderstood this, then please try again and I'll have another
go.
James Shanks
Team Leader, Level 3 Support
Tivoli NetView for UNIX and NT
_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l
|