This is not exactly a question, just kind of a rant about a couple of
features of NetView that work perfectly on paper but the implementation will
bite you.
In our environment, we use smartsets - a lot of smartsets. We have router
smartsets, server smartsets, switch smartsets etc. Now, if you look at
XNMSNMPCONF after you have done a full discovery you find a mixture of
entries that fall into a few categories:
1. The NetView server itself
2. Seed file nodes which support SNMP
3. nodes found because they are in wildcard seed ranges
4. nodes found because discovery is on and is unrestricted
Now, here is what my puny brain attempted to do. I wanted an easy way to
change community strings on a regular basis per the request of our router
and security staff. I wanted to use the smartset facility available in
xnmsnmpconf and in data collection. I purged topology database, then cleared
snmp configuration data (xnmsnmpconf) and cleared data collection entries.
Then I created an entry in SNMP config and in data collection to use a
smartset called Routers to set the SNMP values like retries, timeouts and
community strings and to set the fields I want collected and stored. Now I
have an snmp configuration file with one entry in it and I also have data
collection with one easy to manage simple entry. Last thing I did was change
the default entry for the community string in SNMP conf. Piece of cake.
Then I started discovery. The first problem I encounted was NetView was
unable to speak to the local SNMP agent on my Sun box (DOH forgot to update
/etc/snmp/conf/snmpd.conf to include new default community string). Fixed
that, started over.
Discovery now began adding stuff. Routers and servers were discovered, stuff
added to map, a short time later smart sets were populated. After an hour or
so the vast majority of the network was discovered, I shut off new node
discovery.
Now, I went back and looked in xnmsnmpconf and in data collection and to my
surprise, all the discovered devices had individual entries (which appear to
override my smartset entry) and further more, the polling defaults, retries
etc. were taken from the default, not from the smartset definition. In
addition, some of the entries had public coded in them (public is listed as
an alternate name in communityNames.conf but it is NOT the default - this is
specified because some people can't ever seem to figure out that changing
the snmp community string of any host is the first most important security
hole you can fix). I began to receive large numbers of authentication
failures because I was bombing the routers with public community string. I
had to delete each and every entry (except for the smartset). This wouldn't
be so brutal except for that lovely X-windows GUI feature that prevents me
from selecting MORE than one entry. 800 mouseclicks later, the table was set
up with just the smartset entry in xnmsnmpconf.
Now, the data collection issue more or less took care of itself once the
SNMP config was squared away. I paid no further attention to my now
normally-functioning system. Until I noticed that SNMP collect daemon was
running at about 75-90% of my CPU on a periodic basis. After discussion with
support I came to the conclusion that the reason it was running so high was
due to the SNMPcollect daemon having to do a database query prior to each
collection function. To resolve this, (you guessed it) I had to put
individual entries back in the xnmsnmpconf for each managed devices and set
the retries, timeouts and polling intervals individually (again).
Don't get me wrong, the smartset facility in data collection and in
xnmsnmpconf are great. Just wish I could use them. I don't know how this
feature got deployed when clearly it will not get used in the vast majority
of implementations or at least there should be some warning about its
shortcomings.
-----Original Message-----
From: Thomas Kunz [mailto:t-kunz@admin.ndis.umn.edu]
Sent: Tuesday, July 31, 2001 9:22 AM
To: scott_barr@csgsystems.com; nv-l@tkg.com
Subject: RE: [NV-L] community name changes
We are at 6.01 and AIX 4.3.3 and have also seen this problem. Could someone
please
reply with all the specific files that you are referring to? (i.e. community
names files ...)
Do I update these files through Netview or through AIX?
Thanks and have a great day! :-)
Tom Kunz
OIT/PTS Network & AIX Systems Support
University of Minnesota
1300 S. 2nd St.
Mpls., MN. 55454-1083
Suite 660
Phone: 612-624-8086
Fax: 612-626-1332
Email: t-kunz@cafe.tc.umn.edu
>>> scott_barr@csgsystems.com 07/31/01 07:45AM >>>
I have seen this behavior and I am running 6.02. I changed global default
and left the community names file empty. Later, after doing initital
discovery I put my company-defined community string in and added nodes to
discovery. From time to time, I have to go in and whack the public entry. No
idea why this happens but the trigger is when I see routers sending in SNMP
authentication failure traps. I know there is something screwy here but I
haven't been able to make it happen in a controlled fashion.
-----Original Message-----
From: owner-nv-l@tkg.com [mailto:owner-nv-l@tkg.com]On Behalf Of Leslie
Clark
Sent: Monday, July 30, 2001 8:18 PM
To: IBM NetView Discussion
Subject: Re: [NV-L] community name changes
Don, I have seen confusing behavior in this area a lot. First, do you know
that at 6.01, public is used as if it were in the alternates file whether
you
want it or not, and at 6.02 it is not used unless specified? I hope you
are at 6.01,
because the explanation would be easier. The next odd thing I have been
seeing is the insertion of bogus communities. But I believe that in almost
every
case those turned out to be for nodes that had name resolution problems.
Cleaning
up the name resolution in both directions and a couple of demandpolls ( or
rediscovering the node) cleared it up. I know, I know, you couldn't
possibly have
any name resolution problems....;) My routine now includes:
fix any name problems for the node
delete any related xnmsnmpconf entries (name or address)
demandpoll (it will always work, because it tries everything)
check snmp using one of the MIB appls, which only checks xnmsnmpconf
If it works for Monitor..MIB Values..System Info, then it should work for
snmpCollect, I think. The snmpCol.trace will tell you if it also has name
issues.
Cordially,
Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
Detroit
"Davis, Donald" <donald.davis@firstcitizens.com>@tkg.com on 07/30/2001
05:39:38 PM
Please respond to IBM NetView Discussion <nv-l@tkg.com>
Sent by: owner-nv-l@tkg.com
To: "'NV-L@tkg.com'" <NV-L@tkg.com>
cc:
Subject: [NV-L] community name changes
For the sake of this discussion, let's say that my Global Default community
name is "raleigh".
I have a default communityNames.conf file with no entrys (all comments).
I am NOT using the "-h" netmon flag. (alternate community strings during
all
polls)
Nodes using "raleigh" mysteriously are being added in xnmsnmpconf with a
unique community name of "public".
This really messes up SNMP data collection statistics :(
Has anyone else seen this?
What is happening here?
How do I turn this "feature" OFF ?
Don Davis
Systems Engineer Consultant
Enterprise Management
First Citizens Bank
100 East Tryon Road
Raleigh, NC. 27603-3526
919-716-8448
----------------------------------------------------------------------------
--
This electronic mail and any files transmitted with it are confidential and
are intended solely for the use of individual or entity to whom they are
addressed. If you are not the intended recipient or the person responsible
for delivering the electronic mail to the intended recipient, be advised
that you have received this electronic mail in error and that any use,
dissemination, forwarding, printing, or copying of this electronic mail is
strictly prohibited. If you have received this electronic mail in error,
please immediately notify the sender by return mail.
============================================================================
==
_________________________________________________________________________
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
**************************************************************************
This e-mail and its attachments have been scanned for viruses.
NDIS/ADCS University of Minnesota
|