Christian -
I have no easy suggestions for you. NetView internal traps are a special
case. netmon includes the FQDN of the origin as the second varbind so
that it is always available, other vendors do not. And when trapd gets a
NetView internal trap, he formats what you see using that varbind -- he
"knows", if you will, what a NetView trap should look like. But there is
no special handling for the traps from other vendors, except some old,
legacy HP code.
The only alternative solution I can think of for you is ugly and
cumbersome. You would not forward these traps from other vendors
directly, but intercept them, either with a ruleset or a script running
out of ovactiond, and issue a new trap which adds the FQDN as one of the
varbinds, and then at your central server you receive that trap instead.
Lots of work on your part for each vendor trap you want to see.
I don't understand what you mean when you say CNAT would not solve all
your problems, but I don't want to debate that. But it would certainly
solve this one. That's what it is designed to do. CNAT is the NetView
solution. It's now a free part of the product in the latest releases,
7.1.3
James Shanks
Level 3 Support for Tivoli NetView for UNIX and NT
Tivoli Software / IBM Software Group
cfrantse@csc.com
11/19/2002 03:50 AM
To: nv-l@lists.tivoli.com
cc:
Subject: [nv-l] Re: DNS in a distributed environment
Thank's for you answer James, let me see if I can explain a little better
how everything is connected.
We have a central netview machine that reside in our management network,
this machine monitors all customers that are connected to us, unless they
are using RFC1918 address space.
If the customer uses RFC1918 address space we put a netview server with
one
interface on their LAN and one connected to our management network. This
way we don't have to route their address space in our management network.
We did take a look at CNAT but decided that it didn't solve all our
problems.
These "edgeservers" as I call them, monitor their respective customer
network and then forwards a specified number of traps to the central
machine where all the rule processing is done, and we get a focal point
where we can look at all events from all networks.
Now all that we need is some way of telling what customer a specified
event
is coming from, since they can have the same IP as another customer. This
was supposed to be done by resolving the name at the "edgeserver" and
using
the DNS name to tell from what customer the event came.
The internal traps (Interface Down/Up etc) from the "edgeservers" appears
with FQDN in the central netview server but not traps such as
authentication failure, coldstart, cisco linik down/up etc.
These names can not be resolved in the central netview servers since they
don't exist in either host och dns files, so the name must be coming
directly fom the "edgeserver". It's not possible to add them to the
central
serves host or dns flies either since there are overlapping ip addresses
hence my need to resolve them "on step earlier".
I was hoping traps would be received by the "edgeserver", resolved and
then
forwarded with the FQDN to the central server.
If this is not possible, do you have any suggestions on how to handle this
situation?
I hope this gave a better explanation to my problem.
Christian Frantsen
GIS/NES
CSC, Computer Sciences Corporation
Jonkoping, Sweden
---------------------------------------------------------------------
To unsubscribe, e-mail: nv-l-unsubscribe@lists.tivoli.com
For additional commands, e-mail: nv-l-help@lists.tivoli.com
*NOTE*
This is not an Offical Tivoli Support forum. If you need immediate
assistance from Tivoli please call the IBM Tivoli Software Group
help line at 1-800-TIVOLI8(848-6548)
|