LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: Need help with a redirect hack

To: "LinuxVirtualServer.org users mailing list." <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: Need help with a redirect hack
From: Reid Sutherland <mofino@xxxxxxxxx>
Date: Thu, 4 Aug 2005 16:23:44 -0400
On 8/4/05, Horms <horms@xxxxxxxxxxxx> wrote:
> 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.

Yeah.  I'm starting to think it's not really possible.  I've sort've
fiddled with everything and came out empty handed.

It was worth the effort though, learnt quite a bit about various
netfilter modules :)

Take care,

-reid

<Prev in Thread] Current Thread [Next in Thread>