RE: [nv-l] NetView and DNS -- you using it? (was Re: RES: [nv-l] /etc/ho

Okay, it's not a strict requirement. HOWEVER, let's discuss for a moment the impact of NOT having one.

First of all, if you have a small environment (all your devices in one building for instance, maybe 100 nodes) You certainly could get by without DNS. No question there. But once your environment is beyond the "let's go look at the box" proximity range, you must rely on others to tell you about new devices. If the device address changes, they must inform you. If you use a strict seed file discovery, then DNS isn't a real necessity but if you use ANY wildcard in your seedfile, you are in essence saying I want to know about all the devices in these subnets. Assuming you want to know about these devices, and assuming your discovery loads up a segment with 20-30-40 nodes, they will be nothing but green boxes. You won't know the owner, the purpose, or the type of device. HOWEVER, this can all be avoided if you use DNS, because when people put a new device on the floor, according to network management standards (you DO have a standards doc RIGHT?) they need to notify the DNS administrator of a new box. If they have notified the DNS guy, and you have discovered the box, and your naming convention is suitable, you will know what the device is and a good idea of who owns it even if you do not have SNMP access to the device. For instance, a device showing up on a subnet called branch1-router is a helluva lot more informative than 10.1.1.1 green box. If other boxes on the segment are labled ntserver-email and ntserver-dhcp and ntserver-wins then you know the function of the devices on the network (email dhcp and wins). You know the operating system and function of the device and that will enable you to pin down the owner of the device for any further questions about it.

Why would you want to use wildcard discovery? Well that's easy. I recently updated my seed file to include 1.3.6.1.4.1.42.* (Solaris). Low and behold when I ran discovery we found a box that had two interfaces, one in a DMZ, the other in a development network totally bypassing our firewall. If the box did not have a name in DNS, I would have spent countless hours trying to figure out what it was. The fact that they had it in DNS and it had a Solaris type name on it, led me to the administrator of the box who promplty apologized profusely for bypassing all company security guidelines.

The point is, DNS is a BENEFIT to your company. It helps with discovery, it helps with security and if the names are adminstered by someone else, it makes your job easier. One guy maintains the DNS and everybody in your company will have to go to him to advise him of new boxes or removed boxes.

And don't start with this stuff about "our organization doesn't work like that...." or "politics prevents us from using it...." These are issues that are founded solely on lack of management support for systems/event management. Make them set standards. Make them live by standards. I've worked a long time for some of the biggest bureaucratic corporations, and they found it easier to deploy DNS than deal with me. Go fight the good fight. I'll get off my soap box now. Go spend the 50 cents and get DNS. This is 2003 for goodness sake.

-----Original Message-----
From: Brian Backer [mailto:brian.backer AT CenturyTel DOT com]
Sent: Tuesday, February 18, 2003 12:17 PM
To: Barr, Scott
Subject: RE: [nv-l] NetView and DNS -- you using it? (was Re: RES: [nv-l] /etc/hosts)

Scott,

Dns isn't a MUST HAVE.... you can use other means like a hosts file..

b

-----Original Message-----
From: Barr, Scott [mailto:Scott_Barr AT csgsystems DOT com]
Sent: Tuesday, February 18, 2003 10:29 AM
To: nv-l AT lists.tivoli DOT com
Subject: RE: [nv-l] NetView and DNS -- you using it? (was Re: RES: [nv-l] /etc/hosts)

If your company endorses event / systems management - they should endorse accuracy/reliability of the DNS environment. No if's and's or but's. They are either in the game or not.

I highly recommend making your NetView slave DNS servers off of the master corporate DNS. This has proven to be an excellent performance enhancement on Netview and reduced network traffic by a bunch. Remember a trap coming in is usually one packet, but there may be a dozen DNS requests to put out on the wire before you can even process the trap internally. DNS is a MUST HAVE, local slave DNS is better.

[Barr, Scott]  -----Original Message-----
From: Davis, Donald [mailto:donald.davis AT firstcitizens DOT com]
Sent: Tuesday, February 18, 2003 9:53 AM
To: 'Bernard Disselborg '; [Barr, Scott]      '
Subject: RE: [nv-l] NetView and DNS -- you using it? (was Re: RES: [nv-l] /etc/hosts)

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 AT lists.tivoli DOT 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 AT toddh DOT 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 AT banespa.com DOT 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 AT Nationwide DOT com [mailto:reamd AT Nationwide DOT com]
> Enviada em: Wednesday, February 12, 2003 17:45
> Para: nv-l AT lists.tivoli DOT 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 AT lists.tivoli DOT com
For additional commands, e-mail: nv-l-help AT lists.tivoli DOT 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 AT lists.tivoli DOT com
For additional commands, e-mail: nv-l-help AT lists.tivoli DOT 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.
==============================================================================