Sorry, WRONG PMR - here is the right one:
The netmon.trace.relevant is a grep'd file from the netmon with all
the interfaces from the device in question. The device is
csg-ospc2.csgsystems.com. I have found that the STATUS snmp requests
are going to an interface on the router that is isolated(no traffic
from the netview side is routed to that subnet or interface).
For router csg-ospc2.csgsystems.com, the primary snmp address is
10.255.255.35 as seen in the ovtopodump. We see that it starts using
this address to get the snmp information. Further down in the
processing, we see where we start using another address of an isolated
interface on the same router. several timeouts, and eventually a down
event. I don't believe this is correct.
An efix for apar IY83520 was created for NetView V6.0.2 for Solaris
-----Original Message-----
From: Barr, Scott [mailto:Scott_Barr@csgsystems.com]
Sent: Thursday, October 18, 2001 8:15 AM
To: 'IBM NetView Discussion'
Subject: RE: [NV-L] failing SNMP status polls
This is a clip from my PMR on authentication failures - you may want to
review it.
4. pmr82387 ->aparIY22983:
This was the Authentification traps you were getting, caused by the use
of an incorrect community name for the first x number of request in a
series before the correct one was sent. I know you are getting hit with
non-netvew traps on your nt machines now, so you may not have any
information on the results of this fix. When you do let me know.
(this did fix the problem)
-----Original Message-----
From: Leslie Clark [mailto:lclark@us.ibm.com]
Sent: Wednesday, October 17, 2001 10:56 PM
To: IBM NetView Discussion
Subject: Re: [NV-L] failing SNMP status polls
Hmm... I can understand the problem clearing when you restart netmon. That
would probably be the equivalent of doing an xnmsnmpconf -clearCache.
So might that have something to do with redirects? If the Netview is on
AIX,
you might check the value of 'no -a | grep ipignoreredirects'. If it is 0,
try
setting it to 1. When the problem occurs, does the ip address listed in
'xnmsnmpconf -resolve <selection name>' change from the good address
to the bad address? I don't know what any of this means, it is just my
voodoo approach to problem determination.....
Cordially,
Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
Detroit
Joseph R
Smith/Rochester To: nv-l@tkg.com
/IBM@IBMUS cc: scott_barr@csgsystems.com
Sent by: Subject: [NV-L] failing SNMP
status polls
owner-nv-l@tkg.
com
10/16/01 10:32
AM
Please respond
to IBM NetView
Discussion
"Barr, Scot" wrote:
> Our problems with NETMON included failing SNMP status polls (they were
being
> sent to the wrong interface), AUTHENTICATION FAILURES (NETMON sending out
> wrong community strings) and CORES (due to discovery of "goofy" devices.
> But, I can safely say, WE ARE FIXED!
I would like to know how you resolved the failing SNMP status poll issue. I
am monitoring a hosting environment in which most servers have more than
one address, but the NetView server only has routes and (filter) permission
to specific interfaces. I am using SNMP status polling and I am not using
DNS for name resolution. Instead, I place a single hostname entry for the
accessible address in /etc/hosts. NetView discovers and polls most hosts
correctly. Occasionally, and only for certain servers, NetView starts using
one of the unreachable addresses for SNMP status polling. If I recycle
netmon, NetView starts using the correct address again. I have been unable
to determine the circumstances under which the change takes place.
Joseph R. Smith - CCDA, CCNA, MCP, MCSE
Tivoli Certified Enterprise Consultant - V3.6
I/T Architect - Systems Integration - Consulting
IBM Global Services - SDC Northeast
1630 Long Pond Road, Rochester, NY 14626
Phone 716 723 4957 Tie Line 451 4957
_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l
_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l
|