Re: [nv-l] Newbie's List of Netview Questions (Please grab a cup of Coffee)

[Leslie Clark <lclark@us.ibm.com>]

Well, I've done a hundred or so of these, and so I will tell you what I think is the Best Practice, since you asked.

Customers who insist on using explicit seedfiles to control discovery, or use loadhosts to 'draw' the network are customers who don't have a good handle on what is in their network, and those are exactly the customers that Netview discovery can help the most. It may also be the only way to go if the addressing scheme is hopeless.

I always advise leaving discovery turned on, and control it via the seedfile. You want to restrict the discovery to the items you are responsible for, and that you want to see color changes for, and that you want to see events about.  Sometimes the thing that is causing the problem in the network is the thing you don't know is there.

Identify your network addressing rules, and code the seedfile to match. Any unwanted devices that show up are devices that are out of compliance with the corporate standard and should be dealt with. 

A good seedfile looks like this, in my opinion:

================================================================
# Rules part of the seedfile
# Some negative ranges to exclude some wild stuff
!172.*.*.*
!xxx.*.*.*
# Some negative ranges to exclude the DHCP address ranges
!10.*.1-50.50-100
!10.*.40-60.20-90
# Poll these devices using SNMP
$10.2.3.4
$10.2.3.5
# Exclude these types of devices by snmp sysObjectID
!@oid 0    # exclude non-snmp devices
!@oid 1.3.6.1.4.1.641.*    # exclude lexmark printers
!@oid 1.3.6.1.4.1.11.*      # exclude hp printers
!@oid 1.3.6.1.4.1.311.*   # exclude microsoft pcs with static addresses
# These are HSRP or intentional duplicate addresses
%10.*.*.1
# Explicit part of the seedfile
# Force the discovery of these core switches by the interfaces that resolve to these names
Switch1
Switch2
Switch3
# Allow the discovery of these servers excluded by the oid exclusions above
Server1
Server2
Server3
# End of the permanent base seedfile
==================================================

The initial discovery you did is something I always do, just to see what is there. Make sure it is all connected, meaning you are not missing snmp access to any connecting routers or switches. Then encode a seedfile and rediscover. Refine and repeat. You can add things to the seedfile to speed up their discovery, but you don't have to leave them in there. 

Work up a nice location.conf file to automatically subdivide the map, but only after you know it is mostly properly discovered. Use smartsets to evaluate the devices discovered. Make sure they all have the vendor field set, for instance. That means their oids are all in /usr/OV/conf/oid_to_type. Find other types of devices that you might want to exclude. Update the seedfile, netmon -y, delete the unwanted nodes.

Then address anything that is red all of the time. It may represent needed cleanup in the network, such as unwanted interfaces, or routing problems, or they may be devices that must be polled by SNMP vs ping. Use the provided mib appls under 'Monitor' to check the devices realtime vs their representation on the map. 

Once you have a good map that remains stable with discovery turned on, you have a better chance of finding out about unexpected changes going on in the network, and you can actually reduce the administrative burden associated with adding things. 

This is my most common implementation practice. It is not guaranteed to be applicable to all customer environments. 

Cordially,

Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
(248) 552-4968 Voicemail, Fax, Pager