04-Nov-2019 05:24
Hello there,
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 !
04-Nov-2019 07:17
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.
10-Nov-2019 08:04
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?
11-Nov-2019 09:15
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.
12-Nov-2019 02:08
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 🙂
16-Nov-2019 05:52
thanks for reporting back, always good to see it ends up to be something different.
17-Nov-2019 22:46
Actually they didn't find anything, so there I am back to my issue :s
18-Nov-2019 00:32
19-Nov-2019 05:26
Yes the simple default "ftp".
17-Nov-2019 22:55
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.
17-Nov-2019 23:10
The issue is only via F5 ^^
I opened your link and don't understand much '^^
18-Nov-2019 00:30
19-Nov-2019 05:29
Did the tcpdump on the lan side, nothing to see here.
F5 > ftp request : USER usertest
ftp > F5 ACK
****
5second blank
****
ftp > F5 response : 331 password required for usetest
F5 > ftp ACK
The same when the password is sent, and when the directory is required.
30-Nov-2019 07:14
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.
18-Nov-2019 00:56
Yep, the basic ftp one.
I tried without it, no change.
01-Dec-2019 23:07
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 😄
08-Dec-2019 01:06
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?
08-Dec-2019 23:10
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
08-Dec-2019 23:14
08-Dec-2019 23:17
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....