> It sounds like it is a networking issue. If it didn't have the correct > gateway it makes sense that you would be able to access everything locally > on your subnet, but when it comes time to get out of your subnet it > wouldn't know the route to get there. Other possibilities are your > firewall/router just doesn't allow your IP outbound or there is a NAT > mis-configuration. Does your server require a static 1-to-1 NAT or should > it fall into a pool? The following is why I don't think its a firewall issue. server a.com is broken. server b.com is not. If I change the name and IP address of a.com to match b.com, remove b.com from the network, and reboot a.com (as b.com), it still has the same DNS problem. If the firewall was looking to reject a.com traffic, why won't it work when it is set up like b.com? Is it possible that this is some bizarre SELinux problem? Perhaps the resolv.conf or nsswitch.conf file has the wrong context, or something? I've seen nothing in the logs that would inicate that, but who knows. I'm not at work right now, so I can't check it until tomorrow. This is the most bizarre problem I've ever encountered. > > > > > ----- "Bill Tangren" <bjt@xxxxxxxxxxxxx> 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. >> >> >> > >> > Ian >> > >> > ----- "Bill Tangren" <bjt@xxxxxxxxxxxxx> wrote: >> >> > On Dec 13, 2007 8:02 AM, Bill Tangren <bjt@xxxxxxxxxxxxx> 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@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
