I have an issue I don't understand.
Some customers connect on one of our FTP server behind the F5.
Public IP of the virtual server on port 21 > default pool > one server port 21
No irule nothing.
It lasts nearly 30 secondes between the login and the listing of the FTP content.
But if I try to connect on the FTP server with it's private IP it's instant.
I am not on the same vlan as the FTP so it goes through several switchs and firewalls in private and public.
Any idea? Thank you !
Thanks for the answer.
I don't understand, why would it be linked to a DNS problem?
I did a tcpdump and there was not any error, only some 6sec blank between the login and the password request, an other blank between the password and message, and a last one before the directory listing.
the idea about the DNS is because you say you connect internally on an IP and from the outside it is assumed DNS is used.
is that the case, do customers use DNS or IP?
the delay is odd, do you use a FTP profile on the virtual server?
is the delay the same for all customers?
When you are connecting to the VS, are you using the public IP or the domain ? If domain, check to see the DNS resolution time and try and use the public IP instead of the domain to check if there is any difference in performance.
Sorry I forgot that people indeed use the DNS name for this public IP, but I realized all my tests with the public IP directly and had the same issue.
I made some intensive tests and the issue seems to be related to the server behind because everyone always have these delays when connecting to this specific FTP service.
Our windows team is now investigating, therefore this topic can be forgotten and offered to Chtulhu 😄
Thanks for your suggestions 🙂
thanks for reporting back, always good to see it ends up to be something different.
Actually they didn't find anything, so there I am back to my issue :s
Yes the simple default "ftp".
Tough to answer without seeing the packet capture. Are you seeing still seeing the same issue directly to the server and via F5 ? Try disabling Nagle's algorithm on F5 (or server) and see if it makes any difference.
The issue is only via F5 ^^
I opened your link and don't understand much '^^
Did the tcpdump on the lan side, nothing to see here.
F5 > ftp request : USER usertest
ftp > F5 ACK
ftp > F5 response : 331 password required for usetest
F5 > ftp ACK
The same when the password is sent, and when the directory is required.
it would be useful to check both sides, is there anything coming from the FTP server which the BIG-IP doesn't pass through or does the BIG-IP wait on sending something.
this is way easier to trouble shoot for f5 support, if you haven't already open a support ticket.
Yep, the basic ftp one.
I tried without it, no change.
F5 support don't have a single clue on my issue, for them it's either server side or LAN side.
It's logical concidering that we only have this issue with this particular VS.
But it's doesn't help me much 😄
so the delay starts at the FTP server? have you done a packet capture on the server to see if the delay of 5 seconds is actually there?
is there another FTP server to test wit
if you run the ftp command from the BIG-IP CLI does the same happen?
Hello I found out the culprit in my problem....
There was an IP/account on internet spamming connection tries with a good ID but bad password, all the time, night and day....
It mays have overloaded the FTP server ( but only through the F5 strange ) and it slowed down any other connection from internet...
I deleted the account and banned the IP on the F5 > no more high latency....
I hate to spend weeks on stupid problems like that xD
Our windows team didn't notice anything, I requested a full access to investigate myself and find out there was a permanent connection with bad password....