|
On Thu, Aug 04, 2005 at 04:23:44PM -0400, Reid Sutherland wrote:
> 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 :)
Same here. Though I'd like to probe a bit deeper and find
a mechanism that allows members of the cluster, both real-servers
and linux-directors, to access the cluster VIP in LVS-DR.
That would likely work for LVS-TUN as well (though thats a bit
of a call given that we don't even have a machanism), but
LVS-NAT is a bit of a basket case.
--
Horms
|
