|
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.
==============================================================================
|