We have devices behind a firewall, and the firewall lets
SNMP queries through, but not ICMP pings. So, by including
the routers on the other side of the firewall in the seedfile,
NetView was able to discover the other things (servers) out
there too. I put their addresses in the seedfile with a '$'
in front (for example):
which let NetView do a status poll using SNMP gets (the servers
have SNMP turned on) and everything works fine. Only problem
is that NetView refers to these servers when generating netmon
events as a 'router', so we had to tell the operations staff that
they really weren't routers. Confusing, but OK.
>From: "Kenney, John" <jkenney AT JHANCOCK DOT COM>
>Reply-To: IBM NetView Discussion <nv-l AT tkg DOT com>
>To: "'IBM NetView Discussion'" <nv-l AT tkg DOT com>
>Subject: RE: [NV-L] SNMP Polling
>Date: Tue, 18 Dec 2001 07:10:43 -0500
>Thanks for the insights, James and Leslie. Yes, we are indeed attempting
>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
>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.
>From: James Shanks [mailto:jshanks AT US.IBM DOT 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
>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
>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
>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
>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
>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
>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.
>Level 3 Support for Tivoli NetView for UNIX and NT
>Tivoli Software / IBM Software Group
> "Kenney, John" <jkenney AT JHANCOCK DOT COM>
>Sent by: owner-nv-l AT tkg DOT com
>12/17/2001 02:32 PM
>Please respond to IBM NetView Discussion
> To: "'nv-l AT tkg DOT com'" <nv-l AT tkg DOT com>
> cc: "Lemire, Mark" <mlemire AT JHANCOCK DOT COM>, "Tremblay,
>A." <dtremblay AT JHANCOCK DOT 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
>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'
>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
>Anyone else run into this one? At very least would like to hear of a way
>get around that propagation issue.
>Jack Kenney, MCP+I, MCSE
>CTS/Enterprise Management Tools
>Phone: (617) 572-1031
>Email: jkenney AT jhancock DOT com
>NV-L List information and Archives: http://www.tkg.com/nv-l
Join the world?s largest e-mail service with MSN Hotmail.