Stephen,
Thanks
for the reply. Yes, I do have snmp trap-source on every router, so that's
not the problem. I'm currently rebuilding the map from scratch with a
revised seed file, blocking out some interfaces as HSRP. So far, from what
I can tell, it's working ok.
We'll
see if it stays and continues to learn correctly. Since I have built
a new map, I'll have to wait and see if RFI is working. I did notice
that when I used loadhosts, the setting for netmon was to add new segments as
unmanaged. This probably was causing my issue with RFI. Now that I'm
back to using netmon.seed, RFI should work as documented. At least I hope
so!
--Tim
Tim,
Interesting questions. I have never been a fan of turning off
discovery...because NetView's discovery always finds objects that the best
network administrator did not expect. Check back on Leslie's note of a sample
netmon seed file that tunes your discovery to just what you want.
1. My
experience with NetView is that he sets the 'first' interface discovered for a
node as the SNMP interface. When NetView is discovering, can you force it to
discover a single interface over another...no. Not unless you have discovery
off and force yourself to feed NetView with loadhosts.
Can you change
the SNMP interface after discovery? I would say yes to this. Drill into the
device to the submap containing interfaces. Select all interfaces except for
the interface you want to be the SNMP interface and delete them from NetView.
Then do a demandpoll of the device to rediscover the interfaces on that
device. You now have the SNMP interface that you want. You could probably
script this process with the new nvmaputil function.
Once the SNMP
interface is set it SHOULD NOT CHANGE.....unless you have duplicate IP
addresses messing things up. Then NetView may delete and add
interfaces...which may change the SNMP interface if he is the one being
deleted and added.
2. I let leave this up to support working with your
logs and traces.
3. RFI does work well, but I wonder if you understand
it. Also, it ONLY works if you have a full network picture. If you have loaded
using loadhosts is your network completely connected or does it have islands?
If it has islands, most likely you are missing devices and thus RFI has
problems.
Check the documentation for explanation of RFI. It has
evolved with each release. Basically, if every router interface in a subnet
goes down, then NetView will mark that subnet unreachable and stop polling the
servers in that subnet. Before marking it unreachable during the polling cycle
you may have received some server node down traps before NetView had polled
all the router interfaces. So when something becomes unreachable then some of
the servers may have been marked down, others up....depending on timing of
polling.
4. Last...if you are getting unusal items on RFI....this may
be a side affect of you not letting discovery work. When you use loadhosts,
you specifiy the subnet mask. What happens when the engineer made a mistake in
the router and what you specify is not right. This can put the device in the
wrong subnet in NetView and mess up RFI a bit.
5. non unique address
-- yuck. Have you tried to mark that as an HSRP address in netmon seed file?
Not sure if it will help.
Recommendation: 1 Write a script that can
detect in the NetView database which interface is being used as SNMP interface
and fix it based on info above. You can then use this to clean up discovered
network from step 2. 2 Get Leslie's starter netmon seed file and use
discovery to bring in your network. You can try to put in SNMP addresses as
seeds, but no guarentee they will be first address discovered 3 Continue to
work with support if nvcorrd problem does not get resolved
Make sure
that device name is in DNS ...and it resolves to your SNMP address (no other
addresses) Make sure that all addresses are in reverse lookup table and
resolve to proper host name
Stephen Hochstetler
shochste@us.ibm.com International Technical Support Organization at
IBM Office - 512-838-6198 (t/l 678) FAX - 512-838-6931 http://www.redbooks.ibm.com
|