Thank you Jane. That clears up a lot of things. Didn't realize that the
TLM was taking an "I don't believe what you're telling me until I can prove
it to myself" stance in its relationship to MLM. This is something we are
trying to test to see if we can get objects on the map for our operations
people to "see" so they can "graphically" monitor faults on the protected
side of the firewall. We are currently using NerveCenter in the remote
subnet to manage/correlate traps from these devices and then ship traps to a
Tivoli console, but we can't get anything onto the map. Thought we could
Re: the Ping hole. We can ping ONLY the management server outside the
firewall from specific addresses in our management subnet. So ICMP is
sort-of-open, but on a very restricted basis.
That hand-add method might be worth trying, though.
From: Jane Curry [mailto:jane.curry AT skills-1st.co DOT uk]
Sent: Tuesday, December 04, 2001 2:59 PM
To: IBM NetView Discussion
Subject: Re: [NV-L] MLM and Firewalls
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
information that an MLM sends it unless netmon itself can get at least 1
the discovered node. If you turn on tracing in your firewall and use netmon
12 to track netmon's "ping queue", you can see MLM reporting newly
nodes (using SNMP), these nodes get put on netmon's ping queue but they
get into the NetView object database until a ping succeeds - you can watch
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
Longer term, NetView 7.1 provides a way of running a small NetView inside
firewall that you can access via the web client through your firewall ONLY
http (8080 by default). The extra NetView does NOT need to be running a
GUI - you can run the new netviewd to achieve the same functionality. You
also customise your new NetView to forward selective TRAPs to your main
using either UDP or TCP.
"Kenney, John" wrote:
> This question is based on my fundamental ignorance about how Netview MLM
> Here's the scenario:
> Our Netview top level manager is Netview 6.0.2. We need to manage a
> 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
> 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
> 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
> 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
> should there be a problem with the MLM.
> 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
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 AT skills-1st.co DOT uk>. All rights