FTP service through CSM: Quit command not working

Unanswered Question
May 23rd, 2007

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

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
Gilles Dufour Fri, 05/25/2007 - 01:55

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.

hoffa2000 Sun, 05/27/2007 - 22:52

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.

Attachment: 
Gilles Dufour Mon, 05/28/2007 - 07:40

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.

Actions

This Discussion