Re: Traps coming from

2000-11-17 07:43:21
Subject: Re: Traps coming from
From: "Mark van Kerkwyk" <mark AT vk DOT net>
To: nv-l AT lists.tivoli DOT com
Date: Fri, 17 Nov 2000 12:43:21 +0000
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 :-)

                    [email protected]                                               
                    tivoli.com           To:     IBM NetView Discussion <nv-l 
AT tkg DOT com>                             
                    Sent by:             cc:                                    
                    [email protected]        Subject:     Re: [NV-L] Traps coming 
                    08:11 PM                                                    
                    respond to                                                  
                    IBM NetView                                                 

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  This is normal and standard
(2) trapd.conf on UNIX defines the NetView enterprise as  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  the next
closest one is, 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 is treated as if it were just, 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

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