Bernard,
My most recent experience
tells me that relying on a corporate DNS is a bad idea, unless you are
maintaining that DNS too!
It is of paramount importance that the DNS used by Netview has
100% accurate records.
Here are the some of the issues
that I had with my "corporate" DNS.
These caused major
problems with NetView!
1. All names and addresses do not resolve backwards and
forwards.
(This seems like a no
brainer....but...)
2. Routers must not have different
names on each interface.
(Cisco says it
is ok to name each interface something identifiable,
like routerxyz-e0, routerxyx-s0, routerxyz-l0,
routerxyz-to)
3. All router IP interfaces must
resolve.
4. NetView must use real names, not
round-robin names when it comes to servers.
I experienced all of the above and more. I finally
decided to run my own primary DNS, just for network equipment. I did not want
to just use /etc/hosts because my CiscoWorks server also needs accurate name
resolution. I made certain that all information that I had in NetView
was correct via the /etc/hosts file. Then I wrote a script that parses
the topology database and creates named.conf with individual "SOA" records for
each and every hostname and each and every interface. This means that I have
thousands of zone records, both address and in-addr.arpa. I know this is
unconventional, but, this was done so that my NetView DNS would be
authoratative only for the nodes that were defined and not the entire zone ie.
aaa.com. and forwarding still works.
All is working well and almost completely unattended.
When a new node is added, it is added to DNS by the script
that parses the topology database. When a node is deleted, the script does not
generate DNS records for it because it is gone from the topology
database.
By the way, my corporate DNS is running Microsoft's DNS
server.
Is anyone else using that?
I am running BIND-9.2 on my NetView server
Don Davis
-----Original Message-----
From:
Bernard Disselborg
To: nv-l@lists.tivoli.com
Sent: 2/14/03 2:40 AM
Subject: [nv-l]
NetView and DNS -- you using it? (was Re: RES: [nv-l] /etc/hosts)
Todd,
I've done several implementations of NetView, in most of them
I'm using
DNS.
My opinion on
this: when using DNS it is REQUIRED to run the DNS server
locally.
This to avoid issues with DNS response
times (NetView heavily uses DNS
forward/reverse
lookups) and availability (when DNS is down or with
problems in the network so that DNS can't be reached, NetView is more
or
less down).
It is very
important to have your forward en reverse name resolution
properly configured (A an PTR records).
My
reccomendation is to configure the NetView system as a secondary
server, all the DNS info is stored locally and in can run
independantly
from the primary server in the
network.
HTH,
Bernard
>>> netview@toddh.net 13-Feb-03 18:17:54
>>>
While we're mentioning it.... has anyone experienced specific
gotchas
with NetView being picky about DNS response
times? How many of you
are using DNS happily
with NetView for AIX (and at what level?).
I've recently run into some signficiant issues under NetView
7.1.0
under AIX 4.3.3 ML10 (nmdemandpoll's hanging,
map
syncrhonization--showing hosts green that
ovtopodump shows as down).
We're working with support
and have been alerted to the existence of
the
/etc/netnmrc.pre directives/environment variables
RES_TIMEOUT=1
RES_RETRY=1
that can evidently be helpful in directing NetView to handle
DNS
latency a bit better. It's not yet clear if
these are going to solve
our issue. Resolution
times using the AIX "host" command are
essentially
immediate, as are nslookup queries.
I'm also aware of the Tivoli recommendation to run a
caching-only DNS
server locally on the NetView box
becaues NEtView is such a heavy
consumer of name
resolution resources.
How many of y'all are leveraging DNS as a source of
resolution for
the devices you're monitoring in
NetView? How many are running a
caching-only
server? Is anyone aware of DNS-related gotcha's in
7.1.0 that are fixed in 7.1.2 or
7.1.3? Our direction is to move
to the more recent releases, but production realities mitigate
against
upgrading without a specific reason.
8-)
Can anyone share their experience? How are you handling
name
resolution in your environment?
Best Regards,
Todd
Marcos Antonio Pezzutti Filho <pezzutti@banespa.com.br>
writes:
> Hi Dave,
>
> Besides everithing that my coleagues have said, I
d suggest you to
look at
>
/etc/netsvc.conf file and see what is the order of the terms ? If you
want
> only to resolv name by
/etc/hosts, you have to configure this file in
this
> manner:
>
> hosts=local,bind
>
> -----Mensagem original-----
> De: reamd@Nationwide.com [mailto:reamd@Nationwide.com]
> Enviada em: Wednesday, February 12, 2003
17:45
> Para: nv-l@lists.tivoli.com
> Assunto: [nv-l] /etc/hosts
>
>
> Hi
All,
> 7.1.3
on AIX 5.1... Im trying to get netview to use the
> /etc/hosts for name resolution with no success.. I have
removed the
> etc/resolv.conf which resulted in
netview not allowing me to test
ping,
> demand poll, ect... I get the same result if I just comment
out the
> nameserver line. Any suggestions?
>
> Thank You,
> Dave
---------------------------------------------------------------------
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)
---------------------------------------------------------------------
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)
------------------------------------------------------------------------------
This
electronic mail and any files transmitted with it are confidential and are
intended solely for the use of individual or entity to whom they are
addressed. If you are not the intended recipient or the person responsible for
delivering the electronic mail to the intended recipient, be advised that you
have received this electronic mail in error and that any use, dissemination,
forwarding, printing, or copying of this electronic mail is strictly
prohibited. If you have received this electronic mail in error, please
immediately notify the sender by return
mail.
==============================================================================