|
The
Tivoli NetView Global Users group is planning on a technical exchange for March.
Based on this thread, a good topic may be discovery and location.conf. Anyone
have any comments on how useful this would be? For more information about the
Netview users group go here:
You
know, now that I have read that overlapping range example again (someone
else pointed this out too) I just finally realized that it does apply directly
to my case. Not to further confuse myself, but I read that example as
being defined as SalesOffices starting lower and ending lower then Tivoli,
while Tivoli started lower then SalesOffices ending, but ending higher then
SalesOffices ending - which would truly be an overlapping range. You are
correct, exactly what I'm trying to do is explicitly stated as being
unpredictable. I don't know how many times I read this example and
looked at it the same way. I still think it odd that the example
indicates the most specific range will be used, even though one cannot make
use of it :)
Unfortunately for me I have a number of entries in location.conf that
look very similar to Example D (but I was VERY careful not to overlap the
ranges as I viewed the example), I guess I have some work ahead of me to
explicitly state what ranges belong where....
Thanks for the comments!
Jason
You are being caught by that next section of the header file where it
says
#
Overlapping Ranges are unpredictable. The
following
#
is invalid:
# Tivoli
146.80-90 State
# SalesOffices
146.75-95 City Tivoli
You are
using implied wildcards on your NETx entries, but your catch-all is an
overlapping range. I know you could read this doc to mean it should do what
you want it to do, but it does not actually work that way. I had a customer
take it up with support a while back and they clarified that it works the
way it works. You will have to be a little more specific in your catch-all
definition, I'm afraid.
Actually, I get the impression that as a group, new users have the
idea that the only way to configure the map is with the location.conf file.
There is still the old-fashioned way - cut and paste. For what it's worth,
here's how I use location.conf when I'm implementing Netview for a new
customer network.
1) First
discover the network at least once, and at least all of the routers. Do this
to make sure they are all connected properly, and named they way you like
them. Look at them in a Smartset if they make a furry black ball:) Putting
them away too soon can mask configuration errors that Netview would
otherwise show you.
2) Make a
location.conf file that builds the whole location hierarchy for you,
and places the routers, and the easiest parts of the network ranges.
Concentrate on the remote stuff. That will thin out the map the most. Think
about leaving the core stuff right out on the top layer.
3) Fiddle with this a bit, using file....new map (get
efix for apar IY48698) until the map
is at least readable with zoom
4)Rediscover using the location.conf
5)Take the location.conf out of effect (rename
it), then close/open the map
6)Finish it up by hand. You will change your mind a lot about the
final details, and it is not worth fighting against the location.conf every
time you do. Add some temporary locations manually to hold any large fans
that you are not ready to deal with just yet.
7) When you think you are done, update the
location.conf to match, in case you need to do a rediscovery later on. You
can do this manually, or ask around. A number of people have come up with
scripts that will generate a location.conf from an existing map.
A design consideration: A map
with three things on it does not convey very much information except when
everything is up. I like to see the core infrastructure right on top - eg
all of your pairs of core switches and the major subnets between them. Then
when something does turn yellow, you can gauge the impact at a
glance.
Cordially,
Leslie
A. Clark
IBM Global Services - Systems Mgmt &
Networking
Detroit
|
| "Duppong, Jason"
<jason.duppong@thomson.com>
Sent by: owner-nv-l@lists.us.ibm.com
02/24/2004 03:33 PM
Please respond to nv-l
|
To: "'nv-l@lists.us.ibm.com'"
<nv-l@lists.us.ibm.com>
cc:
Subject: [nv-l] More location.conf
questions...
|
Hello List,
I don't
want to wear out my welcome to this list and I really hope I'm not the only
Netview newbie that gets tripped up on the location.conf file, but I'm
afraid I still need a bit more clarification. I really want to
understand exactly how Netview uses this file for placement of objects.
To this end I've read and re-read release notes and most of the Unix
documentation for Netview, searched through archives on this mailing list,
and played with the file in general just trying to figure things out.
When I make a couple changes and expect one thing and those changes
are not reflected on the MAP the way I understand I get really confused.
I have a rather complex location.conf file, about 600+ lines, breaking
our companies various subnets into containers and sub containers based on
how our network is logically setup (I've worked with countless network
personnel in coming up with the rules for this file). Where I'm conf!
used right now is how to make an "INTERNET" container (doing this is better
then hiding 300+ nodes and segments from the IPMAP). According to the
examples for location.conf, point D indicates:
#
d) If a network matches more than one
entry, the most specific
#
match will be used. So, if we were matching the network
#
146.84.5.5, the address
patterns that it would match (in order
#
of most specific to least specific) are the
following:
#
146.84.5.5
#
146.84.5
#
146.84.1-6
#
146.84
They way that I understand
this example is that I should be able to do an "INTERNET" container with a
line similar to the following:
INTERNET 1-254
U.S.A
When I restart map
generation the initial symbols on my MAP look real promising. Even
during the regen the number of symbols on the map remain relatively constant
except for a number of lines linking to INTERNET that shouldn't. Then
when the map finishes drawing and I double click on the INTERNET container,
I find, to my surprise, all the nodes that should be in a different
container (in this particular case it is all the internal corporate IP's to
my company, which explains all the lines from the other containers). I
have placed the INTERNET container at the top and bottom of location.conf,
nothing makes a difference. Presuming my companies internal subnets
were 10.1.x.x and 192.168.x.x, wouldn't a location.conf looking like this
work?
NET1 10.1
Site2
NET2 192.168
Site3
INTERNET 1-254
U.S.A
Based on the example, Netview would break out
all nodes in the 10.1.x.x subnet and the 192.168.x.x subnet and place them
in the NET1 and NET2 containers while placing all other segments and
connections between NET1 and NET2 to INTERNET if those links/connections
exist? I understand that there will be some stragglers left over that
will appear on the IP Map, but is what I'm trying to do a valid use of the
rules for location.conf? I understand that I probably have a few typos
in my location.conf file, it is 600+ lines long, but this is what the
location.conf file is for right, describing your network? My network
falls into the Medium category for size, so hopefully someone else has a
huge location.conf and already has this working. I guess what I'm
really after is a confirmation that this should work, that way at least I
know I'm not in some wild goose chase.
I
don't think I can thank you Netview Gurus enough for the comments posted
since I've joined this list. I hope you understand how valuable your
experience and comments are to us Netview Newbie's :)
Thanks in advance for any responses....
Jason
|