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
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.
tivoli.com To: IBM NetView Discussion <nv-l
AT tkg DOT com>
Sent by: cc:
[email protected] Subject: Re: [NV-L] Traps coming
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
18.104.22.168.22.214.171.124.3.1. This is normal and standard
(2) trapd.conf on UNIX defines the NetView enterprise as
126.96.36.199.188.8.131.52.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 184.108.40.206.220.127.116.11.3.1. the next
closest one is 18.104.22.168.22.214.171.124.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
126.96.36.199.188.8.131.52.3 is treated as if it were just 184.108.40.206.220.127.116.11.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
Team Leader, Level 3 Support
Tivoli NetView for UNIX and NT
NV-L List information and Archives: http://www.tkg.com/nv-l