2011/4/14 Julian Anastasov <[email protected]>: > > 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 <[email protected]> > -- Romain _______________________________________________ Please read the documentation before posting - it's available at: http://www.linuxvirtualserver.org/ LinuxVirtualServer.org mailing list - [email protected] Send requests to [email protected] or go to http://lists.graemef.net/mailman/listinfo/lvs-users
