|
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.
> 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?
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
|
