|
Julian Anastasov wrote:
> 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 :)
Yes, you can use fwmark for routing, but not really in the manner this patch
enables.
This patch is for routing of the return traffic from the real server in the
direction from where the initial packet that started the session was received.
It might however be the case that the collision no longer is there. The patch
started it's life as a patch to Netfilter IPVS 0.0.5.
> 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.
Regarding iptables / ipvs I currently "only" have three main issues.
a) As the "INPUT" traffic bypasses most normal routes, the iptables conntrack
will get quite confused by return traffic..
b) Sessions will be tracked twice. Both by iptables conntrack and by IPVS.
c) There is no obvious choice if IPVS LOCAL_IN sould be placed before or
after
iptables filter hook. Having it after enables the use of many fancy iptables
options, but instead requires one to have rules in iptables for allowing ipvs
traffic, and any mismatches (either in rulesets or IPVS operation) will cause
the
packets to actually hit the IP interface of the LVS server which in most cases
is
not what was intended.
--
Henrik Nordstrom
SafeCore Technologies
|
