We have just experienced this same problem on NetView 6.0.1 on an AIX
server. The communityNames.conf files is "empty", i.e. we have not added
any alternate community names to it. We do not use "public" on the devices
managed by NetView, and the Global Default entry in NetView's SNMP
Configuration contains the correct Community and Set Community strings.
Intermittently, there would be new entries added to the SNMP Configuration
for various devices with the Community field set to "public". We assumed
that it was the alternate community names feature in NetView V6 that was
responsible for the new entries, but could not determine why they were being
added. The problem is that none of these devices use "public" as a
community string.
We think that we've finally gotten this problem resolved by adjusting the
SNMP timeout values. We increased the Timeout from 2 to 5 seconds on the
Global Default entry, and SNMP polling is much more stable now. None of the
"public" entries have reappeared, either. The only explanation that I can
think of is that there was a timing issue with the SNMP queries and
responses. There was a timeout on the first query with the correct string,
so then another query was issued with "public". The response to the first
query is then received by NetView, and it mistakenly thinks that the correct
string is "public". This is just an educated guess, since we did not do any
kind of tracing to determine the exact cause of the failure.
SNMP timeouts are affected by the relative "speed" of the network, managed
devices and the NetView server. If you're having this mysterious problem of
bogus entries in the NetView SNMP Configuration, try increasing the SNMP
timeout. Just make that it's a reasonable value.
Joel A. Gerber - USAA Information Technology Co. - San Antonio, TX
* (210)913-4231 * mailto:Joel.Gerber@USAA.com " http://www.usaa.com
-----Original Message-----
From: Leslie Clark/Southfield/IBM [SMTP:lclark@us.ibm.com]
Sent: Wednesday, November 08, 2000 20:30
To: IBM NetView Discussion
Subject: RE: [NV-L] Netview changing snmp config by itself
Shailesh, the case you site is, I believe, working as designed. I have
seen it too. That is, it is assumed by netview that 'public' is in the
community names file. The header tells you not to put it in. I think it
is because it is assumed to be in there. That is useful in the case where
your global default is not public. The alternate names processing then
tries public, and adds entries to ovsnmp.conf if they work. That's what
I think.
Cordially,
Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
Detroit
"Patel, Shaileshbhai B" <shaileshbhai.patel@eds.com>@tkg.com on 11/08/2000
05:17:58 PM
Please respond to IBM NetView Discussion <nv-l@tkg.com>
Sent by: owner-nv-l@tkg.com
To: "'IBM NetView Discussion'" <nv-l@tkg.com>
cc:
Subject: RE: [NV-L] Netview changing snmp config by itself
Leslie,
Looks like this is a bug. Here is the scenario. I have a network
device (Cisco Router)
which has a "public" read community set on it (This is a lab
environment). I setup
different community string in ovsnmp.conf using xnmsnmpconf
application. Just for an example say it was set to "notusepublic".
There is no community string
defined in /usr/OV/conf/communityNames.conf. That file is blank. If
I use demandpoll or configuration polling on that device, it is
modifying community string from "notusepublic" to public. I have
tested this for at least 5 times. If the community
string is set to something else then "public" on that device,
demandpoll/configuration polling fails. That is the way it is
supposed to work. My global default is set to "public". If demandpoll
defaults to Global default that is fine but it should not modified
entry in ovsnmp.conf file.
Any comments?
Shailesh Patel
EDS
-----Original Message-----
From: Leslie Clark/Southfield/IBM [mailto:lclark@us.ibm.com]
Sent: Friday, November 03, 2000 8:44 AM
To: IBM NetView Discussion
Subject: Re: [NV-L] Netview changing snmp config by itself
Spooky, eh? Well, there only 2 possible explanations. Either someone has
added a specific entry unbeknownst to you, or someone has added an entry to
/usr/OV/conf/communityNames.conf, which Netview will try when nothing in
ovsnmp.conf works. If something in there works, it adds entries to
ovsnmp.conf.
The Sherlock Holmes approach to problem determination works for me:
When you eliminate the impossible, whatever remains, however improbable,
must be the truth.
Cordially,
Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
Detroit
"Peter Anderson" <pETERanderson@westpac.com.au>@tkg.com on 11/02/2000
08:20:01 PM
Please respond to IBM NetView Discussion <nv-l@tkg.com>
Sent by: owner-nv-l@tkg.com
To: "Netview List (E-mail)" <nv-l@tkg.com>
cc:
Subject: [NV-L] Netview changing snmp config by itself
Hi,
We have Netview Unix 6.0.1 on Solaris 2.7.
I've had a problem occur a couple of times where Netview in its infinite
wisdom creates new entries in the ovsnmp.conf_db database for individual
nodes, using Netview defaults but with community names not found anywhere
except in the managed device itself.
For example, we use public for all our read-only monitoring but use say
"xyz" as our read-write community name.
I setup the ovsnmp.conf_db with only static entries for our two Netview
boxes, and either the default or a smartset entry for every other managed
node.
Our default is:
*.*.*.*:public:*:100:2:7200:::604800:604800:86400:10:1:0:1
Our smartset entries are similar but with slightly different timeout
settings, depending on the set.
branch_swch:public:*:200:2:7200:::604800:2419200:86400:1:0:0:0
I've found two occasions where entries are created like:
hostname1:xyz::::::::::::
It's only happened twice, and it has happened when nobody has been using
Netview, just the daemons in the background doing polling. Entries haven't
been created for EVERY managed node - just some.
Unfortunately, the above settings cause high CPU usage on our smaller Cisco
routers, which I think is due to netmon wanting to get the entire routing
table and with a small timeout, retries occur.
I Netview designed like this and if so why?
Regards,
Peter Anderson
Senior Communications Analyst
Westpac Banking Corporation
Ph: 0011 61 2 99025938
<Remove ETER from my address to reply>
Any views or opinions presented are solely those of the author and do not
necessarily represent those of Westpac Banking Corporation.
_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l
_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l
_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l
|