|
Hello,
On Thu, 15 Feb 2001, Henrik Nordstrom wrote:
> > 1. ip_vs_in2 is too small:
> >
> > - packet defragmentation code is missing
> > - who uses NFC_ALTERED ?
>
> Netfilter. The packet is accepted by the hook but altered (mark changed).
It is set to many places but nobody uses it :) Anyway.
> > - protocol header length is not checked
> > - related ICMP is not handled
>
> Oops. Thanks for the feedback. Will fix these.
>
> > 2. Some parts of the code is commented. Is this a part from the
> > proposal?
>
> This because there is a collision between the fwmark based farms and this
> code. We are not using fwmark based farms so I choose to ignore those for
> now.
Not in 0.2.3. You already can use fwmark only for routing (as in
your patch) without touching this code. Some CPU cycles, just like the
other users will spend some cycles in walking ip_vs_in2 without using
it :)
> > 3. LOCAL_IN priority change is not acceptable: this ignores some
> > useful features.
>
> I did not expect you to accept this. It is a short term solution for us,
> until other measurements have been made to integrate iptables rules and ipvs
> to not require a overly complex iptables ruleset in order to accept
> IPVS traffic.
I'm thinking on how we can make LVS more customizable. It looks
like more features will appear that can't be implemented in users space
but that hurt other LVS and non-LVS users. Sometimes the performance is
meaningful. And it is acceptable to look for existing connections (in
any connection tracking implementation) in the pre routing (as in your
patch). The problem comes when connections are created in this chain.
This is one of the things I don't like in Netfilter but this is my
opinion.
> > Give us an example (with dummy addresses) for setup that require
> > such fwmark assignments.
>
> For a start you need a LVS setup with more than one real interface receiving
> client traffic for this to be of any use. Some clients (due to routing
> outside the LVS server) comes in on one interface, other clients on another
> interface. In this setup you might not want to have a equally complex routing
> table on the actual LVS server itself.
Agreed. It seems an optional hook registering will be a good
idea for LVS. Not sure how simple it can be done, with module options?
How LVS will be tuned when it is compiled in the kernel. Because all
useful features implemented together can collide or at least can drop
the performance in some cases. We know that the LVS/NAT performance
is critical for some users.
> --
> Henrik Nordstrom
> SafeCore Technologies
Regards
--
Julian Anastasov <ja@xxxxxx>
|
