|
Hi Julian,
On Wed, Sep 01, 2010 at 02:22:12AM +0300, Julian Anastasov wrote:
>
> Add more code to IPVS to work with Netfilter connection
> tracking and fix some problems.
>
> - Allow IPVS to be compiled without connection tracking as in
> 2.6.35 and before. This can avoid keeping conntracks for all
> IPVS connections because this costs memory. ip_vs_ftp still
> depends on connection tracking and NAT as implemented for 2.6.36.
>
> - Add sysctl var "conntrack" to enable connection tracking for
> all IPVS connections. For loaded IPVS directors it needs
> tuning of nf_conntrack_max limit.
>
> - Add IP_VS_CONN_F_NFCT connection flag to request the connection
> to use connection tracking. This allows user space to provide this
> flag, for example, in dest->conn_flags. This can be useful to
> request connection tracking per real server instead of forcing it
> for all connections with the "conntrack" sysctl. This flag is
> set currently only by ip_vs_ftp and of course by "conntrack" sysctl.
>
> - Add ip_vs_nfct.c file to hold all connection tracking code,
> by this way main code should not depend of netfilter conntrack
> support.
>
> - Return back the ip_vs_post_routing handler as in 2.6.35 and use
> skb->ipvs_property=1 to allow IPVS to work without connection
> tracking
>
> - new sysctl flag "snat_reroute". Recent kernels use
> ip_route_me_harder() to route LVS-NAT responses properly by
> VIP when there are multiple paths to client. But setups
> that do not have alternative default routes can skip this
> routing lookup by using snat_reroute=0.
>
> Connection tracking:
>
> - most of the code is already in 2.6.36-rc
>
> - alter conntrack reply tuple for LVS-NAT connections when first packet
> from client is forwarded and conntrack state is NEW or RELATED.
> Additionally, alter reply for RELATED connections from real server,
> again for packet in original direction.
>
> - add IP_VS_XMIT_TUNNEL to confirm conntrack (without altering
> reply) for LVS-TUN early because we want to call nf_reset. It is
> needed because we add IPIP header and we want the original conntrack
> to be preserved, not destroyed. The transmitted IPIP packets
> can reuse same conntrack, so we do not set skb->ipvs_property
>
> - try to destroy conntrack when the IPVS connection is destroyed.
> It is not fatal if conntrack disappears before that, it depends
> on the used timers.
>
> Fix problems from long time:
>
> - add skb->ip_summed = CHECKSUM_NONE for the LVS-TUN transmitters
>
> Fix problems only in 2.6.36-rc:
>
> - when altering PASV response in ip_vs_ftp we should check with
> nfct_nat(ct) if NAT is enabled for conntrack before calling
> nf_nat_mangle_tcp_packet. This avoids possible crash when
> iptable_nat is not loaded.
>
> - do not create expectation in ip_vs_ftp when PORT command is
> forwarded, leave it to nf_conntrack_ftp.c:help(). This
> avoids packet drops because nf_ct_expect_related() fails in help().
> Signed-off-by: Julian Anastasov <ja@xxxxxx>
> ---
>
> Simon, this patch is against 2.6.36-rc2, I tested it
> for IPv4. In fact, it is ready for inclusion in net-next but
> I'm not sure if it applies properly.
I can fix that if you prefer.
> After first comments we can
> move the discussion to netdev. The snat_reroute part can be
> separated, if needed at all.
I'd prefer a separate patch.
> Also, IP_VS_CONN_F_NFCT can be
> added to ipvsadm as real server option.
I can handle ipvsadm patches these days.
I can even make the patch if you'd prefer.
> The two problems
> in ip_vs_ftp can be also fixed in next 2.6.36-rc kernels.
Yes, as they are regressions since 2.6.35 please break those changes out
into one or two separate patches so they can be submitted for inclusion in
2.6.36.
> May be Hannes Eder can comment if he can see these problems.
> But I worry that this full patch is needed for 2.6.36
> because not all systems use netfilter conntrack and are
> not tuned for many conntracks. Now 2.6.36 can come as
> surprise to them because IPVS requires Netfilter connection
> tracking support.
Unfortunately I think its too late to get the bulk of this into 2.6.36.
Are you concerned about a performance problem? Even when
Hannes's new features aren't used? Is the snat_reroute flag a
solution/workaround? If so we could try to get that into 2.6.36,
although I'm not sure how well it would be received.
--
To unsubscribe from this list: send the line "unsubscribe lvs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
|
