Shalom!
In, perhaps, a misguided desire for elegance, I moved our DNS server from an aged and infirm host onto our existing file/mail server (Dell PowerEdge/2450 w/dual PIII/866 CPUs and 2GB RAM, running Fedora Core 1 w/all updates). Since the DNS server sat on a different subnet, I added a second NIC to the file/mail server and created the appropriate files in /etc/sysconfig/network-scripts (ifcfg-eth1 and route-eth{0,1}).
"route -n" shows:
Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 128.139.197.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 128.139.206.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 128.139.197.16 0.0.0.0 UG 0 0 0 eth1 0.0.0.0 128.139.206.1 0.0.0.0 UG 1 0 0 eth0
The problem is that although packets received from the two subnets arrive through the corresponding device, *packets sent to a host on a subnet other than 128.139.197.0 exit through eth1.*
Running "ping 128.139.206.12" from a host on the 128.139.206.0 subnet shows that packets exit via eth1, rather than via eth0:
root@efes network-scripts# tcpdump -i eth1 host horen.tau.ac.il tcpdump: listening on eth1 11:54:38.192269 efes.iucc.ac.il > horen.tau.ac.il: icmp: echo reply 11:54:39.202538 efes.iucc.ac.il > horen.tau.ac.il: icmp: echo reply 11:54:40.212855 efes.iucc.ac.il > horen.tau.ac.il: icmp: echo reply
I understand that this is because the metric for eth1 is "0", while the metric for eth1 is "1". If I understand correctly, changing the metric for eth0 to "0" would mean that every packet would be sent to *both* interfaces, giving me a 50% packet loss.
Is there a way to configure routing on this server so that a packet's source-address is "honored" by the system when responding?
worst-case, I'll cobble together a separate DNS server from an unused PIII/500...
TIA!
Jonathan B. Horen wrote:
Is there a way to configure routing on this server so that a packet's source-address is "honored" by the system when responding?
There are some details lacking, such as what are the addresses of the workstations. In particular the workstation that was pinging in your example.
Here is what I think is happening: The metric field is ignored, but when routes handle duplicate destinations (in this case default or 0/0) the last one added prevails in my experience.
If the workstations were local the interface device routes should prevail. So I am guessing that you pinged the name server address from a different subnet from any in your route table, and the last interface brought up's associated route-ethx defined route is how the response was sent.
Try this experiment: ifdown eth0 ifup eth0
I think you will see all packets to non-local subnets go through eth0 via 128.139.197.16.
There is no harm in either configuration unless you believe one default route is a faster way to get there, or not all the same subnets are accessible via either gateway.
If the former is true, then remove the route-ethx file for the slow gateway route. If the latter is true, then you need to put more specific routes in each of the route-ethx files, not simply designate both of them as default.
There are routing daemons available if there are routing protocols supported by your gateways through which the server can learn the most effective route to a destination. See the quagga package included in fedora core.
-
Christopher K. Johnson -
Jonathan B. Horen