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.
Thanks
for the insights, James and Leslie. Yes, we are indeed attempting to
discover and manage routers and hubs beyond that firewall. I suspect
security will give us ICMP access long before we can figure out an easy way to
manage those devices. Sounds like there might be a 'cure', but the cure
could kill us. I will experiment with Leslie's method of 'clueing in'
Netview by coding all the interface IP addresses in the loadhosts statement, but
this might be difficult to automate. Under normal conditions, we add new
routers by plugging their loopback addresses into the seedfile, recycling netmon
and then let NV do the rest... all of which is part of an automated batch cycle
which interacts with our equipment inventory system.
Thanks
again.
What kind of
objects are you trying to add with loadhosts? You have routers beyond
your firewall that you are trying to represent in NetView?
The purpose of loadhosts is to add nodes,
and interfaces to nodes, to the database and the map, and normal nodes
have Symbol Status Source = Symbol, so that is what it is going to use.
If you look at a normal node on this side f your firewall, you will see
this to be true. netmon sets the status on the node and the interfaces
below it. They are never created with Symbol Status Source = Compound
Propagated. Drill down in a normal segment and see. So loadhosts
is working correctly and as designed.
What you are doing is a bit beyond what was intended for SNMP
polling, as I understand it. It was never intended as a means to
extend NetView beyond a firewall, but only as a means to monitor
interfaces on a router which could not be monitored by ping, like unnumbered
serial, admin down, HSRP, and ISDN. It was not intended for discovery
to proceed this way, else you would not have to use loadhosts to add those
nodes. My guess, and it is only a guess, is that the several polling
cycles are necessary because netmon has to re-adjust the topology before he
gets things right. If these are routers, the normally, you would not see
an interface on the map before netmon can find the other end. Since you
put it there, it may take him awhile to figure things out.
In the normal course of events, when netmon discovers that something is
a router, he changes the flags on it (you should see a trap ! ! to that effect
in the window or trapd.log) and when ipmap gets that trap he deletes the
object and re-adds it with the right source and puts it on the IP Internet
map. Until it shows up there, it will never have a status source of
compound propagated. By default, networks and segments have that source,
not nodes.
I don't know any
workarounds, but I think it is entirely reasonable to say that if you are
adding a router, you may very well have to change the status source
yourself.
Of course, this is all
reasonable speculation, based on what I do know extended to what I don't.
I don't do netmon for a living. If you want to see what is really
going on, you'll need to run a full netmon trace when you work with
these things, and if you want help interpreting that, then you'll need to call
Support.
James Shanks
Level 3
Support for Tivoli NetView for UNIX and NT
Tivoli Software / IBM
Software Group
|
| "Kenney, John"
<jkenney@JHANCOCK.COM>
Sent by: owner-nv-l@tkg.com
12/17/2001 02:32 PM
Please respond to IBM NetView Discussion
|
To:
"'nv-l@tkg.com'" <nv-l@tkg.com>
cc:
"Lemire, Mark" <mlemire@JHANCOCK.COM>, "Tremblay,
David A." <dtremblay@JHANCOCK.COM>
Subject:
[NV-L] SNMP Polling
|
We are running NV 6.02 on Solaris 2.6:
We are
using SNMP Polling to discover/monitor objects outside a firewall
which
restricts ICMP traffic (therefore no Pinging). I have flagged
the
various subnets affected in the seedfile using '$' records. I
have also
implemented a Perl script which uses 'loadhosts' and
'nmdemandpoll' to add
these objects to topology and force initial
discovery.
My issue is this:
It seems to take several polling
cycles, including the initial demand-poll,
before the objects are correctly
represented on the map, i.e. many
interfaces are discovered as 'down' when
they are actually 'up' (I check the
MIB). This will usually clear
itself up after a few polling cycles or
repeated demand-polls subsequent to
discovery.
Also, when the object icons appear on the map, the 'Status
source' parameter
for all the SNMP monitored objects defaults to 'Symbol',
where we would
expect these to come up as 'Compound (Propagated)' .
The result of this is
that 'down' conditions on these objects are not
propagated to parent
submaps, so you never know there's a problem unless
you drill down inside
the affected object (or wait for the trap
notifications to show up on the
Tivoli console). I have to go into
each object individually and set this
parameter correctly.
Anyone else run into this one? At very least would like to
hear of a way to
get around that propagation
issue.
Thanks.
Jack Kenney, MCP+I,
MCSE
Consultant
CTS/Enterprise Management Tools
Phone: (617)
572-1031
Email:
jkenney@jhancock.com
_________________________________________________________________________
NV-L
List information and Archives:
http://www.tkg.com/nv-l
|