Solved: Intermittant FTP issues

DOUG KIRK · ‎07-08-2010

I am running an ACE with A2(1.4a) in bridged mode. We are currently experiencing issues with both PASV and Active FTP. When the client connects and issues a PORT command the ACE doesn't loadbalance this to the rserver causing the client to hang. This happens sporadically with connections. I am looking for any insight into what might cause this and any possible solutions. Thanks

When is working, the packet is loadbalanced to the real server:

25 6.804377 10.1.112.30 172.17.213.10 FTP Request: PORT 10,1,112,30,212,46

Ethernet II, Src: Cisco_9e:7d:00 (00:0a:b8:9e:7d:00), Dst: Cisco_fe:1b:05 (00:0b:fc:fe:1b:05)

26 6.806503 10.1.112.30 172.17.210.1 FTP Request: PORT 10,1,112,30,212,46

Ethernet II, Src: Cisco_fe:1b:05 (00:0b:fc:fe:1b:05), Dst: Dell_17:58:c3 (00:22:19:17:58:c3)

When is failing, I don’t see that packet being loadbalanced. But a local ACK from the ACE for the command <PORT>.

This is from failure01, only client to ACE:

25 10.878951 10.1.112.30 172.17.213.10 FTP Request: PORT 10,1,112,30,211,244

Ethernet II, Src: Cisco_9e:7d:00 (00:0a:b8:9e:7d:00), Dst: Cisco_fe:1b:05 (00:0b:fc:fe:1b:05)

26 11.070514 172.17.213.10 10.1.112.30 TCP ftp > 54259 [ACK] Seq=98 Ack=60 Win=32742 Len=0

Ethernet II, Src: Cisco_fe:1b:05 (00:0b:fc:fe:1b:05), Dst: Cisco_9e:7d:00 (00:0a:b8:9e:7d:00)

This is from failure02, only client to ACE:

26 10.584668 10.1.112.30 172.17.213.10 FTP Request: PORT 10,1,112,30,211,255

Ethernet II, Src: Cisco_9e:7d:00 (00:0a:b8:9e:7d:00), Dst: Cisco_fe:1b:05 (00:0b:fc:fe:1b:05)

27 10.773856 172.17.213.10 10.1.112.30 TCP ftp > 54270 [ACK] Seq=98 Ack=60 Win=32742 Len=0

Ethernet II, Src: Cisco_fe:1b:05 (00:0b:fc:fe:1b:05), Dst: Cisco_9e:7d:00 (00:0a:b8:9e:7d:00)

david.stout · ‎07-08-2010

We're using A2(2.3) but used the same config with A2(1.2a)

View solution in original post

david.stout · ‎07-08-2010

Are you using stickyness and ftp inspect ?

We're using a config similar to below and it works ok so hope this helps.

probe ftp FTP-21-PROBE
interval 2
passdetect interval 2
passdetect count 1
expect status 220 220

rserver host Server1
ip address x.x.x.x
inservice
rserver host Server2
ip address x.x.x.x
inservice

serverfarm host FTP-21-SF
probe FTP-21-PROBE
rserver Server1
inservice
rserver Server2
inservice

sticky ip-netmask 255.255.255.255 address source FTP-21-SG
timeout 60
replicate sticky
serverfarm FTP-21-SF

class-map match-all FTP-21-CM
2 match virtual-address x.x.x.x tcp eq ftp

policy-map type loadbalance first-match FTP-21-PM
class class-default
sticky-serverfarm FTP-21-SG

policy-map multi-match FTP-INPUT-POLICY
class FTP-21-CM
    loadbalance vip inservice
    loadbalance policy FTP-21-PM
    loadbalance vip icmp-reply active
    inspect ftp

DOUG KIRK · ‎07-08-2010

Hi David,

I am using the same config, except the stickyness. Let me try that out. I have tried about everything imaginable, but overlooked the stickyness since it shouldn't really be necessary for this. What train of code are you using?

Doug

david.stout · ‎07-08-2010

We're using A2(2.3) but used the same config with A2(1.2a)

DOUG KIRK · ‎07-08-2010

David,

I just implemented the stickyness and the problem still exists. Seems like the loadbalancer just decides not to pass the PORT command sporadically.

Doug

david.stout · ‎07-09-2010

What version of code are you using ? And do you have complete packet captures of the client and server traffic when this fails ?

It would be interesting to read what's happening at both ends of the connection.

There is another thread on FTP issues where it was suggested that using "inspect ftp strict" might help. However upgrading to version A2(1.6a) seemed to fix this persons issue.

Link --> https://supportforums.cisco.com/thread/2030722?tstart=0

DOUG KIRK · ‎07-09-2010

We upgraded the code to A2(2.4) and the problem has gone away. Thanks for your advice.