I don't think you understand what all these nice folks have been telling you.
It is not netmon which is taking so long to resolve the name, it is the
operating system. netmon does not know nor care what method of name resolution
you use. It mere issues gethostbyaddr( ), and sometimes gethostbyname( ), and
it is up to the operating system to resolve that system call. As I said before,
everything above that line in your stack is being done by operating system code
on netmon's behalf. However long it takes AIX ( or Solaris or Digital) to
resolve that name is how long it takes and netmon itself is just waiting.
That said, the point is that there is nothing netmon nor any other part of
NetView can do to speed up name resolution You have to set it up so that it is
fast. If it isn't, then NetView suffers.
Now I think what everyone has been telling you is that to make this fast, you
should
(a) put as many names found in NetView in DNS as possible, both forward and
reverse lookups,
(b) set up resolv.conf to look in DNS first
(c) make /etc/hosts much smaller because searching the current one is such a
problem. Only use this when you have to.
(d) consider doing more things to speed up name resolution, even if that means
you have more admin work to do, such as NOT having three nameservers to consult
before you time out, and putting a caching server on the NetView box itself.
These are all things other people have done for a satisfactory solution.
James Shanks
Team Leader, Level 3 Support
Tivoli NetView for UNIX and NT
REIBENSCHUH Alfred <alfred.reibenschuh@it-austria.com> on 06/15/2000 01:12:27 PM
Please respond to IBM NetView Discussion <nv-l@tkg.com>
To: IBM NetView Discussion <nv-l@tkg.com>
cc: (bcc: James Shanks/Tivoli Systems)
Subject: RE: [NV-L] netmon and /etc/hosts ?
ok, i think you really want to help me
BUT the following stack trace
------------------------------------
#0 0xd0011e38 in fgets ()
#1 0xd0011d4c in fgets ()
#2 0xd00731dc in ho_next ()
#3 0xd0073758 in ho_byaddr ()
#4 0xd009621c in ho_byaddr ()
#5 0xd00d8194 in gethostbyaddr ()
#6 0xd22413d4 in gethostbyaddr_new ()
#7 0xd2ab3b3c in destDataByIpStr ()
#8 0xd2ab4244 in _OVsnmpConfLookupDestData ()
#9 0xd2aaabc8 in OVsnmpConfResolveDest ()
#10 0xd2ac07d0 in OVsnmpFindNodePwEx ()
#11 0xd2ac0940 in OVsnmpFindNodePw ()
#12 0x102084a8 in ?? () from netmon
------------------------------------
is proof enough that netmon chokes on
the /etc/hosts file since the lock-ups
occur entirely in the ho_by* calls
and fgets() is reading from file :)
AND the follwing table should bring more
confusion on the subject:
DNS | resolv-order | host-lines | time*)
--------+---------------+------------+----------
off | none | 16 | 3 min.
on | hosts,bind | 16 | 5 min.
off | none | 6000+ | 67 min.
on | hosts,bind | 6000+ | 43 min.
on | hosts,bind | 6000+ | 1 min. X)
*) time is the time from a "ovstart netmon" to the
first entry (in netmon.trace) after the the
event-suppression (with the -M 53 as parameter)
X) this is the case if you execute
"xnmsnmpconf -clearCache -event ; ovstart netmon"
whats amiss ?
mfG. Alfred Reibenschuh
INFORMATIONSTECHNOLOGIE AUSTRIA GMBH
TELEKOMMUNIKATION
Networkmanagement
A-1020 Wien, Lassallestrasse 5
T: ++43-1-21717-58947
F: ++43-1-21717-58979
E: alfred.reibenschuh@it-austria.com
-----Original Message-----
From: Ray Schafer [mailto:schafer@tkg.com]
Sent: Thursday, June 15, 2000 6:49 PM
To: IBM NetView Discussion
Subject: Re: [NV-L] netmon and /etc/hosts ?
Alfred,
I understand. I think Michael Seibold hit on the problem: NetView is
trying
to resolve a name to an address, it's not in the local cache, so it goes out
to
your other name servers, and this is what is taking 1 minute or 2. You can
try
using ovtopodump and grep for "Node" then find all your IP names and put
them
in a list, then try to resolve each one. That should show you what names
you
are having trouble with. When you are able to quickly resolve them all,
netmon will work much better.
REIBENSCHUH Alfred wrote:
> >Alfred,
> >Assumptions:
> >
> > 1. Originally you said that you were blocked in some system calls that
> took
> > 1 to 2 mins. I assume you were talking about the gethostbyaddr()
> calls.
> > 2. You have an 4 way s7a with 8GB RAM.
> > 3. You have an /etc/resolv.conf file
>
> >Your problem cannot be with the /etc/hosts file. There is no way an s7a
> with
> >sufficeint memory to suck up a large /etc/hosts file is going to take 1
to
> 2
> >minutes to parse it.
>
> during a debugging session the gethostbyname() calls take for about 1
minute
> NOT the gethostbyaddr() calls
>
> >You must have a problem with DNS. Further, it
> >appears that the addresses you are trying to resolve are not in
/etc/hosts
> >(since your netsvc.conf file says to use local /etc/hosts first, then
DNS).
> >Also, I don't think you can run bind on the loopback address only. Maybe
> you
> >are running named, and /etc/resolv.conf has the nameserver set to
> 127.0.0.1?
>
> ok, once more
>
> we have a combined host/dns resolving strategy
> with resolv order hosts-file then dns
>
> we have a named(bind) running on the netview-host
> in caching-only mode (do you know what means?)
>
> the named is configured to forward any request he can't
> satisfy to the 3 company nameservers using a round-robbing
> algorithm and cache the data till TTL ends (usually 2 days)
>
> >I would try to do something about that /etc/hosts file, but that is
really
> >not going to help much. I think what you should do is what Leslie
> suggested:
> >make the machine a secondary name server. Here is a useful link for you:
> >
>
>http://www.rs6000.ibm.com/doc_link/en_US/a_doc_lib/aixbman/commadmn/tcp_nam
> eres.htm
>
> i'll read it but i don't think it will tell me anything
> new about tcp/ip or dns and name-resolution strategies
>
> >from: Michael Seibold
> >We once had some problems when netview tried to lookup ip-addresses
> >which were not in the /etc/hosts and not in the nameserver configured
> >in resolv.conf, so this nameserver had to ask another nameserver which
> >was not responding. As a result netmon was stuck and no status changes
> >took place (icons remained red, new icons remained blue etc.)
>
> thats why we use a caching-nameserver with 3 other dns-servers behind it
> which all have the same name-database (this is throughly tested)
>
> -- alfred reibenschuh
> _________________________________________________________________________
> NV-L List information and Archives: http://www.tkg.com/nv-l
--
Ray Schafer | schafer@tkg.com
The Kernel Group | Distributed Systems Management
http://www.tkg.com
_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l
_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l
|