Tim,
Your answer is DNS. You should also make sure that all of
the loopback interfaces are in DNS and that all the devices
are configured with the loopback interface as the SNMP
interface. In other words, when that device sends back
a snmp request or snmp trap, it uses the loopback address
as the address in the packet. If you do not specifically
configure this to use the loopback address it may well use
a different address, causing NetView to change the SNMP
address.
I think your problem here is that the loopback address is
not the configured SNMP Address on the agent itself. So when
that device sends a trap or a SNMP reply, NetView changes
the SNMP address in the database, that is what your device
is telling it to do. You want the device marked down if the
loopback interface goes down? It sounds to me like you are
trying to get NetView to do something it is not designed to
do. NetView is a Network Management Station designed to
manage your network, not a certain interface on a certain
device. Since your desire seems to be to cripple NetViews
functionality for your needs, I would suggest just turning
off SNMP on those devices(or put a bad community name into
NetView). That way NetView will be unaware of the other
interfaces and you can just use ping. That way if it is
unable to ping, it will be marked down.
As for 3 and 4, you say RFI doesn't work, but in the next
paragraph you state that you are getting unreachable
traps. That doesn't make sense. If NetView knows about
mutlitple routes to get into a subnet, the device will not
be marked unreachable as it can be reached via a different
route. If you are getting unreachable traps, then NetView
believes that all routes to that subnet are not reachable.
As for the non-unique addresses you can define that ip
address as HSRP in the seedfile and NetView will stop
deleting and readding it.
Paul
Evens, Tim wrote:
Hello Everyone,
I've been trying to get some assistance with the support engineers, but none
of them were able to provide any answers. In fact, they're still working on
it. I was hoping that there were people out there like us that use
loopback addresses to manage devices. We have a fairly large network with
routers and switches. 50% of the monitoring is using Netview/netmon/ipmap
with node up/down traps, the other 50% is for event traps sent from the
routers/switches to netview. I am having major problems with correlating
the event traps received from the snmp agent to the netview map. It seems
that nvcorrd uses the ip address that the trap was received from to
correlate it to the map/ruleset. The problem I'm running into is that
Netview is changing the IP address it uses to monitor the device to
something other than the address I configured either through loadhosts or by
specific host entry in netmon.seed.
Some key facts: We're using Netview 7.1.3 fix pack 2. 99% of the devices
are in DNS. Almost all interfaces resolve to DNS names. I've made sure that
the selection name for the node is the same as what the loopback resolves
to. The ruleset that tries to match the trap event to the map fails because
it can't find the same object ID (decimal format of the ip address) because
the map changes the address that it uses to monitor the device dynamically.
Below are the questions and problems that I've been trying to get resolved
using IBM support, but haven't been able to...
Problems/Questions
1) I have been struggling with Netview to stop it from changing the
SNMP address to a different link that it learns when it discovers the
device. I have found that if I disable the ipmap from changing customized
symbol settings it seems to keep it under control, but I have to add devices
a via the loadhosts command. Oh, I also have to have disable discover of
new nodes. If I try to use the seed file with explicit hosts lists,
netmon/ipmap will change the SNMP address to an address that it can't manage
or shouldn't be using to manage the device. Is loadhosts the only way to
force Netview to use a configured SNMP address? Is this really going to work
or am I just lucky that I currently have it working in netview using the
address that I added using loadhosts?
2) In addition to issue defined in item 1, by netview changing the
SNMP address to a different link address for the device, it causes
correlation to be completely messed up. I have smartset rules that identify
devices based on different attrs. When a trap is received via the SNMP
agent, not generated by netview, nvcorrd doesn't know how to correlate it to
the device in the ruleset. By reviewing a nvcorrd trace, I can see that the
cause appears to be with netview using a different address as the SNMP
address.. An engineer with IBM told me that it was suppose to use the
HOSTNAME/Selection name to correlate in the ruleset, but that's not what's
happening. Obviously this is a major issue as each device in our network
has been configured to source traps from a loopback address. Now I have
used techniques listed in option one to get it working, but it seems to be
working by a very thin hair. How can I make sure that Netview will not
change the SNMP management address for the device, even if the interface
that it's using for monitoring goes down. If the management address goes
down, then I need that device to go down, even if there's another interface
that Netview can use. If it doesn't, then all correlation is lost and moot.
Thus, doesn't work!
3) In addition to the above, I have been trying to correlate devices
that reside on the same network. I have researched through redbooks,
whitepapers, knowledge base online and with IBM support desk engineers to
find out if it is even possible to perform this type of correlation. For
instance, a router goes down at site A, netview then generates this trap as
a router down trap. Which is good, but it also generates traps for each
device that was behind that router. Can I configure Netview to suppress
traps for node down, router down, etc... events for devices that are behind
a router? RFI is enabled, but doesn't work. The check route option sounded
like it would work as a replacement for RFI, but after spending some time
with it, it doesn't seem to do anything. The documentation on check route
or this type of correlation seems to be sparse or non existent. Can this
type of correlation be done, if so, can someone direct me to documentation
or example of how they got it working?
4) I have been receiving unreachable traps when I should be getting
node/router down traps. Why would this happen? It doesn't seem to do it
for all devices, just a few. It's causing problems because in some cases I
get both or one or the other. Meaning, some devices will only report
unreachable, some will report down, and others will report both unreachable
and down. How do I get it so that it only generates down events when a
device goes down?
5) We use an additional loopback (not the management loopback) with
a non unique address on several devices. This design works extremely well
for the purpose of it, but Netview seems to have major issues with it.
Netview seems to get stuck in loops on adding and deleting the device and
interface. How can I exclude Netview from monitoring addresses/interfaces
that I do not want it to add/discover? I tried to exclude it in the
netmon.seed file, but that didn't work. And trying to unmanage it doesn't
work either because netview just deletes/adds it again.
Any help would be greatly appreciated.
Thanks,
Tim Evens
|