|
Hello,
On Thu, 15 Feb 2001, Henrik Nordstrom wrote:
> 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.
Yes. My thought was that 0.2.3 already assumes that fwmark
can be used for routing-only purposes, i.e. not always for fwmark-based
LVS service.
> 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.
Yep, in 0.2.3 there will be only one dummy service lookup when
you use fwmark for routing. 0.0.5 will just ignore the client requests.
> > 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..
Is it really confused in 0.2.3? Before 0.2.x we had big problems
with the netfilter conntracking. But now we use special fwmark value
to exit from the next chains and to call okfn.
> b) Sessions will be tracked twice. Both by iptables conntrack and by IPVS.
Yes, for every forwarding method. We must find a way to stop
the connection tracking for the "external" interface where we create
connections. For the in->out traffic we are before netfilter
conntracking (not in pre_routing). May be lookups can be added in the
pre_routing for existing connections (for the both directions) but
may be that can cost very much. In Netfilter there is no double lookups.
If we add some hooks in the pre routing we have to make such
double lookups because the packets simply can be dropped (for many
reasons) before they reach LOCAL_IN. We don't hook the skb primitives
like netfilter and all games before LOCAL_IN are avoided. In your
patch the hook in pre routing is safe but you see that currently
the 2nd LVS connection lookup can't be avoided.
So, in 0.2.x the things should work but with little performance
drop when LVS is used with netfilter together. The other thing you must
not forget when you tune your patch is that LVS can work without any
netfilter modules, i.e. by using the hooks only - the fastest way.
> 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.
Yes, some applications have extra needs for open ports (ftp).
But normally all other ports are closed. Of course, mistakes are not
allowed but relying only on the routing for security is not a good
solution. Sometimes firewall settings are required in the input chain,
usually for LVS-DR setups with one NIC and with many subnets. If the
uplink router guards the cluster the LVS/NAT setup can be with 0
INPUT fw rules, may be just like in your setup. But this can't be a
general feature in LVS, to stay before the filter because LVS does
not traverse the FORWARD fw chain like the Netfilter requires it :)
The LVS place for firewalling is INPUT just like in the Linux 2.2
days :)
> --
> Henrik Nordstrom
> SafeCore Technologies
Regards
--
Julian Anastasov <ja@xxxxxx>
|
