|
Hello,
On Wed, 11 Jul 2001, Tao Zhao wrote:
> I am not sure if this list is the right place to ask this question. If
> not, please let me know where I should send it.
It is LVS related question, though :)
> I am reading the source code of LVS and found out that it adds ip_vs_in()
> to netfilter hook NF_IP_LOCAL_IN to change the destination of packets. As
> I understand, this hook is called AFTER routing decisions have reached. So
> how can it forwards the packet to the new assinged destination without
> routing? I thought the right place to change destination is the
> NF_IP_PRE_ROUTING hook. Am I missing something?
LVS does not follow the netfilter recommendations. What about
if we don't change the destination? This is the way DR and TUN methods
work. They don't change the IP header. When such packet hits the routing
the IP header fields are used for the routing decision. May be someone
have to add ROUTING hook where LVS can change the arguments for the
input routing function call :) OTOH, Netfilter can forward only by using
NAT methods.
LVS tries not to waste CPU cycles in the routing cache.
You can see that there is output routing call involved but there is a
optimization you can find even in TCP - the destination cache. The
output routing call is avoided in most of the cases. This model is
near the one achieved in Netfilter, i.e. to call only once the input
routing function (2.2 calls it twice for DNAT). I'm now testing a
patch for 2.2 (on top of LVS) that avoids the second input routing
call and that can reroute the masqueraded traffic to the right gateway
when many gateways are used and mostly when these gateways are on
same device. The tests will show how different is the speed between
this patched LVS for 2.2 and the 2.4 one (one CPU of course).
We decided to use the LOCAL_IN hook for many reasons. May be
you can find more info for the LVS integration into the Netfilter
framework by searching in the mail list archive for "netfilter".
Some info:
http://marc.theaimsgroup.com/?l=linux-virtual-server&m=98296653726641&w=2
> I know I need read more code. But a quick answer of this will help me.
>
> Thanks,
> -Tao
Regards
--
Julian Anastasov <ja@xxxxxx>
|
