PMR 83520 - SNMP Status Polls fail
Here is the verbage reposted for anyone looking at a similar problem
*** T1S2R3V4
*** Electronic creation by customer via Tivoli Customer Support Web Site
*** Please contact customer by Electronic
***
*** Userid: bars02
*** Email Address: scott_barr@csgsystems.com
*** Fax Number: 402-431-7413
*** 24 Hour Phone Number:
***
Problem Details
.
Abstract:
TivWeb: SNMP Status Polls fail
.
System Type: Sun
System Model: Ultra 10
Other related devices:
.
Operating System: Solaris 2.3+
Product Group: NetView for UNIX
Fileset or Version: v6.02
.
Environment:
.
Problem Description:
It appears that we are having a problem with status polls using SNMP to
certain devices in our network. To trouble shoot this, I started a snoop
on the NetView server and waited for the failure to occur. At that point
I stopped the snoop and after reviewing the file, I do not see the
status polls being sent to the router.
I have provided Paul Stroud with documentation on the ftp server:
/support/incoming/pstroud.tar.Z
/support/incoming/pstroud2.tar.Z
These files contain ovtopodump, ovobjprint, xnmsnmpconf, netmon.trace
and the snoop files.
Action Taken: Sending to incoming product queue.
AM0906TIV
Action Taken:
Got data from ftp site and spoke with Customer Rep. I have found that in
the netmon.trace we are sending the SNMP request to a different
interface on the device than is listed in the SNMP ADDRESS in topodump.
The particular interface we are sending the SNMP request to is an HSRP
interface on an isolated subnet.
.
Action Plan:
Research further.
Action Taken:
Synopsis:
CC has three routers that occasionally show an incorrect down status on
the router. Tracing information for one of these routers is on
dfs/org/ts/netview/sep01/pmr83520bbre. 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). Passing to the backend for further analysis
.
Action Plan:
Passing to the backend
-----Original Message-----
From: William.Stringfellow@bankofamerica.com
[mailto:William.Stringfellow@bankofamerica.com]
Sent: Monday, September 10, 2001 10:18 AM
To: IBM NetView Discussion
Subject: [NV-L] RE: Demand poll times out, but SNMP walk works.
Scott,
Please tell us what the title line of your PMR is so that we can keep
abreast of what support finds to be the problem.
Thanks,
Bill
Date: Fri, 7 Sep 2001 07:57:49 -0500
From: "Barr, Scott" <Scott_Barr@csgsystems.com>
Subject: RE: Demand poll times out, but SNMP walk works.
We have a problem open with support for SNMP status polls that fail because
*some* of the SNMP requests are flowing to the wrong interface. For
instance, we have 3 routers in our network that get marked down and the next
status poll marks them back up.
After exhaustive troubleshooting, we found that the packets were being
directed to an interface that was not routable from the NetView server. We
use a loop back interface in each router and the SNMP requests were flowing
to an address in a subnet that NetView could not reach. On the surface it
looked like NetView was not sending the packets at all but we finally found
the packets were going out just to the wrong address.
I would set up a sniffer/snoop and try and catch the SNMP activity. You may
be having this problem too.
|