Well, it turned out that ifconfig wasn't really the problem. The
problem was that when you try to do a ping, an attempt is made by
the ping program to resolve the hostname, even if you use an ip number.
So when you try to ping -s 127.0.0.1, ping tries to resolve the name of
your localhost. Now if you happen to be the only machine on a network,
and you have no nameservers defined, then the attempts to use the
resolver cause longer and longer delays as the hostname is not properly
resolved by the address in your resolv.conf file. In this case the
first host in the resolv.conf file was 127.0.0.1 (this machine was
eventually going to be a nameserver). So what we did to fix the problem
was to start up named as early as we could in the rc.local file and
that seemed to fix the problem (although ping never ended up working in
single user mode). A special thanx to Per Hedeland for initially
pointing us out in the right direction...
-David Meleedy
Thanks to :
Steve Lodin <swlodin@kocrsv01.delcoelect.com>
Eckhard R|ggeberg Eckhard.Rueggeberg@ts.go.dlr.de
per@erix.ericsson.se (Per Hedeland)
stern@sunne.East.Sun.COM (Hal Stern - NE Area Systems Engineer)
paulo@dcc.unicamp.br (Paulo Licio de Geus)
From: Steve Lodin <swlodin@kocrsv01.delcoelect.com>
(NOTE: This may be way off so confirm it)
The Sun is incapable of routing between two different class networks, or two
networks with different subnet masks. To do such a thing, usually you need
a real router like a Cisco.
Recommended reading material:
Unix System Administration, Nemeth Seebass Synder
TCP/IP Network Administration, Hunt
Comer's Book
Steven's Book
From: Eckhard.Rueggeberg@ts.go.dlr.de
> 127.0.0.1 localhost.softconf.near.net localhost
I personally think it is a mistake to enter FQHNs in the /etc/hosts file. It
could be the only way for the second ethernet controller, but for the first
and loopback, you are asking for trouble.
What was the reason to change the code in rc.boot concerning ifconfig ?
It runs fine for our gateways, but they don't separate a logical domain, only
physical domains.
Eckhard R|ggeberg
eckhard@ts.go.dlr.de
From: per@erix.ericsson.se (Per Hedeland)
>The problem is this. For some reason when you try to do a ping -s
>127.0.0.1, there are delays that get repeatedly longer and longer. It
>starts out quick, but the delays increase by 7000 milliseconds each
>time.
In all cases where I have seen "increasing delays with ping", it has
been a problem with IP address lookups. On receipt of packets, ping
wants to translate the sender IP address to a name for the display -
there is a timeout if this fails, and somehow the timeouts get
accumulated into the rtt's reported. I.e. I believe you need to check
out how you have configured these lookups (NIS, DNS-via-NIS, direct DNS)
and whether it is working or not - in the particular situation you
describe, I would suspect a problem with routing table entries needed to
reach a non-local name server being incorrect.
Hope this helps...
--Per Hedeland
per@erix.ericsson.se or
per%erix.ericsson.se@sunic.sunet.se or
...uunet!erix.ericsson.se!per
From: stern@sunne.East.Sun.COM (Hal Stern - NE Area Systems Engineer)
are you setting the netmask for the 128.103 net to be 255.255.255.0?
if not, ifconfig uses the default, which can cause confusion. you're
setting a class C bcast address, so i assume you're using class C
subnetting
--hal
From: paulo@dcc.unicamp.br (Paulo Licio de Geus)
I have detected a ifconfig bug that I haven't seen mentioned before.
We detected it because we were in the same situation as you for some
time, i.e. different netmasks on gateway machines.
The solution was to comment out the ifconfig lines in rc.local, since
they make use of NIS maps to match networks with netmasks, and invoke
ifconfig properly (see below). This doesn't seem to work, and there's
even a note between the lines in the System and Network Administration
manual that "suggests" you not to use the standard invocation when
running NIS. The whole thing is not very clear to me, since some
sites choose not to run NIS, so how is the "-a" option in rc.local
ever going to work?!?
The solution we found was true for 4.1, and I haven't checked whether
later releases still present the problem, but we keep doing the work
around.
Anyway, the correct way of invoking ifconfig is as follows (extracted
from my rc.local, 4.1.1):
# pldg:
#ifconfig -a netmask + broadcast + > /dev/null
ifconfig le0 inet 143.106.7.1 netmask 0xffffffc0
ifconfig ie1 inet 143.106.1.11 netmask 0xffffffc0
We now run both interfaces with the same netmask, but the secret is in
the inet part. Although the interfaces, at this point, already have
IP numbers (and you wouldn't need to redefine them again), ifconfig
doesn't work properly if you don't include the inet arguments in the
same invocation, and the interfaces end up in a non-functional state.
Magically, including the inet part, ifconfig works properly and all is
well. This was found by chance (actually a lot of trial and error, of
course).
Hope this helps with your problem.
-- postmaster/manager Paulo Licio de Geus INTERNET:paulo@dcc.unicamp.br Depto de Ciencia da Computacao DCC - IMECC - UNICAMP caixa postal: 6065 13081 Campinas SP Brazil======== David Meleedy Smithsonian Astrophysical Observatory meleedy@cfa.harvard.edu 60 Garden Street, MS 70 Phone: 617 495 7252 Cambridge, MA 02138 USA
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:53 CDT