I favor a broad discovery myself, so you know what's out there.
The statement that not using dynamic dns would circumvent the problem
is not exactly true. Netview's DHCP handling is supposed to swap the
intefaces if the new one resolves and the old one no longer does. It is
not working for you, presumably because the nodes are unmanaged.
So you want all PCs discovered, but you don't want them to make the map
yellow? And you cannot unmanage them because Netview's dhcp handling
won't work for unmanaged nodes.
How about just unmanaging the interfaces?
I would try making a smartset where
IP Address matches your DHCP ranges using regular expressions
AND
isInterface is True
Then you could just go into that Smartset, sort them by status, grab the
managed ones, and unmanage them. The nodes will all be blue, but
they will be managed, so I believe that the configuation checks should
continue to work. Netview should remove the expired interfaces on its
own as new ones show up, and those will appear in the Smartset.
Unmanage them daily.
I question the prolonged default polling frequency. Better to make a
Smartset of PCs (non-snmp, or Microsoft oid, eg, or just isComputer) and
set the polling for that smartset to the longer period. That way you don't
have to add entries for all of the good guys. And if the interfaces
are unmanaged, you don't need the shortened Node Down Delete
interval. The shortened configuration polling is good, and you can
either do it across the board, or do it just for the PCs.
My favorite approach is to just exclude the DHCP address ranges
from discovery, however. This works well if you have a very tidy
addressing scheme without a lot if messy subnet masking. Any PCs
that get plugged into the network in the ranges reserved for your
network devices will show up so you can hunt them down and
punish them.
I hope this helps. I'm sure others have other ways of going about
this.
Cordially,
Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
Detroit
"Barr, Scott"
<Scott_Barr@csgsy To: "IBM NetView Discussion
(E-mail)"
stems.com> <nv-l@tkg.com>
Sent by: cc:
owner-nv-l@tkg.co Subject: [NV-L] Discovery
Methods
m
10/23/01 04:50 PM
Please respond to
IBM NetView
Discussion
Okay, I have been playing around with discovery a bit and want to discuss
some options. The pre-requisite for this topic is the discovery of ALL
devices on the network. All meaning, um, ALL. In addition to finding all
devices, discovery is to be left running all the time.
Obviously some folks will be asking WHY would I want to discover all my
network resources? Well, to be honest, I have a small enough network that
horsepower isn't really an issue and limited discovery means that you are
giving up some degree of visibility into your network. So, I am evaluating
the feasibility of doing unlimited discovery in my network. So, assuming
you can get past that WHY question, here is the issue.
I ran discovery last Thursday for the first time on a clean database. When
discovery was complete, I had about 8000 objects in the database. No sweat.
I started combing through the network, subnet by subnet, unmanaging devices
I didn't care about. Most of these devices were workstations or development
boxes. So 75-80% of all devices were unmanaged. I left discovery running.
Monday, I came back in, drilled down through all subnets, finding
workstations that had been added to discovery since thursday. I unmanaged
all those, location and segment icons all back to green.
Today, I found that new workstation objects had been added - but with an
undesirable result. The problem is that we a) run DHCP on our workstations
(not a problem for netview per se.) and b) our DNS is automagically kept in
sync with DHCP. Each time a workstation changes IPs, DNS is automatically
changed to reflect that. So, what is happening is, a workstation lease
expires and he grabs a new DHCP address. NetView discovers a new interface,
uses reverse lookup to determine the name of the workstation, then ADDS an
interface to the existing object in NetView object database. The icon for
the workstation is changed on the premise that it now has multiple
interfaces AND does not support SNMP, so Netview thinks he's probably a
router. No problems here, working as designed.
If I *did not* use DNS in this dynamic fashion, this wouldn't be a problem
because the new interface would not resolve in DNS and therefore be a new
box rather than an existing object.
So, after talking with support about how to accomplish this, I am doing
rediscovery after making the following changes:
1. changed the default status poll to 30 minutes rather than 5 (due to the
fact that to keep topology straight I *MUST* manage the device, unmanaged
devices can't change configurations)
2. changed the node down interval to 24 hours instead of 7 days (to
eliminate down workstations which will change addresses when they are left
down long enough)
3. changed the default config poll to 6 hours instead of 24 hours. This
forces Netview to consider workstation changes more quickly.
I'd l ike feedback from others on this topic. The goal is to eliminate the
need for a lot of administration of seed files AND to be able to
confidently discover all network devices and to leave discovery running all
the time. Since our organization is relatively loose, folks are allowed
more leeway on plugging in devices (re: causing trouble) and therefore our
need to discover every device is probably greater than the average
enterprise. (nothing like finding a firewall on your network you didn't
know about <grin>)
Scott Barr
Network Systems Engineer
CSG Systems
Phone: 402-431-7939
Fax: 402-431-7413
Email: Scott_Barr@csgsystems.com
|