[Top] [All Lists]

Re: [nv-l] Re: DNS in a distributed environment

To: nv-l@lists.tivoli.com
Subject: Re: [nv-l] Re: DNS in a distributed environment
From: James Shanks <jshanks@us.ibm.com>
Date: Tue, 19 Nov 2002 09:03:13 -0500
 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, 

James Shanks
Level 3 Support  for Tivoli NetView for UNIX and NT
Tivoli Software / IBM Software Group

11/19/2002 03:50 AM

        To:     nv-l@lists.tivoli.com
        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 
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

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 
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 
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 
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 
forwarded with the FQDN to the central server.
If this is not possible, do you have any suggestions on how to handle this

I hope this gave a better explanation to my problem.

Christian Frantsen
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

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)

<Prev in Thread] Current Thread [Next in Thread>

Archive operated by Skills 1st Ltd

See also: The NetView Web