[Top] [All Lists]

RE: SNMP Polling

To: nv-l@lists.tivoli.com
Subject: RE: SNMP Polling
From: "Kenney, John" <jkenney@jhancock.com>
Date: Tue, 18 Dec 2001 07:10:43 -0500
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.
-----Original Message-----
From: James Shanks [mailto:jshanks@US.IBM.COM]
Sent: Monday, December 17, 2001 3:33 PM
To: IBM NetView Discussion
Subject: Re: [NV-L] SNMP Polling

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.


Jack Kenney, MCP+I, MCSE
CTS/Enterprise Management Tools
Phone: (617) 572-1031
Email: jkenney@jhancock.com

NV-L List information and Archives: http://www.tkg.com/nv-l

<Prev in Thread] Current Thread [Next in Thread>

Archive operated by Skills 1st Ltd

See also: The NetView Web