One man's opinion; go slowly.  

Start by turning off automatic discovery.  Add a line like "3.3.3.*" to
the end of the file /usr/OV/netmon.seed.  While you have the file open
read the contents of netmon.seed. That will stop automatic discovery and
give you a chance to control things as they develop.  How important this
is depends on the size of your network.  (In the early days, about 1995,
we used to have fun starting automatic discovery of a Class A network
before we went home and seeing how long it took to crash the server.  We
would start with a key corporate router in France and get most of Europe
on the map before the crash. We called such a map the "Death Star" with
apologies to the Star Wars movie.) 

For a small network - no more than a half dozen routers - ignore what
follows except for the community string piece and just let it rip.  For
a bigger network you need to develop it slowly.  

Add the community strings to /usr/OV/conf/communityNames.conf.  Then add
the primary addresses of your main routers to the
/usr/OV/conf/netmon.seed file, execute the "netmon -y" command and ping
the routers at their primary addresses.  

Then go to the read-write X-windows console and build locations for the
major divisions of your network in the default map.  I create a LOCATION
icon for each major router and it's associated networks then cut and
paste the router and network icons into the location submaps.  At this
point there may not be any further major divisions.  If you have routers
at separate geographic sites this is the time to create LOCATION icons
for each site and paste router and location icons into the site submaps.


Now go back and add the second layer of routers to /usr/OV/netmon.seed,
execute the "netmon -y" and ping again.  Build more locations and repeat
until you're satisfied you have all the nodes you need to manage.  My
location is looking for routers, switches and corporate level servers.
If we didn't use a seed file we would be seeing many thousands of
workstations show up in our maps.  

As to your other questions: 

        Smartsets are useful for grouping devices on some identifiable
characteristic or set of common characteristics.  Look at the samples
with the "nvUtil" command to see the ones that are there.  Defining them
is an exercise in programming.  

        It may take some work on your part to suppress those messages
depending on how they are being delivered.  Without action you may just
see Unreachable messages instead of Down messages.  Look at the sample
rulesets.  A ruleset can be developed to suppress unwanted traps or
change the default actions.  Rulesets can also be controlled by the
Smartset definitions.  Traps can also be customized to initiate actions
beyond the minimum.     

The class "IBM Tivoli NetView for UNIX 7.1 for Administrators" is
scheduled for Raleigh in November.  (It's offered worldwide.)  I'm
prejudiced but I recommend it.  You'll save a lot of time and trouble in
the long run if you take the week to attend it.  

Bill Evans
Former instructor for that class back in the days of NV Version 5.



-----Original Message-----
From: nv-l-bounces AT lists.ca.ibm DOT com
[mailto:nv-l-bounces AT lists.ca.ibm DOT com] On Behalf Of Sean Lawrence
Sent: Thursday, July 12, 2007 9:18 AM
To: Tivoli NetView Discussions
Subject: [NV-L] Setting up Netview for the first time.

Ok my turn for the newbie question.

 

Our Network admins have finally agreed to open up snmp for the cisco
devices on our network.

 

Up till now we have only been using Netview as a trap handler as we
could not see anything on the network.

 

Where should I begin?

 

I have successfully configured the community strings and can see Netview
discovering devices.

 

What are Smartsets useful for? I have begun creating smart sets to group
devices by type, dev/production etc. Can rulesets be tied to smartsets?
Can I set different alert severities based on smartest membership?

 

The whole reason the network is finally opened up to us is because the
Network guys wanted us correlate router failures and suppress node down
messages for objects behind the router.

 

It is my understanding the Netview will do this automatically and flag
the other nodes as unreachable. Can I also suppress traps coming from
other tools that are complaining about a DB Server being unreachable as
well?

 

Sean Lawrence 

Systems Automation Technical Specialist

905-790-5728



_______________________________________________
NV-L mailing list
NV-L AT lists.ca.ibm DOT com
Unsubscribe:NV-L-leave AT lists.ca.ibm DOT com
http://lists.ca.ibm.com/mailman/listinfo/nv-l (Browser access limited to 
internal IBM'ers only)