I am a heavy user of loopback addresses. The key is (and I think Paul hit on
it) is the "trap source". In cisco-land, this is the snmp trap source statement
which says "use the loop back interface as the origin for traps". This will
mean that every trap that comes in will come in with the DNS-resolved loopback
address. This is also important because if an interface is down, and it happens
to be the interface that would be in the path of the trap reaching NetView, use
of the loopback interface as the trap source allows another network path to be
used. Loopback interfaces can never be down, so the device can not "eat" the
trap because he has an interface down.
If you are in a heavy cisco environment, I would be willing to compare notes on
specific issues with you. Overall, having read Pauls response and being as I
said, a heavy loopback user, you are doing the right things if you can get your
devices to originate their traps from the loopback interface.
-----Original Message-----
From: owner-nv-l@lists.us.ibm.com [mailto:owner-nv-l@lists.us.ibm.com]On
Behalf Of Paul
Sent: Friday, February 06, 2004 11:12 AM
To: nv-l@lists.us.ibm.com
Subject: Re: [nv-l] Netmon changes managed address, Loopback
trap-source, correlation issues, RFI issues - please help.
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
>
|