On Wed, Aug 27, 2003 at 12:31:46PM +0300, Julian Anastasov wrote:
>
> Hello,
>
> On Wed, 27 Aug 2003, Horms wrote:
>
> > > hook. IIRC, fwmark is present in PRE_ROUTING but such move can
> > > create some compatibility problems, are all we ready for this?
> >
> > My main concern would be breaking compatibility - breaking people's
> > setups won't make friends with anyone.
>
> Agreed. Due to such reasons our development is simply
> stopped. We can not do any progress in the kernel area (we are
> limited by netfilter hooks, we will need extension to the routing).
> But there must be a way to move forward.
But would it break anything? I am not convinced either way.
> > I am interested to hear what sort of problems you think might occur?
>
> For example, IPVS will not require local VIPs anymore (you
> still can add VIPs, of course). This will solve the problem of
> balancing forwarded traffic without the need of local delivery
> hacks.
Of course, that it the reason I suggetsted it in the first place.
> If IPVS likes the packets (according to the virtual server
> definition) he can grab them, else they go in their own way.
> I do not see other gains for the user settings by removing the
> local delivery.
Nor do I. But I also don't see any losses.
> As for the kernel part, IPVS will be able to avoid
> LOCAL_IN->LOCAL_OUT paths and to use forwarding. There are also
> ways for optimizing the forwarding speed and to properly route+SNAT
> in inout direction (multiple ISPs).
This would seem to also be a gain, though possibly negligable.
> > What minor changes to the kernel would you advocate?
>
> That is the problem :) No minor changes, only major :)
> But I have to check the posibilities if we move to pre_routing
> because there we will not need so many major changes.
>
> > It might be easiest to only move handling of fwmark virtual services
> > to
> > prerouting. But this has the disadvantage that it would produce
> > slightly different behaviour depending on which you used, and
> > probably
> > involve code duplication and possible (slight) inefficiencies.
>
> I'll try to refresh my TODO document, may be in the
> weekend, then we can discuss them again. I hope this is the only
> way we can move forward, it is probably a Linux 2.7 work.
I look forward to seeing the list and discussing this from there.
But I am still not clear on what if any changes you think are needed
to allow LVS's in-hook to move to prerouting.
--
Horms
|