|
Joseph Mack wrote:
Justin Georgeson wrote:
The director is multihomed (public interface and 192.168.10.0/24
interface) and running NAT rules.
.
.
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.
a couple of points
o I don't know if RedHat's ipvsadm/ip_vs works.
o if you are scheduling with LVS-NAT 2.4.x, you do not have NAT rules
on the director
o there is no ARP problem with LVS-NAT
Perhaps I used the wrong terminology then, I was using The "typical
LVS-NAT setup" ASCII drawing at
http://www.linuxvirtualserver.org/Joseph.Mack/mini-HOWTO/LVS-mini-HOWTO.html#lvs_ascii
as a reference, and it labels a machine as the director. The VIP and the
DIP are on separate physical NICs which go to separate physical LANs
(one of which goes to the internet). The client box is on the same
physical LAN as the realservers, and was also configured to be on the
same subnet. I had this set of rules
#external
-A -t $VIP:5222 -s wrr
-a -t $VIP:5222 -r $RIP_1:5222 -m
-a -t $VIP:5222 -r $RIP_2:5222 -m
#internal
-A -t $DIP:5222 -s wrr
-a -t $DIP:5222 -r $RIP_1:5222 -m
-a -t $DIP:5222 -r $RIP_2:5222 -m
So a connection request from the client would go to the DIP and be
relegated wo whichever RIP was next in the rotation. The packets would
readh the RIP, with the CIP as the source IP. The RIP would then send
packets directlry to the CIP, which were dropped because the client was
expecting them from the DIP. If that is not the ARP problem then I was
wrong to label it as such.
Anyway. I fixed it by taking all 192.168.10.0/24 configuration off the
client box and configuring it only with an 192.168.20.0/24 interface. So
the director (still using terminology of the diagram) has both
192.168.10.0/24 and 192.168.20.0/24 subnets configured on one NIC. The
192.168.10.0/24 IP is the DIP, the 192.168.20.0/24 IP isn't used for any
IPVS rules. I had hoped to be able to configure the client to be on both
subnets since it has two physical interfaces, but it just wouldn't work
that way. But it's not a big deal, because the exercise was mostly a
proof-of-concept for my employer.
--
; Justin Georgeson
; http://www.lopht.net
; mailto:jgeorgeson@xxxxxxxxx
; "Free the mallocs, delete the news"
|
