Re: [lvs-users] connection broken after 2MB of data transmitted

To: Robert.Grange@xxxxxxxxxxxx
Subject: Re: [lvs-users] connection broken after 2MB of data transmitted
Cc: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
From: Julian Anastasov <ja@xxxxxx>
Date: Sat, 19 May 2018 16:14:34 +0300 (EEST)

On Fri, 18 May 2018, Robert.Grange@xxxxxxxxxxxx wrote:

> Hi Julian,
> Here are the 3 traces anonymized (IP, MAC, Port, and with no payload)
>       mq_00001_20180518102401_onlyip_192.168.0.1_anon at frame 3430
>       director_00001_20180518102356_onlyip_192.168.0.1_anon   at frame 3428 
> (but always TCP Retransmit & TCP Dup Ack since the beginning)
>       client_00001_20180518102350_anon                                at 
> frame 4287
> I also tried to change the
>       ethtool -K ETH gso off
>       ethtool -K ETH gro off
> but it didn't help
> on the client, the arp -a shows that the MAC of the VIP has the correct MAC 
> (the one of the active director)

        May be on director there is some HW problem with the
receiving interface. Client sends packets for seq 67008:67084
on the > connection,
they have IP id 12552, 12554, 12555, 12556, 12557, 12558.
None of them is received on director. Still, director successfully
receives id 12553 and 12559 which are a pure ACK.

        Try to disable HW RX CSUM on director with
'ethtool -K INDEV rx off' to check if that helps to receive
such packets, in case they are dropped for some reason.
You can also monitor the interface stats for strange

ethtool -S INDEV

        If the problem is with the HW RX CSUMs, try with
fresh kernel or different hardware.

        Another alternative is problem with TX CSUMs in
client but you say it works directly to real server...


Julian Anastasov <ja@xxxxxx>

Please read the documentation before posting - it's available at: mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
or go to

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