Re: SNMP Polling

["James Shanks" <jshanks@us.ibm.com>]

This is a multipart message in MIME format.

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



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