Check default route
# ip route list
10.212.166.0/24 dev eth0 proto kernel scope link src 10.212.166.26
169.254.0.0/16 dev eth0 scope link
default via 10.212.166.1 dev eth0 <----!!!!
correct if necessary.
Check for UDP connectivity
# nmap -PU -p53 DNS.SERVER.IP.ADDRESS
# traceroute -U DNS.SERVER.IP.ADDRESS
OK, this is what is produced on the server that works:
*****
[root@mach2 X11]# ip route list
169.254.0.0/16 dev eth0 scope link
10.0.0.0/8 dev eth0 proto kernel scope link src 10.1.5.58
default via 10.1.1.2 dev eth0
So mach2:eth0 has an IP of 10.1.5.58, right?
[root@mach2 ~]# nmap -PU -p53 10.1.1.6
Starting nmap 3.70 ( http://www.insecure.org/nmap/ ) at 2007-12-12 15:33
EST
Note: Host seems down. If it is really up, but blocking our ping probes,
try -P0
Nmap run completed -- 1 IP address (0 hosts up) scanned in 2.054 seconds
[root@mach2 ~]# nmap -PU -p53 10.1.1.46
Starting nmap 3.70 ( http://www.insecure.org/nmap/ ) at 2007-12-12 15:33
EST
Interesting ports on aurora.timenet.usno.navy.mil (10.1.1.46):
PORT STATE SERVICE
53/tcp open domain
MAC Address: 00:18:8B:38:28:97 (Unknown)
Nmap run completed -- 1 IP address (1 host up) scanned in 0.295 seconds
[root@mach2 ~]#
*****
The server that doesn't looks like this:
*****
[root@aa-cvs ~]# ip route list
169.254.0.0/16 dev eth0 scope link
10.0.0.0/8 dev eth0 proto kernel scope link src 10.1.5.58
default via 10.1.1.2 dev eth0
and aa-cvs:eth0 also has an IP address of 10.1.5.58, right?
See the problem yet? Same IP address on two nodes?
[root@aa-cvs ~]# nmap -PU -p53 10.1.1.6
Starting nmap 3.70 ( http://www.insecure.org/nmap/ ) at 2007-12-12 15:33
EST
Note: Host seems down. If it is really up, but blocking our ping probes,
try -P0
Nmap run completed -- 1 IP address (0 hosts up) scanned in 2.054 seconds
[root@aa-cvs ~]# nmap -PU -p53 10.1.1.46
Starting nmap 3.70 ( http://www.insecure.org/nmap/ ) at 2007-12-12 15:33
EST
Note: Host seems down. If it is really up, but blocking our ping probes,
try -P0
Nmap run completed -- 1 IP address (0 hosts up) scanned in 2.049 seconds
[root@aa-cvs ~]#
*****
The difference
If either works then check for an access list on your DNS. Usually in
named.conf
I am having this problem even if I change the name and IP number of the
broken server to the unbroken one. Same problem.
I have now reinstalled the OS on the broken server, and it STILL is having
problems. It has to be a hardware problem, but I can't figure out what it
could be.
Try a different switch port if possible.
I'll have to talk to the network guys about this.
--
Stephen Carville <scarville@landam.com>
--
Stephen Carville <scarville@landam.com>
Systems Engineer
Land America
1.626.667.1450 X1326
################################################## ###################
Ad eundum quo nemo ante iit.
--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
12-12-2007, 08:30 PM
"Bill Tangren"
queer dns access problem
> Bill Tangren wrote:
>>>> -----Original Message-----
>>> Some ideas:
>>>
>>> Turn off firewalling if possible.
>>>
>>> Check default route
>>> # ip route list
>>> 10.212.166.0/24 dev eth0 proto kernel scope link src 10.212.166.26
>>> 169.254.0.0/16 dev eth0 scope link
>>> default via 10.212.166.1 dev eth0 <----!!!!
>>>
>>> correct if necessary.
>>>
>>> Check for UDP connectivity
>>>
>>> # nmap -PU -p53 DNS.SERVER.IP.ADDRESS
>>>
>>> # traceroute -U DNS.SERVER.IP.ADDRESS
>>
>>
>> OK, this is what is produced on the server that works:
>>
>> *****
>> [root@mach2 X11]# ip route list
>> 169.254.0.0/16 dev eth0 scope link
>> 10.0.0.0/8 dev eth0 proto kernel scope link src 10.1.5.58
>> default via 10.1.1.2 dev eth0
>
> So mach2:eth0 has an IP of 10.1.5.58, right?
Correct.
>
>> [root@mach2 ~]# nmap -PU -p53 10.1.1.6
>> Starting nmap 3.70 ( http://www.insecure.org/nmap/ ) at 2007-12-12 15:33
>> EST
>> Note: Host seems down. If it is really up, but blocking our ping probes,
>> try -P0
>> Nmap run completed -- 1 IP address (0 hosts up) scanned in 2.054 seconds
>>
>> [root@mach2 ~]# nmap -PU -p53 10.1.1.46
>> Starting nmap 3.70 ( http://www.insecure.org/nmap/ ) at 2007-12-12 15:33
>> EST
>> Interesting ports on aurora.timenet.usno.navy.mil (10.1.1.46):
>> PORT STATE SERVICE
>> 53/tcp open domain
>> MAC Address: 00:18:8B:38:28:97 (Unknown)
>>
>> Nmap run completed -- 1 IP address (1 host up) scanned in 0.295 seconds
>>
>> [root@mach2 ~]#
>> *****
>>
>> The server that doesn't looks like this:
>>
>> *****
>> [root@aa-cvs ~]# ip route list
>> 169.254.0.0/16 dev eth0 scope link
>> 10.0.0.0/8 dev eth0 proto kernel scope link src 10.1.5.58
>> default via 10.1.1.2 dev eth0
>
> and aa-cvs:eth0 also has an IP address of 10.1.5.58, right?
>
> See the problem yet? Same IP address on two nodes?
Sorry. That's a cut and paste error. It is actually 10.1.5.94. I just
rechecked.
--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
12-12-2007, 08:53 PM
Stephen Carville
queer dns access problem
Bill Tangren wrote:
Bill Tangren wrote:
-----Original Message-----
Some ideas:
Turn off firewalling if possible.
Check default route
# ip route list
10.212.166.0/24 dev eth0 proto kernel scope link src 10.212.166.26
169.254.0.0/16 dev eth0 scope link
default via 10.212.166.1 dev eth0 <----!!!!
correct if necessary.
Check for UDP connectivity
# nmap -PU -p53 DNS.SERVER.IP.ADDRESS
# traceroute -U DNS.SERVER.IP.ADDRESS
OK, this is what is produced on the server that works:
*****
[root@mach2 X11]# ip route list
169.254.0.0/16 dev eth0 scope link
10.0.0.0/8 dev eth0 proto kernel scope link src 10.1.5.58
default via 10.1.1.2 dev eth0
EST
Interesting ports on aurora.timenet.usno.navy.mil (10.1.1.46):
PORT STATE SERVICE
53/tcp open domain
MAC Address: 00:18:8B:38:28:97 (Unknown)
Nmap run completed -- 1 IP address (1 host up) scanned in 0.295 seconds
[root@mach2 ~]#
*****
The server that doesn't looks like this:
*****
[root@aa-cvs ~]# ip route list
169.254.0.0/16 dev eth0 scope link
10.0.0.0/8 dev eth0 proto kernel scope link src 10.1.5.58
default via 10.1.1.2 dev eth0
and aa-cvs:eth0 also has an IP address of 10.1.5.58, right?
See the problem yet? Same IP address on two nodes?
Sorry. That's a cut and paste error. It is actually 10.1.5.94. I just
rechecked.
OK. Is the /8 netmask a cut and paste error too?
Your trouble could be a routing issue: 10.1.5.58/8 and 10.1.1.46/8 are
on the same subnet as far as the network layer is concerned so there is
no reason to go to the default route. Thats why I asked for a
traceroute too -- or mtr if you have it installed and it will work.
# mtr -rnc 10 DNS.SERVER.IP.ADDRESS
What netmask is the firewall using for the interface?
--
Stephen Carville <scarville@landam.com>
Systems Engineer
Land America
1.626.667.1450 X1326
################################################## ###################
Ad eundum quo nemo ante iit.
--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
12-13-2007, 03:02 PM
"Bill Tangren"
queer dns access problem
> Bill Tangren wrote:
>>> Bill Tangren wrote:
>>>>>> -----Original Message-----
>>>>> Some ideas:
>>>>>
>>>>> Turn off firewalling if possible.
>>>>>
>>>>> Check default route
>>>>> # ip route list
>>>>> 10.212.166.0/24 dev eth0 proto kernel scope link src 10.212.166.26
>>>>> 169.254.0.0/16 dev eth0 scope link
>>>>> default via 10.212.166.1 dev eth0 <----!!!!
>>>>>
>>>>> correct if necessary.
>>>>>
>>>>> Check for UDP connectivity
>>>>>
>>>>> # nmap -PU -p53 DNS.SERVER.IP.ADDRESS
>>>>>
>>>>> # traceroute -U DNS.SERVER.IP.ADDRESS
>>>>
>>>> OK, this is what is produced on the server that works:
>>>>
>>>> *****
>>>> [root@mach2 X11]# ip route list
>>>> 169.254.0.0/16 dev eth0 scope link
>>>> 10.0.0.0/8 dev eth0 proto kernel scope link src 10.1.5.58
>>>> default via 10.1.1.2 dev eth0
>>> So mach2:eth0 has an IP of 10.1.5.58, right?
>>
>>
>> Correct.
>>
>>
>>>> [root@mach2 ~]# nmap -PU -p53 10.1.1.6
>>>> Starting nmap 3.70 ( http://www.insecure.org/nmap/ ) at 2007-12-12
>> 15:33
>>>> EST
>>>> Note: Host seems down. If it is really up, but blocking our ping
>> probes,
>>>> try -P0
>>>> Nmap run completed -- 1 IP address (0 hosts up) scanned in 2.054
>> seconds
>>>> [root@mach2 ~]# nmap -PU -p53 10.1.1.46
>>>> Starting nmap 3.70 ( http://www.insecure.org/nmap/ ) at 2007-12-12
>> 15:33
>>>> EST
>>>> Interesting ports on aurora.timenet.usno.navy.mil (10.1.1.46):
>>>> PORT STATE SERVICE
>>>> 53/tcp open domain
>>>> MAC Address: 00:18:8B:38:28:97 (Unknown)
>>>>
>>>> Nmap run completed -- 1 IP address (1 host up) scanned in 0.295
>>>> seconds
>>>>
>>>> [root@mach2 ~]#
>>>> *****
>>>>
>>>> The server that doesn't looks like this:
>>>>
>>>> *****
>>>> [root@aa-cvs ~]# ip route list
>>>> 169.254.0.0/16 dev eth0 scope link
>>>> 10.0.0.0/8 dev eth0 proto kernel scope link src 10.1.5.58
>>>> default via 10.1.1.2 dev eth0
>>> and aa-cvs:eth0 also has an IP address of 10.1.5.58, right?
>>>
>>> See the problem yet? Same IP address on two nodes?
>>
>>
>> Sorry. That's a cut and paste error. It is actually 10.1.5.94. I just
>> rechecked.
>
> OK. Is the /8 netmask a cut and paste error too?
No, it is correct.
>
> Your trouble could be a routing issue: 10.1.5.58/8 and 10.1.1.46/8 are
> on the same subnet as far as the network layer is concerned so there is
> no reason to go to the default route. Thats why I asked for a
> traceroute too -- or mtr if you have it installed and it will work.
>
> # mtr -rnc 10 DNS.SERVER.IP.ADDRESS
>
> What netmask is the firewall using for the interface?
When the network guy comes in this afternoon, I'll ask. This still doesn't
explain why it works for one machine, but not the other, when both are set
the same.
--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
12-15-2007, 03:47 PM
"Stephen Carville"
queer dns access problem
On Dec 13, 2007 8:02 AM, Bill Tangren <bjt@usno.navy.mil> wrote:
> >
> > OK. Is the /8 netmask a cut and paste error too?
>
> No, it is correct.
>
> >
> > Your trouble could be a routing issue: 10.1.5.58/8 and 10.1.1.46/8 are
> > on the same subnet as far as the network layer is concerned so there is
> > no reason to go to the default route. Thats why I asked for a
> > traceroute too -- or mtr if you have it installed and it will work.
> >
> > # mtr -rnc 10 DNS.SERVER.IP.ADDRESS
> >
> > What netmask is the firewall using for the interface?
>
>
> When the network guy comes in this afternoon, I'll ask. This still doesn't
> explain why it works for one machine, but not the other, when both are set
> the same.
I am assuming you've done the usual stuff
double checked /etc/resolv.conf
checked /etc/nsswitch.conf
Pinged the default gateway.
Checked the network cabling back to the switch.
Checked the patch cable.
ifconfig to make sure the interface is actually up.
ethtool to check that speed and duplex are as expected.
Can't think of anything else offhand.
--
Stephen Carville
--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
12-15-2007, 08:46 PM
"Bill Tangren"
queer dns access problem
> On Dec 13, 2007 8:02 AM, Bill Tangren <bjt@usno.navy.mil> wrote:
>
>> >
>> > OK. Is the /8 netmask a cut and paste error too?
>>
>> No, it is correct.
>>
>> >
>> > Your trouble could be a routing issue: 10.1.5.58/8 and 10.1.1.46/8 are
>> > on the same subnet as far as the network layer is concerned so there
>> is
>> > no reason to go to the default route. Thats why I asked for a
>> > traceroute too -- or mtr if you have it installed and it will work.
>> >
>> > # mtr -rnc 10 DNS.SERVER.IP.ADDRESS
>> >
>> > What netmask is the firewall using for the interface?
>>
>>
>> When the network guy comes in this afternoon, I'll ask. This still
>> doesn't
>> explain why it works for one machine, but not the other, when both are
>> set
>> the same.
>
> I am assuming you've done the usual stuff
>
> double checked /etc/resolv.conf
>
> checked /etc/nsswitch.conf
Did these two.
>
> Pinged the default gateway.
>
Ping is shut off on the gateway. I'll ask the firewall guy to turn it on
long enough to test this.
> Checked the network cabling back to the switch.
Yes, other computers work just fine with this cabling.
>
> Checked the patch cable.
>
Patch cable? What is that?
> ifconfig to make sure the interface is actually up.
>
yep.
> ethtool to check that speed and duplex are as expected.
>
Didn't think to do this. Will try it on Monday.
> Can't think of anything else offhand.
>
Thanks for the help.
> --
> Stephen Carville
>
--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
01-03-2008, 07:10 PM
david brett
queer dns access problem
It sounds like a network configuration error somewhere.
Try doing the following:
-traceroute to the DNS server's IP address
-see if you can access anything outside your own network via IP (i.e.
ping http)
-see what is the default route on the box not working (netstat -nr)
These three steps will help point the direction to look next.
Please accept my apology if, jumping in late I have missed any of these
already.
Steve Phillips wrote:
Bill Tangren wrote:
Earlier you said you could ssh out of the broken box. Can you ssh to
the
same segment or to a remote network? Can you log in to the box twice
and
start a packet capture while you attempt a dns lookup? This might
show us
if it is related to firewalling or routing.
If by the same segment, you mean within the same 10.1.5.x domain, I can
ssh if I use the IP number to the same segment (there are errors, but it
ultimately succeeds), but I cannot ssh out of the segment, with or
without
IP number. Also, I can ssh into the broken box from within the segment.
[see below]
there is no 10.1.5.x segment, there is only a 10.x segment. You have
both the working and non working box in the same network. I would be
double checking hte network masks at this point as it does sound like
you have a network masking problem. It may also help to know what boxes
(ip ranges) are working and what ones are not, what exactly are you
testing to.
like
on box a i can ssh to (using ip addresses)
10.1.5.1
10.1.6.1
but not 10.100.6.1
but 202.1.4.5 works as well
on box b all of the above work.
you could also try making your subnet masks smaller, your gateway is in
10.1.1.2 ? try reducing your mask to a /21 (255.255.248.0) and see if
that allows you to reach the dns servers - at this point tho, you should
really be getting a network tech involved or someone who has access to
the dns servers and see how they are configured.
Ian
----- "Bill Tangren" <bjt@usno.navy.mil> wrote:
On Dec 13, 2007 8:02 AM, Bill Tangren <bjt@usno.navy.mil> wrote:
OK. Is the /8 netmask a cut and paste error too?
No, it is correct.
Your trouble could be a routing issue: 10.1.5.58/8 and
10.1.1.46/8 are
on the same subnet as far as the network layer is concerned so
there
is
no reason to go to the default route. Thats why I asked for a
traceroute too -- or mtr if you have it installed and it will
--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
queer dns access problem
