On Wed, Aug 03, 2005 at 03:52:43PM +0900, Horms wrote:
> On Tue, Aug 02, 2005 at 10:58:28AM -0400, Reid Sutherland wrote:
> > This can be considering an iptables tables question, but I would
> > imagine someone here must have done this before.
> >
> > I'm using LVS TUN. My problem is the "real servers" need to make
> > requests to the cluster themselves. Obviously this doesn't work
> > quite right since it ends up hitting the local host rather than the
> > cluster (since the cluster IP is bound to tunl0).
> >
> > Could someone drop me a hint as to what they did to solve this issue?
> >
> > I've tried all sorts of iptables targets (route, redirect, d/snat) in
> > order to "proxy" the traffic to fake LVS out. Here's a quick example
> > of how I see the solution, but cannot get there.
> >
> > _Director_
> > VIP: .1
> > LVS faker IP: .100
> >
> > _Real Servers_
> > RIP1: .10
> > RIP1: .11
> >
> > I tell the real servers to connect to .100 instead of .1. Then I
> > setup some sort of iptables based proxy on .100 and redirect the
> > traffic back and worth between .100 and .1. The rest of the system
> > that needs the cluster simply hits .1.
> >
> > So has anyone done something this wacky before? Or can suggest
> > something else (please don't say LVS NAT, I'm trying to avoid it)?
>
> Someone asked me about this the other day in the context of LVS-DR,
> which has much the same problem. My immediate thought was to try
> to use policy routing (man ip(8)) but I haven't had a chance to test
> this out.
I had a bit of a poke around with my theory, without much luck.
Though I did make one potentially useful discovery. It is necessary and
sufficient for an address to have a route in the local table to be
treated as local. You can observe this table using "ip route sh table local"
and if you do so you will see that local interfaces are automatically
added there (though if you want to break things you can remove them).
This could be useful as a substitute for adding local addresses,
as simply running "ip route add local $VIP dev local table local"
will see the address treated as if it was attached to a local interface,
assuming that the packet arrives on the box someowhoe (e.g. using
LVS-NAT). However, this would eliminate the need for a local interface
and thus the use of arp_ignore. However, it doesn't negate the need
for arp_announce, so I am not sure how valuable this techinque is.
I found that adding a route like this to any other table did not help.
Thus my idea of having a table that was only acccessed by non-locally
generated packets, which marked packets as being handled local failed.
Actually, I think it worked, but routes in the local table do something
special, and without that the system doesn't work.
--
Horms
|