Hi Jack,
I'm afraid your idea won't work (though I am curious about how you have
negotiated a single "ping hole" through a firewall - I always either get "No
ICMP" or "OK" from firewall folk).
The netmon discovery algorithm in NetView fundamentally won't believe discovery
information that an MLM sends it unless netmon itself can get at least 1 ping to
the discovered node. If you turn on tracing in your firewall and use netmon -a
12 to track netmon's "ping queue", you can see MLM reporting newly discovered
nodes (using SNMP), these nodes get put on netmon's ping queue but they don't
get into the NetView object database until a ping succeeds - you can watch the
ping intervals just get longer and longer....
2 ways I have found around this. For starters, put entries in your netmon
seedfile for SNMP polling ($ syntax) of devices behind your firewall. ONCE a
node has been discovered into the object database, you then get it polled by
SNMP. If you only have a few nodes beyond your firewall, you can "hand-add"
them from Edit -> Add Object.... If you have more devices than you wish to
hand-add, use the loadhosts command which is effectively a CLI method of
hand-adding.
Longer term, NetView 7.1 provides a way of running a small NetView inside your
firewall that you can access via the web client through your firewall ONLY using
http (8080 by default). The extra NetView does NOT need to be running a native
GUI - you can run the new netviewd to achieve the same functionality. You can
also customise your new NetView to forward selective TRAPs to your main NetView
using either UDP or TCP.
Kind regards,
Jane
"Kenney, John" wrote:
> This question is based on my fundamental ignorance about how Netview MLM
> works.
> Here's the scenario:
>
> Our Netview top level manager is Netview 6.0.2. We need to manage a subnet
> of inter-company devices which live on the other side of a firewall which
> will pass SNMP traffic but NOT ICMP. Assume for this argument that we will
> never be able to open the firewall for ICMP. We have a server in this
> protected subnet to which we CAN send and receive ICMP traffic, on which we
> can install and run MLM v5.0.7.
> My question is this. If we set up the Top Level NV manager to delegate
> discovery and status checking to the MLM, will that be enough to get
> sufficient information from the nodes on the protected subnet to populate
> the object DB and the map DB on the top-level manager (bearing in mind that
> the top-level manager cannot SEE the nodes to ping them)? i.e. the TLM
> cannot do discovery or status checking, nor could it take over as the backup
> should there be a problem with the MLM.
>
> 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
--
Tivoli Certified Enterprise Consultant & Instructor
Skills 1st Limited, 2 Cedar Chase, Taplow, Bucks, SL6 0EU, UK
Tel: +44 (0)1628 782565
Copyright (c) 2001 Jane Curry <jane.curry@skills-1st.co.uk>. All rights
reserved.
|