Damn, I tried to send this two times before but it seems not have reached
the nv-l server.
Oliver
----- Forwarded by Oliver Bruchhaeuser/Germany/Contr/IBM on 10.02.2004
08:10 -----
|---------+---------------------------->
| | Oliver |
| | Bruchhaeuser |
| | |
| | 09.02.2004 13:58 |
| | |
|---------+---------------------------->
>--------------------------------------------------------------------------------------------------------------------|
|
|
| To: nv-l@lists.us.ibm.com
|
| cc:
|
| From: Oliver Bruchhaeuser/Germany/Contr/IBM@IBMDE
|
| Subject: RE: [nv-l] Netmon changes managed address, Loopback
trap-source, correlation issues, RFI issues - |
| please help.(Document link: Bruchhaeuser Oliver)
|
|
|
|
|
|
|
|
|
|
|
>--------------------------------------------------------------------------------------------------------------------|
all you loopback-guys should set the netmon option:
NV_NETMON_IGNORE_RESP_SNMPADDR=TRUE
in /usr/OV/conf/netmon.conf.
This causes netmon NOT to change the SNMP address if it receives an answer
to a SNMP request from a different interface.
Oliver
|---------+---------------------------->
| | "Alan E. Hennis" |
| | <Hennis_Alan_E@ca|
| | t.com> |
| | Sent by: |
| | owner-nv-l@lists.|
| | us.ibm.com |
| | |
| | |
| | 06.02.2004 20:50 |
| | Please respond to|
| | nv-l |
| | |
|---------+---------------------------->
>---------------------------------------------------------------------------------------------------------------------|
|
|
| To: nv-l@lists.us.ibm.com
|
| cc:
|
| Subject: RE: [nv-l] Netmon changes managed address, Loopback
trap-source, correlation issues, RFI issues - |
| please help.
|
|
|
|
|
>---------------------------------------------------------------------------------------------------------------------|
Scott and Paul
Excellent advice. Source your traps to a know IP address. Cisco routers
will use as a source address for traps of which ever interface a packet
leaves. If you have two WAN/Serial interfaces on a router the source
address of the trap will be which ever interface the packet leaves. In this
example the packet can have one of two different source addresses depending
which interface is used for egress.
I have a mostly Cisco shop. I would also be interested in exchanging war
stories. We use almost every model of Cisco router and switch, wireless
access point, CSS (a.k.a. ArrowPoint load balancer), ONS 15454 and ONS
15540.
Thanks
Alan E. Hennis
Caterpillar Inc.
Systems+Process Division
309.494.3308
hennis_alan_e@cat.com
"Barr, Scott"
<Scott_Barr@csgsy
stems.com>
Sent by:
owner-nv-l@lists. To: <nv-l@lists.us.ibm.com>
us.ibm.com cc:
02/06/2004 01:19
PM Subject: RE: [nv-l] Netmon
changes managed address, Loopback trap-source,
Please respond to correlation issues, RFI
issues - please help.
nv-l
Caterpillar: Confidential Green Retain Until: 03/07/2004
Retention Category: G90 -
General
Matters/Administration
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
>
|