|
Apologies in advance for the long email, but I have a habit of confusing
people when I try to make compact descriptions. :) I have Red Hat 7.3
servers, all with Red Hat's stock i686 2.4.18 kernel RPMs. The provided
kernel has ipvs modules enabled, and includes source for ipvsadm 1.20,
which I compiled and installed on the director.
# ipvsadm -v
ipvsadm v1.20 2001/11/04 (compiled with popt and IPVS v0.9.7)
The director is multihomed (public interface and 192.168.10.0/24
interface) and running NAT rules. The 192.168.10.0/24 interface on the
director is the default gateway for all the machines on the
192.168.10.0/24 subnet. I am using round robin scheduling to load
balance a service between two real servers on the 192.168.10/24 subnet.
Enter a 4th machine, also on the 192.168.10/24 subnet (it actually has
two physical interfaces on that subnet, in case that's important later).
I have a service that the two real servers need to talk to. The catch is
that the service gives them the public FQDN. I have DNS setup so that a
DNS query from the 192.168.10.0/24 subnet will return a 192.168.10.0/24
IP (if applicable), rather than the public IP. So that resolves to the
192.168.10.0/24 IP of the director. I thought I could have the same NAT
rules for the internal IP as I do for the public IP, but I'm getting hit
by the ARP problem. (client sends to director, which NAT's packet to
realserver, which responds directly to client. Client drops packets
because it doesn't now about an ESTABLISHED connection between client
and realserver).
So I tried changing the interface on the client to use a 192.168.20.0/24
IP, and gave the director's 192.168.10.0/24 a secondary IP on the
192.168.20.0/24 subnet too. The realserver still just put the MAC
address of the client's 192.168.20.0/24 interface in the ARP table and
sent reply packets directly to it. I tried changing the client's
interface to having just a 192.168.20.0/24 IP, but that didn't help. I
saw some stuff about 'echo 1 > /proc/sys/net/ipv4/eth0/arp_filter' to
disable ARP requests in certain situations, and thought it applied to my
scenario, but that didn't seem to help.
I read in the HOWTO that adding a second NIC doesn't fix the ARP problem
for 2.4 kernels, and I guess this is basically what I was trying to do,
albeit with virtual interfaces at first.
--
; Justin Georgeson
; http://www.lopht.net
; mailto:jgeorgeson@xxxxxxxxx
; "Free the mallocs, delete the news"
|
