Possible, but our NetView is not
NATed. I had the same problem today on the Routers of the enterprise and
they don't get anywhere near NAT. For them I turned off the SNMP
management and things started working. I'm getting more suspicious
about local subnet congestion and SNMP request timeouts. Some of my
Demand Polls took a terribly long time to respond today.
Bill Evans
Tivoli NetView
Support for DOE
301-903-0057
-----Original Message-----
From: owner-nv-l@lists.us.ibm.com
[mailto:owner-nv-l@lists.us.ibm.com] On
Behalf Of Barr, Scott
Sent: Wednesday, June 23, 2004
1:27 PM
To: nv-l@lists.us.ibm.com
Subject: RE: [nv-l] SNMP
monitoring anomaly
Bill, I remember
discussing behavior like this with support - I think we ended up thinking it
was a problem with NATing the NetView server. Are you NAT'd? If so, (and I
can't remember the details) some of the headers don't bear the translated
address, or they do, whichever causes the problem. Sorry I'm fuzzy but CNAT was
recommended for this. I use SNMP only for status polls, so I don't seem to have
this issue with either of the devices you mention.
From: owner-nv-l@lists.us.ibm.com [mailto:owner-nv-l@lists.us.ibm.com]
On Behalf Of Evans, Bill
Sent: Wednesday, June 23, 2004
12:08 PM
To: 'nv-l@lists.us.ibm.com'
Subject: RE: [nv-l] SNMP
monitoring anomaly
NV 7.1.3.0 on Solaris
2.8. Yes, I'm a bit behind.
Our system has a number of firewalls
which will only respond to a ping on the NetView facing interface. I do
have ACLs set which will allow the NetView machine to manage the firewalls
using SNMP. The boxes in question are
mostly Cisco PIX and Cisco VPN 3000 plus a couple Nokia boxes supplied by a
services vendor. Regardless they all behave
the same.
The netmon.seed file
is
set for monitoring on all our core routers and the firewalls using SNMP.
The
routers will allow ICMP to query all interfaces but firewalls will allow ICMP
only to inward facing interfaces.
The problem which has
occurred a couple times is that NetView seems to forget it's supposed to use
SNMP on the firewalls. The symptoms:
·
I
can browse the boxes using SNMP
·
Demand
poll displays the Admin/Op status of the interfaces
·
NetView
will only show the inward facing interfaces for firewalls as normal and all
outward facing interfaces as down.
·
Quick
Test will not find the true state of the outward facing interfaces on the
firewalls.
·
The
routers show no changes in behavior.
·
Functional
operation of the firewalls continued without interruption.
In the heat of the incident
last evening I tried to restart NetView (shutdown the X-console and issue
OVSTOP then OVSTART and netview -dconsole) and see if it helped. It did
not. I acknowledged the outward facing interfaces
and planned to investigate further this morning.
The event log shows that
normal SNMP monitoring of the firewalls resumed about five minutes after I went
home. This was about twenty minutes after restarting NetView and ten
minutes after acknowledging the interfaces.
Can anyone propose an
explanation of what happened? Is there a patch addressing anything like
this? Anyone else experienced it? Could
this similar to the November 2000 problem in
the archives where SNMP
timeouts
may have caused different community names to be tried?
As the King said to Anna,
"Is a puzzlement!"
Bill Evans
Tivoli NetView Support for
DOE