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
"Mark van Kerkwyk" <mark@vk.net> on 11/17/2000 05:39:25 AM
Please respond to IBM NetView Discussion <nv-l@tkg.com>
To: IBM NetView Discussion <nv-l@tkg.com>
cc: (bcc: James Shanks/Tivoli Systems)
Subject: Re: [NV-L] Traps coming from 1.3.6.1.4.1.2.6.3.1
Hi James, confused ? Me too.
I have a perl script which runs on each event whish reads trapd.conf,
matches the enterprise, generic and specific values and then formats the
alert message in the appropriate way based on the values passed through to
the shell
All my traps seem to come in as 1.3.6.1.4.1.2.6.3.1
NVATTR_8=0
NVATTR_4=974485516 1027
NVATTR_5=openview
NVATTR_6=3
NVATTR_7=N
NVATTR_1=2
NVATTR_2=210.9.8.10
NVATTR_3=Node Up.
NVE=1.3.6.1.4.1.2.6.3.1
NVG=6
NVA=210.9.8.10
NVC=publicc
NVT=2000/18/11 05:25:16
NVS=58916864
Netview normally matches these traps and they end up in the console as
correct entries (eg Node Down)
Here is the trapd.conf entry for 58916864
IBM_NVNUP_EV {1.3.6.1.4.1.2.6.3} 6 58916864 N 0 0 "Status Events"
$3
Maybe nvevents somehow matches the string with the trailing 1.
I also end up with garbage chars on the end of the trap community string
also, see the "c" on the end of public ?
Do you think I should just do a global replace and add the trailing 1 to
1.3.6.1.4.1.2.6.3 into trapd.conf ??
Thanks
Mark
Here is an extract of what the script does.
# Read in shell environment and make it available to perl environment
for (keys %ENV)
{
$exec="\$$_=\$ENV{$_};";
eval($exec);
}
# Category Config
# Each entry can have more than one contact number, each seperated
# by a blank space and complete string must be enclosed within double
quotes.
# For example...
# The following section extracts the Event message text and reformats the
it to work within this script.
if ( $NVG != "6" )
{
@VAR=split(/\./,$NVE);
$NVE=join('.',@VAR[0],@VAR[1],@VAR[2],@VAR[3],@VAR[4],@VAR[5],@VAR[6]);
}
$line="";
open(F,"/usr/OV/conf/C/trapd.conf");
while (<F>)
{
if (m/\{$NVE\} $NVG $NVS /o) {
$line=<F>;
break;
}
}
close(F);
if ($line eq "")
{
print "FAILURE:{$NVE $NVG $NVS} Not Found\n";
}
else
{
print "SUCCESS:{$NVE $NVG $NVS} Found\n";
}
# Substitute all the $A,$E,$G,$S etc to the format which they appear in the
environment
# eg. $E should map to $NVE, $1 should map $NVATTR_1
# Convert $T to $NVT
$line=~s/(\$T)/$NVT/g;
# Convert $S to $NVS
$line=~s/(\$S)/$NVS/g;
# Convert $E to $NVE
$line=~s/(\$E)/$NVE/g;
# Convert $G to $NVG
$line=~s/(\$G)/$NVG/g;
# Convert $C to $NVC
$line=~s/(\$C)/$NVC/g;
# Convert $A to $NVA
$line=~s/(\$A)/$NVA/g;
# Convert all $1,$2 etc to $NVATTR_1,$NVATTR_2 etc...
$line=~s/(\$\d)/\$NVATTR_$1/g;
$line=~s/(\_\$)/_/g;
$line=~s/\$(\w+)/${$1}/g;
# Store complete message in this var for emailing as length won't matter,
and carriage returns are normally better have for email.
$longeventmessage=$line;
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
04:48 PM
Please
respond to
IBM NetView
Discussion
Well, now I am very confused. The situation you described did exist on NT
and we took an APAR to fix it but we did so by copying the code that
already existed in the UNIX version, including Solaris. So there must be
something else amiss here than what you say. netmon on UNIX sends most
NetView traps with the trailing 1 on the end of 1.3.6.1.4.1.2.6.3.1 and yet
trapd.conf has always just said 1.3.6.1.4.1.2.6.3. But if this were a
problem on Solaris then almost all NetView traps would end up being "no
format found" or some such. And I have several Solaris boxes (all at
5.1.3 or 6.01. of course) so I can see that is not the case. I don't know
what to say now, Mark. I just did " event -e NDWN_EV -h james1" to
prove it. How did you arrive at the conclusion that this was not working
correctly? What symptoms are you seeing?
James Shanks
Team Leader, Level 3 Support
Tivoli NetView for UNIX and NT
"Mark van Kerkwyk" <mark@vk.net> on 11/18/2000 01:45:49 AM
Please respond to IBM NetView Discussion <nv-l@tkg.com>
To: IBM NetView Discussion <nv-l@tkg.com>
cc: (bcc: James Shanks/Tivoli Systems)
Subject: Re: [NV-L] Traps coming from 1.3.6.1.4.1.2.6.3.1
Sorry, I screwed up, this box is running 5.11 on Solaris 2.6
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
14:18
Please
respond to
IBM NetView
Discussion
What version and level of NetView are you using?
James Shanks
Team Leader, Level 3 Support
Tivoli NetView for UNIX and NT
"Mark van Kerkwyk" <mark@vk.net> on 11/17/2000 10:56:36 PM
Please respond to IBM NetView Discussion <nv-l@tkg.com>
To: IBM NetView Discussion <nv-l@tkg.com>
cc: (bcc: James Shanks/Tivoli Systems)
Subject: [NV-L] Traps coming from 1.3.6.1.4.1.2.6.3.1
Hi,
in my trapd.conf I have and entry for "netView6000
{1.3.6.1.4.1.2.6.3}" but traps are coming in with Enterprise
"1.3.6.1.4.1.2.6.3.1", so when I try and resolve the incoming specific trap
for 58916865 it fails.
Is the trailing 1 on the end of 1.3.6.1.4.1.2.6.3.1 an instance reference
or something else ?
The only way I can think of fixing it is to do a global change in
trapd.conf and change 1.3.6.1.4.1.2.6.3 to 1.3.6.1.4.1.2.6.3.1
IBM_NVNDWN_EV {1.3.6.1.4.1.2.6.3} 6 58916865 N 5 0 "Status Events"
$3
EVENT_CLASS OV_Node_Down
Any ideas ?
Mark :-)
_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l
_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l
_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l
_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l
_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l
|