Discovery Methods

["Barr, Scott" <Scott_Barr@csgsystems.com>]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

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:  <mailto:Scott_Barr@csgsystems.com> Scott_Barr@csgsystems.com

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