|
On Thu, 2004-04-08 at 16:55, Joseph Mack wrote:
> It would be better if TP wasn't needed and LVS would accept the
> packet (ipvsadm already knows that packets with a particular fwmark
> are LVS packets), but Julian says there's a bit of work involved and with
> few people using fwmark, there isn't much motivation for
> him to code it up.
That comes as a surprise, because HOWTO.fwmark says:
"Setting up an LVS on fwmarks rather than the VIP is now the method of
choice for anything but a collection of simple one port non-persistent
services."
Thanks very much for your patience in answering. In the end, what works
perfectly is to use the HOWTO.fwmark example of using iptables MARK in
conjunction with ipvsadm fwmark-service, and then using the routing
trick referenced in LVS-HOWTO.routing_tricks.html#routing_and_delivery
to force the box to accept the packets into the stack for marking:
ip rule add prio 100 fwmark 1 table 100
...
ip rule add prio 100 fwmark n table 100
ip route add local 0/0 dev lo table 100
What I needed to do was actually very simple. But because the HOWTO
describes how to accomplish a large number of things on multiple (very
different) kernels in multiple ways, the amount of information is
overwhelming to start with.
> you can put 0.0.0.0 on a NIC. There is a note from Ted Pavlic
> on doing this. I think it's really nasty myself, but you can
> test your setup with it.
In fact, that doesn't work very well if traffic routes back out through
the director. Yes, I know this isn't recommended, but our test
environment demands it, and Ted's trick caused the director to swallow
replies from the realservers[1].
> > Well, I'm building a cluster of transparent TCP proxy hosts. Since the
> > TCP proxies are bidirectional, it's important that all the traffic
> > associated with a single TCP connection pass through a single TCP proxy
> > host.
>
> -dh scheduler? (maybe, not sure that I understand your situation yet).
Hmmm. There's a thought. Maybe I can get away with using the -sh
scheduler on the fore director, and the -dh scheduler on the aft
director. The problem that immediately springs to mind is that the
first packet the aft director needs to load balance is a SYN+ACK, not
the initial SYN.
> > Therefore, not only do I need a load balancer between the proxies and
> > the outside world, but I also need a load balancer between the proxies
> > and the protected, interior hosts. The interior load balancer will have
> > to keep track of the Ethernet source address of the proxy host
> > associated with each tracked connection, so that return traffic from the
> > protected, interior hosts passes out through the correct proxy host.
>
> hmm, hopefully you can solve this with routing (I don't know that you can,
> it's just a hope). In case you need inspiration try
So far no good. :-)
Basically, the aft director needs act as if it's doing this:
a) Track incoming connections.
b) Store with tracked connection entries, the source ethernet address
from which the incoming connection was established.
c) Route outbound traffic to the stored ethernet address for the tracked
connection.
I seem to have run out of Fu. :-)
But thanks so much for your help with the problem I originally posted
on, even though I was asking a question which is answered in the HOWTO
if you just read it enough times.
Ciao,
Sheldon.
[1] At least, I _think_ that's what happened. Maybe the swallowing was
a function of dummying the VIPs on the realservers. I didn't make
notes. :-(
|
