nv-l
[Top] [All Lists]

RE: failing SNMP status polls

To: nv-l@lists.tivoli.com
Subject: RE: failing SNMP status polls
From: "Barr, Scott" <Scott_Barr@csgsystems.com>
Date: Thu, 18 Oct 2001 09:01:36 -0500
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


<Prev in Thread] Current Thread [Next in Thread>

Archive operated by Skills 1st Ltd

See also: The NetView Web