I have a firewall environment with NV 6.0.1 on Solaris 2.6.
DNS entries resolve router name to router's loopback address only -
reverse DNS resolves all interfaces back to the one name.
I have $<router loopback address> and simply <router loopback address>
in my seedfile
My router is a firewall - he will ONLY respond to SNMP on the loopback
interface - not on others.
ICMP is blocked entirely so ping's are not respnded to.
My router doesn't get discovered automatically even though the router
loopback is specified in the seedfile as an exact entry. I can live
with this and hand-add the node which then has to be hand-demand polled
before he turns from blue to green (although, using netmon -a 16 , I can
see that SNMP polls are going to the box as soon as he has been added
but he stays with STATUS of UNKNOWN) - again, I can live with that.
Once node is discovered and STATUS of UP, everything is fine - the rest
of the interfaces are discovered using SNMP and are monitored using
SNMP, the SNMP requests from netmon are still sent to the router
loopback address - no worries.
The problem comes when someone accidentally does a Test -> Ping of this
router. This router is a firewall and doesn't respond to ping so the
ping times out and the node is marked down. This shouldn't be the end
of the world - my polling interval is 1 minute so inside 60 seconds he
should get an SNMP poll that brings him back up again. The major
problem is that, since the ping, he seems to have changed his SNMP Poll
address from the loopback (which responds to SNMP), to one of the other
interfaces which doesn't!!!! So SNMP polls also time out, as do Test ->
Demand Polls. My router stays red.
I know that not permitting pings through the firewall is somewhat
draconian but my security manager is paranoid (and still "the
customer").
We have also tested the same scenario where pings generally ARE enabled
but the router loopback stops responding to ping - same result - the
SNMP poll address gets changed under the NetView covers, to an interface
that doesn't respond to SNMP. Continuing with this scenario, when the
router loopback restarts responding to ping, you must Test -> Ping the
loopback interface and the SNMP Poll interface magically goes back to
him again - everything OK.
I guess what we are saying is that SNMP-polled devices MUST be ping'able
on their SNMP-poll interface ('cos someone is going to try and Test->
Ping sooner or later). From a NetView development point-of-view, if
there is an algorithm that internally swaps the SNMP poll interface
after a failed ping, then the algorithm should continue to cycle through
the list of possible interfaces for it's SNMP poll. Ideally, the user
should have control over the SNMP poll interface.
Has anyone else seen this? Can anyone else reproduce it?
All comments gratefully received,
Jane
--
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.
|