Re: [lvs-users] Apparent MTU problem using LVS-DR and Windows 2003 RealServers

[Christopher Smith <csmith@xxxxxxxxxxxxxxxx>]

Thanks for the responses, Simon and Joseph.

I've managed to identify the key factor: only transfers from a Windows client 
*on the same subnet* fail.  If I use a Linux client on the same subnet, or move 
the Windows client to a different subnet, it works fine.  Additionally, *a 
direct connection between the client and the server* (ie: not using the VIP on 
the directors) on the same subnet also works fine.

I've also identified this is a problem only when *sending data from the client 
to the RealServer* (using SFTP in the test case below).  Since I'm pretty sure 
the problem is independent of the protocol, and that everyone here will be more 
familiar with SFTP, I'm going to concentrate on getting that working first. :)

In summary: if I have a Windows client, on the same subnet, I can't 
load-balance SFTP sends *TO* a Windows RealServer.  These other scenarios all 
work fine:
* Linux client on same subnet
* Windows client on different subnet
* Linux client on different subnet
* Any "pull" style transfers (eg: grabbing a file via HTTP - even large ones 
(5MB+))


Since I needed to get the basic DICOM functionality up and running in the 
interim, I've temporarily moved the "production" clients onto a different 
subnet to get them going.  As such, the configuration has changed slightly 
since my first mail.

The director VIP is: 10.183.3.116
The MAC address for the interface it is on is: 00:0C:29:FB:40:F1

The RealServer IP is: 10.183.3.115
Its MAC is: 00:50:56:99:5C:E0

The Client IP is: 10.183.3.244
Its MAC is: 00:50:56:99:2B:6D

MTU on all machines  is the standard 1500.

The ldirectord config file is:
autoreload = yes
checkinterval = 30
checktimeout = 3
callback = "/etc/ha.d/resource.d/sync_config.sh"
# SFTP.  Mainly used for testing
virtual = 10.183.3.116:22
        ## IMPORTANT.  The following directives for the
        ## above virtual/service IP definition ***MUST*** be
        ## indented by _at least_ four (4) spaces *OR* a single tab.
        protocol = tcp
        scheduler = rr
        #persistent=600
        #real = 10.183.3.113:22 gate
        #real = 10.183.3.114:22 gate
        real = 10.183.3.115:22 gate
        checktype = connect
        quiescent = no
# SFTP.  Mainly used for testing
virtual = 10.183.3.116:80
        ## IMPORTANT.  The following directives for the
        ## above virtual/service IP definition ***MUST*** be
        ## indented by _at least_ four (4) spaces *OR* a single tab.
        protocol = tcp
        scheduler = rr
        #persistent=600
        #real = 10.183.3.113:80 gate
        #real = 10.183.3.114:80 gate
        real = 10.183.3.115:80 gate
        checktype = connect
        quiescent = no


It looks like the director is sending these:
07:39:56.419436 00:0c:29:fb:40:f1 > 00:50:56:99:2b:6d, ethertype IPv4 (0x0800), 
length 590: 10.183.3.116 > 10.183.3.244: ICMP 10.183.3.116 unreachable - need 
to frag (mtu 1500), length 556

I also see a lot of TCP out-of-order, duplicate ACK and retransmission packets 
on the client.

I have attached a tcpdump (from the director) and two wireshark pcap files 
(from the client and RealServer) that were captured during an attempt to SFTP a 
512kb file from the client to the RealServer (I cancelled the copy about 30-45 
seconds after it hung - it did not complete).  Any help anyone can offer in 
figuring out what is wrong, would be great, as I've exhausted my knowledge. :)  


Cheers,
-- 
Christopher Smith

UNIX Team Leader
Nighthawk Radiology Services
Limmatquai 4, 6th Floor
8001 Zurich, Switzerland
http://www.nighthawkrad.net
Sydney Fax:    +61 2 8211 2333
Zurich Fax:    +41 43 497 3301
USA Toll free:  866 241 6635

Email:         csmith@xxxxxxxxxxxxxxxx
IP Extension:  8163
Sydney Phone:  +61 2 8211 2363
Sydney Mobile: +61 4 0739 7563
Zurich Phone:  +41 44 267 3363
Zurich Mobile: +41 79 550 2715

All phones forwarded to my current location, however, please consider the local 
time in Zurich before calling from abroad.


CONFIDENTIALITY NOTICE:   This email, including any attachments, contains 
information from NightHawk Radiology Services, which may be confidential or 
privileged. The information is intended to be for the use of the individual or 
entity named above. If you are not the intended recipient, be aware that any 
disclosure, copying, distribution or use of the contents of this information is 
prohibited. If you have received this email in error, please notify NightHawk 
Radiology Services immediately by forwarding message to 
postmaster@xxxxxxxxxxxxxxxx and destroy all electronic and hard copies of the 
communication, including attachments.

Client.zip
Description: Client.zip

director.gz
Description: director.gz

RealServer.zip
Description: RealServer.zip

_______________________________________________
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