If you were on AIX I would be more confident of my answers, but it should
work the same so I will pipe up. First, you should be sure to be at the
latest
level of Netview (5.1.2) unless you have a reason not be be. There have
been lots of bugs fixed over the last two years.
1) The connection you are seeing between the 8274 and the single 8271: is
it on the IP-level submap? If not, where is it?
Understanding the submap heirarchy is important in order for you to know
if discovery is working correctly or not, so here goes, just in case:
Things with more than one interface, or things defined to oid_to_type as G
(gateway, or router) are put on the top level (IP Internet) submap, along
with
the subnets that connect them. Netview does not really know about switches,
and generally treats them as routers if they have more than one address, or
hubs or nodes if they have only one. On the Network submaps you will find
those 'routers' again, plus anything defined to oid_to_type as H or B. You
will
also find here one or more segments, one per interface type. On the segment
submap you will find all of the above, plus anything else with the same
subnet
address, whether it is snmp-reachable or not.
I believe the 8271s, if they are known to Netview at all, are known as
hubs.
So they won't be on the top map at all, only in the network submaps. If one
shows up at the top level, connected to the 8274, it is because it has more
than one IP address, the same way the 8274 got 'promoted'. I see this
often when a slip address has been defined on a device that otherwise has
only one address. So you should be seeing the 8274, with several subnets
connected to it, and inside those subnets, you should see the 8271s that
are on that subnet. If their oids are not known to Netview, or if they are
not
snmp-reachable, they will be even further down, in the segment submaps.
But in that case I would have expected them to be flagged as 'bad oids',
since you say the are all configured the same (community, etc). Don't
assume
they all have the same oid - check them.
Netview does not know about Layer-3 topology. It is strictly subnet-based.
2) It happens sometimes that Neview will put something on a wrong subnet
and then tell you about it. (Be sure you have the latest maintenance on).
It
is not capable of moving things. You should delete that node thoroughly
along with the bogus network, and rediscover it. On AIX, to make sure of
a clean rediscovery, I always stop netmon, delete the things, ovtopofix -a,
and then restart netmon and ping the device at the commandline. I think
it goes the same way on NT. It is possible that a device with a bad mask
(on network 10) has the router in its arp cache and led Netview to find it
and
add it there. The solution is to force Netview to find that router on its
own,
first, by pinging it or putting it in the seedfile.
3) Much of the information you are looking at is set at discovery time,
some
of it is updated on demandpoll. I would not bother hand-editing anything.
After the correction is made to the configuration files, stop/start the
daemons
and delete and rediscover the node as described above.
I spend a few days working out all of the configuration updates needed, and
then flush and rediscover the whole thing to get them all discovered just
right before I commit to any fancy cut/paste or arrangement of the map.
That's what the bad oid business is there for.
I hope this help. Maybe some of the NT folks know about specific problems
encountered on that platform.
Cordially,
Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
Detroit
=========================================================================
Being new to Tivoli, I am somewhat puzzled by the way it works. Here are
some problems I have that maybe you have an explanation for :
1) My network has a relatively simple IP addressing scheme :
* subnet of 255.255.255.0 for all ethernet interfaces
* a central site with a Layer3 switch (IBM 8274) having ip
addresses of
10.20.1.x, 10.20.2.x, 10.20.3.x, 10.20.4.x to form different IP networks
* on subnet 10.20.3.x and 10.20.4.x, eight IBM 8271 switches (4 on
each
subnet)
* On subnet 10.20.2, a Cisco 2503 router connecting to a Frame
Relay
network
* About 30 remote sites, with Cisco 1603 routers connecting to the
FR
network. Networks are numbered 10.20.40.x, 10.20.41.x, and so on
Here are *some* of the problems I encouter when running the
discovery
process :
1) Although all the 8271 switches have the SAME config (except for IP addr
of course), for ONE and only ONE of them Tivoli creates a connexion between
the 8271 switch and the 8274 switch. My question is : why for ONE of them ?
Is there any logical reason ?
2) From time to time the discovered Cisco routers mention a "bad mask",
with
255.0.0.0 instead of 255.255.255.0. For this reason, netview discovers an
ip
network numbered "10", instead of a series of networks numbered "10.20.40"
and so on. When i use "snmpwalk" to check what snmp returns, I do get the
correct 255.255.255.0 netmask.
3) THIS ONE HAPPENS ALL THE TIME : If I happen to hand-modify some element
of a discovered device, I lose some information : Events for that element
don't display anymore, and I also lose the uptime and "general" snmp info
(syslocation etc). I first did this for an Ascend Max unit : since there
was
no OID_TO_TYPE entry for the ascend it would appear as "BAD OID". I
correcte
the OID_TO_TYPE file then stopped and restarted NETview and kept waiting
hours; the status of the Ascend never got corrected. So I tried to
hand-modify the information... and the above data disappeared.
Well this seems like A LOT of strange behaviour, I suppose I miss a key
point but I really believe Tivoli works rather strangely...
Last info I am running Netview IT director edition on a NT Workstation :
Pentium II - 333 / 160 Mb Ram / 8 Gb disk - NT 4.0 SP5.
Anybody has an idea ? Help appreciated !!!
Best regards,
Eric Granados
NETsite S.A.
Mailto:Eric.Granados@NETsite.be
|