[RFC PATCH] Using LVS as a way to provide load-balanced internet
horms at verge.net.au
Tue Aug 9 07:17:09 BST 2005
On Thu, Aug 04, 2005 at 07:40:01AM +0200, Ludo Stellingwerff wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> Horms wrote:
> > I had a brief look over the patches and the seem ok to me. Except
> > that I am not clear on the motivation of the following hooks.
> > Doesn't this mean that ip_vs_in is registered in three separate
> > places? Is this actually what you need?
> Yes, as I try to redirect forwarded traffic (with addresses not local
> to the director), I need to hook into NF_FORWARD. Ideally this has to
> be a seperate ip_vs_forward_in function, but these patches are a
> concept proof.
> This new ip_vs_forward_in function should be limited to matching fwmarks.
> Flow with these patches:
> incoming packet -> PRE_ROUTING -> FORWARD -> ip_vs_in (returning
> NF_ACCEPT, after changing skb->dst) -> POSTROUTING -> outgoing packet.
> I'm also looking at the possibility of using the iptables REDIRECT
> target to get rid of the forwarding hook and use the normal ip_vs_in,
> but I'm not yet sure this will not mangle the original packet (It
> should not loose the original destination data). At least reinject
> should than be changed to return NF_STOLEN on the INPUT hook, and call
> ip_forward() to get the packet on it's way again.
> The flow for the packet will then become:
> incoming packet -> PRE_ROUTING (REDIRECT)-> INPUT -> ip_vs_in
> (returning NF_STOLEN, sending packet to ip_forward()) -> FORWARD ->
> POSTROUTING -> outgoing packet.
IF you can get that working, that would be nice.
Though I have often wonder4ed about just moving ip_vs_in()
to FORWARD and being done with it. I've tried it breifly
in the past to good effect.
More information about the lvs-users