|
2011/4/14 Julian Anastasov <ja@xxxxxx>:
>
> Hello,
>
> On Thu, 14 Apr 2011, Romain Meillon wrote:
>
>> I'm using 2.6.32-5-xen-amd64 from debian repo, here is the ipvs config, :
>>
>> CONFIG_IP_VS=m
>> CONFIG_IP_VS_IPV6=y
>> # CONFIG_IP_VS_DEBUG is not set
>> CONFIG_IP_VS_TAB_BITS=12
>> CONFIG_IP_VS_PROTO_TCP=y
>> CONFIG_IP_VS_PROTO_UDP=y
>> CONFIG_IP_VS_PROTO_AH_ESP=y
>> CONFIG_IP_VS_PROTO_ESP=y
>> CONFIG_IP_VS_PROTO_AH=y
>> CONFIG_IP_VS_RR=m
>> CONFIG_IP_VS_WRR=m
>> CONFIG_IP_VS_LC=m
>> CONFIG_IP_VS_WLC=m
>> CONFIG_IP_VS_LBLC=m
>> CONFIG_IP_VS_LBLCR=m
>> CONFIG_IP_VS_DH=m
>> CONFIG_IP_VS_SH=m
>> CONFIG_IP_VS_SED=m
>> CONFIG_IP_VS_NQ=m
>> CONFIG_IP_VS_FTP=m
>
> As I didn't know the kernel version I wanted to see
> if it is 2.6.37+ and how the NFCT option is set. But it is
> older, without NFCT support.
>
>> These modules are loaded :
>>
>> ip_vs 81576 24
>> ip_vs_wrr,ip_vs_wlc,ip_vs_sh,ip_vs_sed,ip_vs_rr,ip_vs_nq,ip_vs_lc,ip_vs_lblcr,ip_vs_lblc,ip_vs_ftp,ip_vs_dh
>>
>> In masq mode, the connection is established, but you are right, there
>> is checksum errors, and retransmissions until SMTP timeout exceeded :
>
> If you detect them in client then we can be sure
> it is a checksum problem. Sometimes tcpdump can show wrong
> check sum for outgoing packets but they actually are
> sent correctly from the ethernet device. So, it is hard to
> say with dump from director if we are working correctly.
> And I remember for checksum problems with Xen. Not sure
> if this recent patch fixed them:
>
> http://archive.linuxvirtualserver.org/html/lvs-devel/2010-10/msg00125.html
>
> It is part of 2.6.37. For the NAT case may be
> you have to test with above patch or to try 2.6.38 kernel.
> The patch is not needed for DR mode.
Thanks, you gave me a new way to find a solution, i'll try the
2.6.38-2 tomorrow :)
>> Transmission Control Protocol, Src Port: smtp (25), Dst Port: 51662
>> (51662), Seq: 1, Ack: 1, Len: 48
>> Source port: smtp (25)
>> Destination port: 51662 (51662)
>> [Stream index: 34]
>> Sequence number: 1 (relative sequence number)
>> [Next sequence number: 49 (relative sequence number)]
>> Acknowledgement number: 1 (relative ack number)
>> Header length: 20 bytes
>> Flags: 0x18 (PSH, ACK)
>> Window size: 5888 (scaled)
>> Checksum: 0xcfef [incorrect, should be 0x43cd (maybe caused by
>> "TCP checksum offload"?)]
>> [SEQ/ACK analysis]
>> Simple Mail Transfer Protocol
>> Response: 220 mtatest.servitics.fr Servitics SMTP Server\r\n
>>
>> On the IPVS, all packets back from the real server have checksum
>> errors, i'll try to find why :
>>
>> 11:18:27.844380 IP (tos 0x0, ttl 118, id 10288, offset 0, flags [DF],
>> proto TCP (6), length 48)
>> <PUB_IP>.51749 > 10.254.0.100.25: Flags [S], cksum 0xd148
>> (correct), seq 786497704, win 8192, options [mss 1460,nop,nop,sackOK],
>> length 0
>> 11:18:27.844843 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
>> TCP (6), length 48)
>> 10.254.0.100.25 > <PUB_IP>.51749: Flags [S.], cksum 0xfea2
>> (correct), seq 1246531960, ack 786497705, win 5840, options [mss
>> 1460,nop,nop,sackOK], length 0
>> 11:18:27.904216 IP (tos 0x0, ttl 118, id 10297, offset 0, flags [DF],
>> proto TCP (6), length 40)
>> <PUB_IP>.51749 > 10.254.0.100.25: Flags [.], cksum 0x4746
>> (correct), ack 1, win 64240, length 0
>> 11:18:27.933729 IP (tos 0x0, ttl 64, id 7442, offset 0, flags [DF],
>> proto TCP (6), length 88)
>> 10.254.0.100.25 > <PUB_IP>.51749: Flags [P.], cksum 0x9859
>> (incorrect -> 0xc3d1), seq 1:49, ack 1, win 5840, length 48
>> 11:18:30.930244 IP (tos 0x0, ttl 64, id 7443, offset 0, flags [DF],
>> proto TCP (6), length 88)
>> 10.254.0.100.25 > <PUB_IP>.51749: Flags [P.], cksum 0x9859
>> (incorrect -> 0xc3d1), seq 1:49, ack 1, win 5840, length 48
>
> Dump is from director?
The second part yes, the detailled first one is from the client.
> Regards
>
> --
> Julian Anastasov <ja@xxxxxx>
>
--
Romain
_______________________________________________
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
|
