05-04-2006 01:31 PM
I'm trying to convert my CSM load-balancing environment from directed to dispatch mode. I've had success with normal telnet traffic but run into problems with FTP.
My real servers are layer-2 adjacent to the switch.
My config looks like this:
ip slb vlan 19 client
ip address 176.11.16.11 255.255.240.0
ip slb vlan 9 server
ip address 176.11.48.11 255.255.240.0
serverfarm FTP
no nat server
no nat client
real 176.11.48.104
real 176.11.48.110
vserver FTP
virtual 176.11.16.12 tcp ftp service ftp
no unidirectional
serverfarm FTP
I've put a sniffer on the server side vlan and I can see this pattern:
1) Client SYN pkt goes through CSM, gets
routed to server.
2) Server responds with SYN/ACK, but this packet goes directly back to the client (not through the CSM, because I'm not NATing)
3) Client responds with the final ACK, which goes to the CSM, but the CSM eats the packet. When I turn on debug module csm 11 ftp, I see that each time the final ACK is received by the CSM, it outputs these lines:
May 4 20:48:06.758 UTC: CSM11: called slowpath_ftp_rx
May 4 20:48:06.758 UTC: CSM11: no session for ftp rx
the CSM conn display shows:
prot vlan source destination state
----------------------------------------------------------------------
In TCP 19 176.11.16.103:1131 176.11.16.12:21 ESTAB
Why doesn't the ACK get processed and sent to the correct server by the CSM?
One additional note: I also tried this same scenario but without specifying 'service ftp' on the virtual server defintion. In that case, the control connection comes up fine but any attempt to bring up a data connection fails (times out). But then again, that's the whole point of 'service ftp', right?
Solved! Go to Solution.
05-05-2006 06:34 AM
the problem is your point #2.
If you do service ftp, the CSM expects to terminate the connection from the client and open a new one with the server.
This is how the csm can listen to all the info passed between client and server.
Moreover, the csm will need to see the server response to identify which port the server will be listening on for data connection.
So, definitely not a good idea to do direct server return with this type of config.
You should remove the 'service ftp' command and have anothe vserver to catch all data traffic. You could use a vserver with no tcp port or port 20 if your servers are configured to only use port 20.
You can then use sticky-srcip to make sure the control channel and data channel are sent to the same server.
Gilles.
05-05-2006 06:34 AM
the problem is your point #2.
If you do service ftp, the CSM expects to terminate the connection from the client and open a new one with the server.
This is how the csm can listen to all the info passed between client and server.
Moreover, the csm will need to see the server response to identify which port the server will be listening on for data connection.
So, definitely not a good idea to do direct server return with this type of config.
You should remove the 'service ftp' command and have anothe vserver to catch all data traffic. You could use a vserver with no tcp port or port 20 if your servers are configured to only use port 20.
You can then use sticky-srcip to make sure the control channel and data channel are sent to the same server.
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: