DNS or router trouble?
Tony
know, not this again. But I've been reading for days on deja and I
haven't found a solution yet. Thanks for your patience.
We have our OpenServer 5.06a box connected to a large network at the
customer site. They are using a Windows 2000 box as the DNS server and
DHCP server.
A series of machines at 192.168.1.xxx are assigned a fixed address which
includes our SCO server.
All other machines are assigned addresses by the DHCP server onto an
network of 10.14.100.xxx.
If I ping a machine using hostname on 192.168.1.xxx it works great.
If I ping a machine using hostname on 10.14.100.xxx it takes forever!
Here is an exampe output of 'ping hostname'
The response takes several seconds before it is displayed.
============================================================================================
root@scobox /etc# ping hostname
PING hostname.customerdomain.com (10.14.100.17): 56 data bytes
64 bytes from 10.14.100.17 (10.14.100.17): icmp_seq=0 ttl=127 time=0.754 ms
64 bytes from 10.14.100.17 (10.14.100.17): icmp_seq=1 ttl=127
time=14869.597 ms
64 bytes from 10.14.100.17 (10.14.100.17): icmp_seq=2 ttl=127
time=13869.699 ms
64 bytes from 10.14.100.17 (10.14.100.17): icmp_seq=3 ttl=127
time=12869.780 ms
64 bytes from 10.14.100.17 (10.14.100.17): icmp_seq=4 ttl=127
time=11897.362 ms
64 bytes from 10.14.100.17 (10.14.100.17): icmp_seq=5 ttl=127
time=10897.459 ms
64 bytes from 10.14.100.17 (10.14.100.17): icmp_seq=6 ttl=127
time=9897.551 ms
64 bytes from 10.14.100.17 (10.14.100.17): icmp_seq=7 ttl=127
time=8957.766 ms
64 bytes from 10.14.100.17 (10.14.100.17): icmp_seq=8 ttl=127
time=7957.861 ms
64 bytes from 10.14.100.17 (10.14.100.17): icmp_seq=9 ttl=127
time=6957.958 ms
64 bytes from 10.14.100.17 (10.14.100.17): icmp_seq=10 ttl=127
time=6000.282 ms
64 bytes from 10.14.100.17 (10.14.100.17): icmp_seq=11 ttl=127
time=5047.065 ms
64 bytes from 10.14.100.17 (10.14.100.17): icmp_seq=12 ttl=127
time=4047.168 ms
64 bytes from 10.14.100.17 (10.14.100.17): icmp_seq=13 ttl=127
time=3047.310 ms
64 bytes from 10.14.100.17 (10.14.100.17): icmp_seq=14 ttl=127
time=2107.007 ms
64 bytes from 10.14.100.17 (10.14.100.17): icmp_seq=15 ttl=127
time=1107.100 ms
64 bytes from 10.14.100.17 (10.14.100.17): icmp_seq=16 ttl=127
time=107.208 ms
--- hostname.customerdomain.com ping statistics ---
17 packets transmitted, 17 packets received, 0% packet loss
round-trip min/avg/max = 0.754/7037.584/14869.597 ms
=========================================================================================
If I use 'ping -n hostname' it is fast as expected.
Every thing I have read from the group indicates this is a DNS problem.
But if I try 'nslookup hostname' it responds with an address
immediately. I was under the impression that this would be a good test
of the DNS.
My resolv.conf files is this:
hostresorder local bind
domain customerdomain.com
nameserver 192.168.1.122
Could it be an issue with their router? Or is there something about
their DNS which is not set correctly. I would love to tell them whats
wrong with their network but I want to make sure that something isn't ME!
Here is some more info. The results of 'netstat -rn'
root@scobox /etc# netstat -rn
Routing tables
Destination Gateway Flags Refs Use Interface
default 192.168.1.1 UGS 0 1 net0
10.11.100.13 192.168.1.1 UGHD 0 24 net0
10.11.100.53 192.168.1.1 UGHD 0 206 net0
10.11.100.61 192.168.1.1 UGHD 0 10 net0
10.11.100.63 192.168.1.1 UGHD 0 5 net0
10.11.100.65 192.168.1.1 UGHD 0 12 net0
10.11.100.68 192.168.1.1 UGHD 0 290 net0
10.11.100.69 192.168.1.1 UGHD 0 20 net0
10.11.100.70 192.168.1.1 UGHD 0 27 net0
10.11.100.77 192.168.1.1 UGHD 0 147 net0
10.11.255.254 192.168.1.1 UGHD 0 3 net0
10.13.100.2 192.168.1.1 UGHD 0 30 net0
10.14.100.3 192.168.1.1 UGHD 1 187 net0
10.14.100.7 192.168.1.1 UGHD 0 7 net0
10.14.100.13 192.168.1.1 UGHD 0 40 net0
10.14.100.14 192.168.1.1 UGHD 0 8 net0
10.14.100.17 192.168.1.1 UGHD 1 511 net0
10.14.100.18 192.168.1.1 UGHD 0 2 net0
10.18.100.3 192.168.1.1 UGHD 0 4 net0
10.18.100.6 192.168.1.1 UGHD 0 9 net0
10.18.100.10 192.168.1.1 UGHD 0 45 net0
10.18.100.12 192.168.1.1 UGHD 0 1 net0
10.18.100.18 192.168.1.1 UGHD 0 2 net0
10.18.255.254 192.168.1.1 UGHD 0 3 net0
10.19.100.4 192.168.1.1 UGHD 1 13 net0
10.19.100.5 192.168.1.1 UGHD 0 0 net0
10.19.100.6 192.168.1.1 UGHD 0 0 net0
10.19.100.12 192.168.1.1 UGHD 0 0 net0
127.0.0.1 127.0.0.1 UH 3 1700 lo0
192.168.1 192.168.1.155 UC 1 0 net0
192.168.1.155 127.0.0.1 UGHS 0 18 lo0
209.98.16.1 192.168.1.8 UGHD 0 7 net0
224 192.168.1.155 UCS 0 0 net0
As I ping the machines on 10.xx net they are added to the routing table
with a 'D' flag indicating the route was added as the result of a
redirect message. I this part of my problem?
Thanks for any help,
Tony
Mike Brown
You may have guessed the problem, try a
route add -net 10 192.168.1.1
to see if it helps. I have normally added
each network by itself, ie
route add -net 10.11 192.168.1.1
route add -net 10.13 192.168.1.1
route add -net 10.14 192.168.1.1
....
Mike
--
Michael Brown
The Kingsway Group
Tony
> Tony wrote:
>
>>Sorry for another question like this. But my 'ping' is slow! Ya Ya I
>>know, not this again. But I've been reading for days on deja and I
>>haven't found a solution yet. Thanks for your patience.
>>
>>We have our OpenServer 5.06a box connected to a large network at the
>>customer site. They are using a Windows 2000 box as the DNS server and
>>DHCP server.
>>
>>A series of machines at 192.168.1.xxx are assigned a fixed address which
>>includes our SCO server.
>>All other machines are assigned addresses by the DHCP server onto an
>>network of 10.14.100.xxx.
>>
>>If I ping a machine using hostname on 192.168.1.xxx it works great.
>>If I ping a machine using hostname on 10.14.100.xxx it takes forever!
>>
>>Here is an exampe output of 'ping hostname'
>>The response takes several seconds before it is displayed.
>>
>>============================================================================================
>>
>>root@scobox /etc# ping hostname
>>PING hostname.customerdomain.com (10.14.100.17): 56 data bytes
>>64 bytes from 10.14.100.17 (10.14.100.17): icmp_seq=0 ttl=127 time=0.754 ms
>>64 bytes from 10.14.100.17 (10.14.100.17): icmp_seq=1 ttl=127
>>time=14869.597 ms
>>64 bytes from 10.14.100.17 (10.14.100.17): icmp_seq=2 ttl=127
>>time=13869.699 ms
>>--- hostname.customerdomain.com ping statistics ---
>>17 packets transmitted, 17 packets received, 0% packet loss
>>round-trip min/avg/max = 0.754/7037.584/14869.597 ms
>>
>>=========================================================================================
>>
>>If I use 'ping -n hostname' it is fast as expected.
>>
>>Every thing I have read from the group indicates this is a DNS problem.
>> But if I try 'nslookup hostname' it responds with an address
>>immediately. I was under the impression that this would be a good test
>>of the DNS.
>>
>>My resolv.conf files is this:
>>hostresorder local bind
>>domain customerdomain.com
>>nameserver 192.168.1.122
>>
>>Could it be an issue with their router? Or is there something about
>>their DNS which is not set correctly. I would love to tell them whats
>>wrong with their network but I want to make sure that something isn't ME!
>>As I ping the machines on 10.xx net they are added to the routing table
>>with a 'D' flag indicating the route was added as the result of a
>>redirect message. I this part of my problem?
>>
>>Thanks for any help,
>>Tony
>
>
> You may have guessed the problem, try a
>
> route add -net 10 192.168.1.1
>
> to see if it helps. I have normally added
> each network by itself, ie
>
> route add -net 10.11 192.168.1.1
> route add -net 10.13 192.168.1.1
> route add -net 10.14 192.168.1.1
> ....
>
> Mike
>
Thanks for the input Mike, but that didn't seem to solve it. One of the
machines I am trying to ping is at address 10.14.100.17. I tried adding
the entries to the route table as seen below, one at a time. Although
the ping works eventually it still takes seconds to respond.
root@scobox /etc# netstat -rn
Routing tables
Destination Gateway Flags Refs Use Interface
default 192.168.1.1 UGS 1 104 net0
10 192.168.1.1 UGS 0 20 net0
10.14 192.168.1.1 UGS 0 19 net0
10.14.100.17 192.168.1.1 UGHS 0 17 net0
127.0.0.1 127.0.0.1 UH 2 40 lo0
192.168.0.255 192.168.1.8 UGHD 1 99 net0
192.168.1 192.168.1.155 UC 1 0 net0
192.168.1.155 127.0.0.1 UGHS 4 26 lo0
224 192.168.1.155 UCS 0 0 net0
root@scobox /etc#
One other thing I am not familiar with which I am going to read up on
today is the WINS resolution on a Windows DNS server. Would this have
anything to do with it?
Thanks again,
Tony
Dan
"Tony" <to...@tabletrac.com> wrote in message
news:3D7756BE...@tabletrac.com...
> Mike Brown wrote:
> > Tony wrote:
> >
>
I notice you are still having troubles. I would suggest checking on the
router area.
My first test would be a traceroute, but I am not sure if that is available
on SCO.
That would be how I would see that, do to improper configuration, I was
taking the long route. I had one case where it took 30 hops to get to a
server in the same computer room.
Another trick I use is to do ftp's between the hosts. Take the same file
and ftp it each way and compare the the rates given at the end of the ftp.
I also like to turn on hash. If flow of pound signs is not even, then you
have collision or auto bandwidth problems.
Mike Brown
You are suffering from a problem that I have seen and raise with
the OSR5 people at forum. If you have a 10.14 route then you
should not get a 10.14.100.17 route also! Try setting up the
required static route ( you can edit /etc/tcp and add lines ),
then reboot and retest. I have noticed that when OSR5 gets
twisted up in the routing table then delays occur.
Bill Vermillion
It would more likely be the auto-negotiation on FDX vs HDX.
You can transmit that way but you get failures because one side is
running a collision protocol - the HDX side - while the FDX doesn't
using a collision protocol as it has separate line pairs for TX and
RX. If by bandwidth you mean speed - then you really won't get
much there because the protocols on the line are so differernt.
>
--
Bill Vermillion - bv @ wjv . com
Bela Lubkin
> Sorry for another question like this. But my 'ping' is slow! Ya Ya I
> know, not this again. But I've been reading for days on deja and I
> haven't found a solution yet. Thanks for your patience.
>
> We have our OpenServer 5.06a box connected to a large network at the
> customer site. They are using a Windows 2000 box as the DNS server and
> DHCP server.
>
> A series of machines at 192.168.1.xxx are assigned a fixed address which
> includes our SCO server.
> All other machines are assigned addresses by the DHCP server onto an
> network of 10.14.100.xxx.
>
> If I ping a machine using hostname on 192.168.1.xxx it works great.
> If I ping a machine using hostname on 10.14.100.xxx it takes forever!
>
> Here is an exampe output of 'ping hostname'
> The response takes several seconds before it is displayed.
>
> ============================================================================================
>
> root@scobox /etc# ping hostname
> PING hostname.customerdomain.com (10.14.100.17): 56 data bytes
> 64 bytes from 10.14.100.17 (10.14.100.17): icmp_seq=0 ttl=127 time=0.754 ms
> 64 bytes from 10.14.100.17 (10.14.100.17): icmp_seq=1 ttl=127 time=14869.597 ms
> 64 bytes from 10.14.100.17 (10.14.100.17): icmp_seq=2 ttl=127 time=13869.699 ms
...
> 64 bytes from 10.14.100.17 (10.14.100.17): icmp_seq=15 ttl=127 time=1107.100 ms
> 64 bytes from 10.14.100.17 (10.14.100.17): icmp_seq=16 ttl=127 time=107.208 ms
>
> --- hostname.customerdomain.com ping statistics ---
> 17 packets transmitted, 17 packets received, 0% packet loss
> round-trip min/avg/max = 0.754/7037.584/14869.597 ms
>
> =========================================================================================
>
> If I use 'ping -n hostname' it is fast as expected.
>
> Every thing I have read from the group indicates this is a DNS problem.
> But if I try 'nslookup hostname' it responds with an address
> immediately. I was under the impression that this would be a good test
> of the DNS.
That's a reasonable smoke-test of forward DNS resolution. Your problem
is with reverse DNS resolution. `ping` is trying to translate the
numeric IP address, 10.14.100.17, to a name. The DNS server is
responding slowly to this request.
ping works by having two separate logical threads of execution. One
sends out periodic packets; the other receives the responses and prints
them out. What's happening here is that the reader thread is being
blocked for a long time by DNS, even though the writer is still sending
a new packet every second. Responses #1 through 15 were probably
received in perfectly normal amounts of time, but they didn't get _read_
until the delayed DNS response to packet #1 was finished.
Notice how the times step down by about 1 second per packet: this is
because, when the DNS response was finally received, the rest of the
queued responses were absorbed quickly.
It's a bit odd that your DNS server happily responded immediately to the
_first_ query about 10.14.100.17 (packet #0), and slowly to the second.
But that's up to the DNS server.
If you had given exactly the same symptoms, but said that the behavior
was the _same_ with `ping -n`, I would give a radically different
diagnosis. In that case I would say that an intermediate router between
you and 10.14.100.17 was experiencing intermittent line drops. Suppose
there are 7 hops between you and 10.14.100.17, and that the connection
between hops 3 & 4 is a dialup modem. If the modem hung up, machine #3
would redial machine #4, which would take several seconds. Depending on
its IP-over-modem implementation, it could choose to either drop packets
received during the down time, or queue them. If you saw the results
you showed, it would tell you that machine #3 was queuing the packets
while redialing. Then it send them all on to machine #4, so on down the
line to 10.14.100.17, and back to you; the responses all arrived in a
burst at about the same time.
This behavior would happen whether or not you were having ping do
reverse-DNS lookups, so it isn't what's going on in your case. The
scenario with the downed intermediate route would probably also have one
other difference: the burst of responses when the line came back up
would probably be somewhat out of sequence. That can't happen with the
DNS delay scenario since all of the received packets are already sitting
on your machine, waiting to be read by ping, in an ordered queue.
>Bela<