Le 11/12/2012 22:00, Thomas Bätzler a écrit :
> Zhongkang Lao wrote on 05.12.2012 08:41:
>> I have already googled this like a hundred of times, but I got nothing.
>> I didn't find any page or any article explain this.
>> I'm sure someone here can explain this.
>> So sorry to bother you guys here.
> I don't have any answers, but I can confirm the problem (and the
> workaround) on a box running Debian "Squeeze" with 2.6.32 directing
> traffic from a VIP bound to lo via NAT to an active/backup bonding
> interface on the backend. With "gro on" for the bonded interfaces to the
> backend real servers, throughput was ~64K/s. With "gro off" it was
> ~50MB/s. It's not a general networking problem since a direct connection
> to the real server via a DNAT port forward was not impacted.
>>From what I gleaned from a cursory look with tcpdump it seems that the
> problem is caused by incorrectly calculated tcp checksums.
> Anybody interested in pursuing this further?
Yes, I can relate.
I had the same conclusions, incorrectly calculated TCP checksums leading
to packet drops by the next firewall (in my architecture).
Also fixed by disabling gro.
CentOS 6.2, ipvsadm-1.25-9.el6.x86_64, kernel 2.6.32-220.23.1.el6.x86_64
Please read the documentation before posting - it's available at:
LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
or go to http://lists.graemef.net/mailman/listinfo/lvs-users