I find it a bit difficult to understand exactly what you are saying.
Do you mean that the sender of the trap ( $A ) is mis-identified? That is
usually a DNS reverse-lookup problem. Trapd does a gethostbyaddr for this and
only uses the ip address if nothing is found.
If you mean that the contents of the traps itself, some variable or other, is
incorrect, then you will have to contact the vendor Xylan for a fix.
If you require more help in debugging your problem, then you might re-configure
the trap in trapd.conf (using xnmtrap) to say "$*" so that all variables are
displayed in the event window and in trapd.log. If you want to see the actual
contents of the trap as NetView receives it, then you can configure the trapd
daemon to enable hex dump of all packets (trapd will then run with the -x
option) and you can toggle tracing on and off from the command line with the
trapd -T command. When tracing is on with the -x option, the sender and the
hex dump of the exact trap will be logged in trapd.trace. A copy of that
should be enough to convince Xylan that they have a problem if a variable is
bad.
James Shanks
Tivoli (NetView for UNIX) L3 Support
Goran Saradzic <gorans@US.IBM.COM> on 11/03/99 11:03:42 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/Tivoli Systems)
Subject: NetView trapd.log and events display report wrong source IP
address
Good day everyone,
has anyone encountered this problem? The traps coming in from Xylan
switches are
reporting a non-existant source IP address which prevent us from
identifying which
switch has a problem.
If we do the iptrace on the NetView server it does show a correct source
management
address from the switch.
Anyone has a fix for this???
Thank you for your time.
Goran
|