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
|