|
Hello,
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 192.168.0.1.50315 > 192.168.0.101.1234 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
errors:
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...
Regards
--
Julian Anastasov <ja@xxxxxx>
_______________________________________________
Please read the documentation before posting - it's available at:
http://www.linuxvirtualserver.org/
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
|
