[Novalug] I don't understand basic routing
larkoc at iges.org
Wed Feb 17 14:43:51 EST 2010
Patrick R McDonald wrote:
Megan's response to Patrick McDonald's comments below:
> On Wed, Feb 17, 2010 at 02:10:46PM -0500, Megan Larko wrote:
>> Greetings Fellow LUGgers!
>> I am not understanding some basic TCP/IP routing concepts here.
>> I have two linux CentOS 5.3 boxes. Box A is dual-homed with both a public IP and a non-routable
>> private IP set-up. Box B has a non-routable IP only for net access.
>> Box A seems to be completely fine and behaves as expected (ping, traceroute, route, netstat all
>> show expected parameters).
>> Box B is puzzling me. It is directed to Box A as its UG (universal gateway). It communicates fine
>> with the local private network. But now I get confused. Box B uses private interface (if) on Box
>> A in /etc/resolv.conf as a nameserver after /etc/hosts. The ifcfg-eth0 sets Box A private (if) as
>> the gw IP and a netmask of 255.255.0.0. On Box B I am able to resolve hostnames not in my Box B
>> /etc/hosts, nor on Box A /etc/hosts, but hostnames that are registered in the "wild". From Box B I
>> can initiate a ping to such an hostname and the correct IP number is resolved/found. I cannot ping
>> or traceroute these "wild" hostnames because the Destination Host is unreachable. These same
>> resolved hostnames can be successfully pinged or tracerouted from Box A. This is okay. I don't
>> understand it fully, but it is okay.
>> The dual-homed Box A can get to other public IPs in our company's local network. Box A can ping,
>> traceroute (one hop) and ssh to a public IP in our company namespace. Box B cannot ping, traceroute
>> nor ssh to any IP other than the similar IPs in the private, non-routable IP range. So Box B can
>> resolve and lookup, but not access boxes not in its own IP range.
>> I don't understand how the Box A gateway configured on Box B can resolve even "wild" IPs and
>> hostnames and yet have no route/network access to those names it can successfully resolve. I would
>> like to allow Box B to have limited access to other boxes in our companies network (probably via
>> public interface as the private ones are very different---10.0.x.y compared with 172.16.x.y) to
>> place files (outgoing activity from Box B) onto our company boxes with public registered IP numbers.
>> Is this possible? I'm thinking of MASQUERADE or FORWARD in iptables on Box A, but I was
>> wondering if a "route add -net..." on Box B might be a better choice.
>> Reading through "man route" has not cleared this up for me. Other recommended search strings to
>> learn about this would be appreciated.
> I don't believe the problem is with Box B. I think the problem may lie
> with Box A. When you run the following command on Box A, what is
> # cat /proc/sys/net/ipv4/ip_forward
> Most likely this returns a 0. This means Box A is not setup to route IP
> packets. You can set this permanently to 1 in your sysctl.conf file.
The Box A already has a 1 set in sysctl.conf and is properly echoed as 1 in the "cat" line above.
> Next, on Box B, run the following command
> # netstat -nr
> This should display the interface from which your packets leave to get
> to various networks. You are looking for a line which begins with
> 0.0.0.0. This line will specify the default interface to which packets
> will head unless another route is specified. The IP address in the
> second column of this line should be the IP of the internal interface of
> Box A.
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.64.0 0.0.0.0 255.255.255.0 U 0 0 0 ib0
184.108.40.206 0.0.0.0 255.255.255.0 U 0 0 0 eth0
220.127.116.11 172.16.1.1 255.255.255.0 UG 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 ib0
172.16.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
0.0.0.0 172.16.1.1 0.0.0.0 UG 0 0 0 eth0
Note: The ib0 interface goes to Lustre data disks (bricks). The boxes to which I wish to copy/ssh
files are 18.104.22.168 and 22.214.171.124.
This set-up is what I had prior to my first email message about my not understanding basic routing.
I did not change anything per Patrick's suggestions as those conditions already exist.
(who will be looking for help on "caching name server"--thanks for the phrase)
> Let me know if this helps.
More information about the Novalug