Mark -
I am sorry that your response has not been more timely, but there is little
I can do about that.
As for your problem, there are too many strange aspects to it for me to
make sense of here, but I will tell you what I know. I cannot for the
life of me understand about the strange IP addresses you are seeing as the
trap source. That makes no sense to me, and I could not think of anything
to tell you to do about them on the information you have provided, not that
you should have known what else to say . I simply haven't seen anything
like it and I don't know where to begin to tell you to look, though I would
start by adding the -x option to trapd to dump all packets to hex so that
we can at least get a look at what is coming in. There are lots of ways
to do this -- edit the trapd entry in ovsuf, edit /usr/OV/lrf/trapd_dm.lrf
and do ovdelobj/ovaddobj, or use the Framework context menu to add the
option -- and then ovstop trapd and ovstart everything again. The next
thing I would do is try sending your own traps with snmptrap and see what
you get for the IP address there.
The community name thing is also puzzling. First, the community name in a
trap, no matter what source, will not normally cause an authentication
error. The trap recipient is trapd, not snmpd, and trapd does care what
community name you use. This can be easily proved by stopping netmon so
that no other traps are coming in and issuing one of your own with a bogus
community name using snmptrap. I assure I do this all the time in the lab
and it causes no problems such as you describe. But there still might be a
problem wit netmon issuing traps with community name "public" if that is
not the name in use on your box, though not being a netmon guy, I am not
sure if it is even designed to put your actual community name in the trap.
You see, netmon traps are sent directly to trapd by way of a UNIX domain
socket using TCP and they do not go over the network interface (162/udp) at
all. And since trapd doesn't check the community name in a trap for
authenticity, I don't know that it matters.
Finally then, what about your authentication errors if the traps are not
causing them (and I don't see how they could)? The only thing I can
suggest is that you turn on snmpd tracing by editing the snmpd.conf file,
setting the level to 3, and restarting snmpd. That may tell you something
about the source. But the only thing you can really do is to try to double
check the boxes that these traps are about, double check the SNMP Config
for netmon, and try things like snmpwalk to verify that the community name
you think is in effect really is. It is difficult and tedious at best.
So I avoided saying all this before because I think you will need personal
attention from Support to get to the bottom of all your problems.
James Shanks
Tivoli (NetView for UNIX) L3 Support
Mark van Kerkwyk <kerkwyk@COMTECH.COM.AU> on 02/12/99 03:38:12 PM
Please respond to Discussion of IBM NetView and POLYCENTER Manager on
NetView <NV-L@UCSBVM.ucsb.edu>
To: NV-L@UCSBVM.ucsb.edu
cc: (bcc: James Shanks)
Subject: Re: Wrong community name in Netview internal events/traps
Hi James, I have had this problem logged for over 5 weeks now with support
and was hoping someone else had run into the same problem.
Mark
James Shanks <James_Shanks@TIVOLI.COM> on 12/02/99 23:00:05
Please respond to Discussion of IBM NetView and POLYCENTER Manager on
NetView <NV-L@UCSBVM.ucsb.edu>
To: NV-L@UCSBVM.ucsb.edu
cc:
Subject: Re: Wrong community name in Netview internal
events/traps
I have two words for you: Call Support.
James Shanks
Tivoli (NetView for UNIX) L3 Support
Mark van Kerkwyk <kerkwyk@COMTECH.COM.AU> on 02/12/99 02:00:46 AM
Please respond to Discussion of IBM NetView and POLYCENTER Manager on
NetView <NV-L@UCSBVM.ucsb.edu>
To: NV-L@UCSBVM.ucsb.edu
cc: (bcc: James Shanks)
Subject: Wrong community name in Netview internal events/traps
Hi ,
I'm still trying to solve an old problem which I've had logged for a
while now. We don't use public for our read only or trap community name.
It appears that all Netview internally generated traps are not being sent
to localhost with the correct community name. Everything else works fine
except for the locally generated traps from within Netview.
I'm running Netview 5.1 on Solaris 2.6 and all community names appear to be
set correctly in both the OS and with Netview, other local traps appear to
be sent correctly.
I'm not sure whether the community names like public11,public16,publicc
mean anything, maybe they are just spurious grep errors and I'm still
trying to work out what "NVA=0.108.108.103" could refer to.
Any ideas ?? Below is an extract from the file I log to all of the time, I
log all environment variables which have NV in them.
Mark :-)
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
NVATTR_8=0
NVATTR_4=
NVATTR_5=
NVATTR_6=7
NVATTR_7=I
NVATTR_1=13
NVATTR_2=<none>
NVATTR_3=IP Map connected to trapd.
NVE=1.3.6.1.4.1.2.6.3.1
NVG=6
NVA=0.108.108.103
NVC=public11
NVT=1999/12/02 13:58:10
NVS=59179056
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
NVATTR_8=0
NVATTR_4=
NVATTR_5=
NVATTR_6=7
NVATTR_7=I
NVATTR_1=13
NVATTR_2=<none>
NVATTR_3=IP Map connected to trapd.
NVE=1.3.6.1.4.1.2.6.3.1
NVG=6
NVA=0.0.0.208
NVC=public9
NVT=1999/12/02 13:58:13
NVS=59179056
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
NVATTR_8=0
NVATTR_4=
NVATTR_5=
NVATTR_6=7
NVATTR_7=C
NVATTR_1=12
NVATTR_2=<none>
NVATTR_3=xnmcollect connected to trapd.
NVE=1.3.6.1.4.1.2.6.3.1
NVG=6
NVA=0.0.0.0
NVC=publicTr
NVT=1999/12/02 13:59:20
NVS=59179056
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
|