05-23-2007 07:03 AM
Greetings all
I've been testing FTP service through our CSM for about a day now and has run into an issue I can't find an answer for.
Here are the settings I'm currently using for the vserver and serverfarm. The 10.90.1.0 network is routed from my client network by a firewall using NAT.
serverfarm APPFARM
nat server
no nat client
predictor leastconns
real 10.91.1.155
inservice
probe ICMPCHECK
vserver APPFTP
virtual 10.90.1.40 tcp ftp service ftp
serverfarm APPFARM
persistent rebalance
inservice
Connecting to the FTP works just fine using both passive and active FTP and I can log in and transfer files. However when I send the "quit" command to the FTP server, as I do when connecting to the server directly, the session freezes and the "good bye" messages never appears.
My guess is that there is some premature termination of the connection before a final disconnect is sent to my FTP client. Anyone have an idea how this can be solved?
Regards
Fredrik Hofgren
05-25-2007 01:55 AM
Fredrik,
first time I see this.
Could you capture a sniffer trace of csm portchannel showing what happens before, during and after the Quit.
Also, there is way to achieve ftp loadbalancing without the need to use 'service ftp'. You'll get much better performance if you do not use this function.
All you need is configure loopback on your servers using the vip address so they can advertise the right ip in the control channel fo the client to open the data channel.
You then need a generic vserver to catch all possible port and by using stickyness you can guarantee that the control channel and the data channel are both sent to the same server.
Gilles.
05-27-2007 10:52 PM
Ethereal sniffer trace on the CSM port channel included. What I can see from the trace the Quit message is transmitted by the FTP/VIP but not forwarded by the firewall. Strange, I you have another interpretation please let me know.
I've tried L2 FTP using the VIP as loopback on the FTP server but couldn't get it to work with both active and passive FTP.
05-28-2007 07:40 AM
not sure how you captured the trace, but normally I would have expected to see each packet twice. Once on the front vlan and once and the backend vlan.
What I can tell is that the quit made it to the server because this responded with a 221 ...
So, the quit is not the problem.
However, we then see the server sending a FIN/ACK which is correctly ACK'ed by the client.
And then we don't see the FIN from the client.
Without more info about the trace, and without a front and backend trace, I can't tell where the FIN is dropped and why.
Gilles.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: