Very Computer

Recently, our primary DNS server went down. This shouldn't have been a
problem since we have a secondary, but in fact it was. None of the Linux
machines were able to ping anything, including their own network interface.
I would have assumed that the resolver was timing out on the first nameserver,
but since I was pinging IP addresses this shouldn't have happened, correct?

Each Linux server's /etc/resolv.conf looked like:

search mydomain
nameserver 1
nameserver 2

I then found that if I did this:

search mydomain
nameserver 2
nameserver 1

or removed /etc/resolv.conf completely then the problem went away--I could
ping. (BTW, I was using IP addresses and not symbolic names!)

This is quite scary, and I am looking for a fix. We are running RH6.2 with
Linux kernel 2.2.14. Is this a known bug, or do I need to configure something
differently?

I can supply any additional, relevant information as required. Thanks for any
help.

Regards, Dustin

--

Integrate Linux Solutions into Your Windows Network
- http://www.prima-tech.com/integrate-linux

Correct. Didn't they have their own hostname in their /etc/host tables?

Peter

Quote:Peter writes:
> Correct. Didn't they have their own hostname in their /etc/host tables?

I believe that he should be able to ping the IP of any interface that is
configured up no matter what is in /etc/hosts.  IIRC the kernel
short-circuits such packets.
--
John Hasler

Dancing Horse Hill
Elmwood, Wisconsin

tables?

Quote:> I believe that he should be able to ping the IP of any interface that
is
> configured up no matter what is in /etc/hosts.  IIRC the kernel
> short-circuits such packets.

That's correct.  But maybe his path includes an nfs mounted directory,
mounted hard.  Or maybe he tried it from within X with the display
variable set to me.my.mine:0.

I.e. I am looking for things that would prevent him seeing what is
happening by locking most of his machine up.

Peter

Yes. I always have:

127.0.0.1       localhost
aa.bb.cc.dd     hostname hostname.domainname

But since I was using IP addresses rather than hostnames I don't think
this would actually come into play.

Regards, Dustin

--

Integrate Linux Solutions into Your Windows Network
- http://www.prima-tech.com/integrate-linux

No on all of these.

Quote:>I.e. I am looking for things that would prevent him seeing what is
>happening by locking most of his machine up.

Well, if I have time and I get the greenlight I am going to try and reproduce
this error. I'll then come back with more information.

Anyway, any more ideas, clues, or gotchas?

Regards, Dustin

--

Integrate Linux Solutions into Your Windows Network
- http://www.prima-tech.com/integrate-linux

If you have a spare machine (or even a spare window to run it on) run
tcpdump and log the results.

Tauno Voipio

        It wouldn't.  DNS converts names to addresses and possibly vice
versa.  _That's_it_.  (OK, there are MX records, but that's a special case.)
Likewise with /etc/hosts.  The failure of name resolution should never
prevent you from pinging by IP address.  Is your nameserver serving any
other purpose, like being your gateway?  How is your gateway defined, for that
matter?  I'm not 100% sure it makes any difference, but your gateway should
probably always be defined numerically, not by name - else you might not be
able to reach it if the nameserver goes down.  What's the netmask for your
machines?  What's in your /etc/host.conf?  Is it possible that the
nameserver is crashing in such a way that it becomes a jabber and prevents
anything else from talking on the network?  When the network is down, what's
the output of 'netstat -rn' and 'ifconfig'?

        The suggestion to run tcpdump on another machine is a good one.  I
would also suggest (while the network is running OK) pinging something else
by numeric address, and disconnecting the nameserver while the ping is
running, just to see if you can reproduce anything that way.

JDW

On Wed, 31 Jan 2001 17:31:39 GMT, Tauno Voipio

Well, I tried to reproduce the problem and couldn't. Perhaps it was something
else. Here is what I tried:

<---start--->

search veda
nameserver 192.168.0.26
nameserver 192.168.0.60

order hosts,bind
multi on

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.0.23    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0 eth0

eth0      Link encap:Ethernet  HWaddr 00:D0:B7:8E:C8:BE  
          inet addr:192.168.0.23  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:697307 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1158893 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          Interrupt:17 Base address:0xb000

PING gatekeeper.veda (192.168.0.1) from 192.168.0.23 : 56(84) bytes of data.
64 bytes from gatekeeper.veda (192.168.0.1): icmp_seq=0 ttl=64 time=2.0 ms

--- gatekeeper.veda ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 2.0/2.0/2.0 ms


PING gatekeeper.veda (192.168.0.1) from 192.168.0.23 : 56(84) bytes of data.
64 bytes from gatekeeper.veda (192.168.0.1): icmp_seq=0 ttl=64 time=2.0 ms

--- gatekeeper.veda ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 2.0/2.0/2.0 ms
<---stop--->

The difference here is that packets for 192.168.0.26 are not being routed. In
the original problem packets were being routed, but the machine was down.

I would accept the theory that this is a problem with my sanity and not the
machines, but I did a fair amount of testing when the problem occurred and
I'm pretty sure that it in fact was related. Hmm..

Regards, Dustin

--

Integrate Linux Solutions into Your Windows Network
- http://www.prima-tech.com/integrate-linux