LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: trouble about IP Fragmentation by using the Linux Virtual Server

To: Roberto Nibali <ratz@xxxxxxxxxxxx>
Subject: Re: trouble about IP Fragmentation by using the Linux Virtual Server
Cc: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
From: Julian Anastasov <ja@xxxxxx>
Date: Wed, 18 Sep 2002 14:59:48 +0300 (EEST)
        Hello,

On Wed, 18 Sep 2002, Roberto Nibali wrote:

> > - if netfilter connection tracking is used, ip_send_check is called
> > after ip_defrag and LVS has packet with valid IP csum.
>
> Hey, I think with the new {nf|ct}-netlink framework you could ask for
> that and then do your conditional check. But I doubt if it will be
> faster then.

        We can now use one ip_send_check at the beginning of ip_vs_in(),
it will delay only NAT because this is the only method that
uses its own ip_send_check after header change. IMO, the best thing
is when after each ip_defrag there is ip_send_check. But it
is better if IPVS is out of LOCAL_IN which will not happen
soon.

> >     Now, after introducing the Layer 8 factor (Julian) who
>
> LOL! Maybe someone should update some RFC with OSI-L8 then :).

        Agreed :)

> >     So, we add unconditional ip_send_check when we know the
> > packet will be forwarded to another host. We can not know that
> > someone fixed the csum after ip_defrag.
>
> 2 Questions:
>
> o Wouldn't it be nicer to have a bitfield in the struct skbuff which
>    indicates the csum status? But I guess then netfilter would need to
>    adapt a lot of code. But I see some nice unused fields in skbuff :)

        NFC_NEED_IPCSUM :)

> o Shouldn't we do a conditional check for skb->summed? For example if it
>    is for the LOCAL_NODE feature.

        Yes, local node and NAT don't need this csum update, the
csum2 patch accounts it.

> We should really put the LVS hook out of the netfilter misery and call
> it directly from the FIB :)

        To control routing :) It is difficult :) But it is possible
to link one conn entry for the both directions and calling
routing with different keys (working at prerouting), NAT on FORWARD :)
Then we can work with many ISPs :) SNAT decision before routing
or more correctly, with lsrc key for established traffic. One
day I'll try it for test.

> BTW, Julian, do you know how to export a struct to the slabinfo so it
> doesn't show up in on of the size-{32,64,...} slabs? If I have multiple
> size-128 slabs, I would like to differentiate them. For example like
> arp_cache or skbuff_head_cache.

        Hm, I only know for slab cache, if you have many size-128
entries you better to use cache. Or you have something different
in mind?

> Best regards,
> Roberto Nibali, ratz

Regards

--
Julian Anastasov <ja@xxxxxx>



<Prev in Thread] Current Thread [Next in Thread>