I wonder what it would do if, in the loadhosts script, you specified it as
a router? I know you can do this if you put multiple addresses with the
same name in that list. This is from the man page for loadhosts:
.......
Examples
You can load the gateway gw1 with IP addresses 15.2.112.1 and 15.2.40.1,
and the node node1 with IP address 15.2.112.96 by entering:
loadhosts -p -m 255.255.248.0 <<EOF
15.2.112.1 gw1
15.2.40.1 gw1
15.2.112.96 node1
EOF
............
It will make a router out of nothing at all if you do this. I've seen it.
As James says, nodes in segments, which is where you usually add nodes
when you add them manually, have a status source of symbol. But so do
routers, in the segment view. I suspect that loadhosts is just smart enough
to
add a router with status source of compound propogate, if you can tell it
that it IS a router. I know that when I manually do what you are doing, it
gets the correct status source.
Cordially,
Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
Detoit
James
Shanks/Raleigh To: IBM NetView Discussion
<nv-l@tkg.com>
/IBM@IBMUS cc:
Sent by: Subject: Re: [NV-L] SNMP Polling
owner-nv-l@tkg
.com
12/17/01 03:32
PM
Please respond
to IBM NetView
Discussion
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> To: "'nv-l@tkg.com'"
Sent by: <nv-l@tkg.com>
owner-nv-l@tkg.com cc: "Lemire, Mark"
<mlemire@JHANCOCK.COM>, "Tremblay, David A."
<dtremblay@JHANCOCK.COM>
12/17/2001 02:32 PM Subject: [NV-L] SNMP Polling
Please respond to IBM
NetView Discussion
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
|