05-03-2018 07:50 AM - edited 03-08-2019 02:53 PM
When I attempt download a file from our public FTP server to any of our 3850's I get the below error message.
%Error opening ftp://*****:*****@11.22.33.44/cat3k_caa-universalk9.SPA.03.06.08.E.152-2.E8.bin (Incorrect Login/Password)
I'm using this command syntax to copy the file.
copy ftp://$USERNAME:$PASSWORD@11.22.33.44/cat3k_caa-universalk9.SPA.03.06.08.E.152-2.E8.bin flash:/cat3k_caa-universalk9.SPA.03.06.08.E.152-2.E8.bin
Troubleshooting steps taken...
1. FTP server is pingable.
2. Able to login to the FTP server from my PC using the same credentials
3. Tested using the "ip ftp username" and "ip ftp password" commands and then not specifying creds in the copy command. I receive the same error message.
4. No ACL's on the switches
5. Debug output below
1383852: .May 3 10:14:03.716 EDT: FTP: 220 Serv-U FTP Server v14.0 ready... 1383853: .May 3 10:14:03.717 EDT: FTP: ---> USER $USERNAME 1383854: .May 3 10:14:03.725 EDT: FTP: 220 Serv-U FTP Server v14.0 ready... 1383855: .May 3 10:14:03.725 EDT: FTP: ---> QUIT
6. We're currently running 3.4.4 on all our switches. There are a few bugs regarding FTP but I don't think any of them would give the symptoms we're experiencing. We do have "ip ftp passive" configured.
As a last resort we can utilize TFTP but I'd really like to get FTP working. We have multiple switches all at different locations with no one on site, so easiest is probably we TFTP over the internet, which I've not had luck with in the past. I'm also just curious why this isn't working.
Solved! Go to Solution.
05-09-2018 07:14 AM - edited 05-09-2018 07:16 AM
We ran a packet capture on the ftp server and tcp debugs on the switch. Both sides were saying the other one sent a tcp reset packet.
The issue turned out to be an IPS appliance sending (spoofing) RST packets to both the server and the client.
05-03-2018 09:15 AM
05-03-2018 09:21 AM
Keep the config with the ftp username and password and try "no ip ftp passive".
Also, step through the FTP process:
!
copy ftp flash:
Address or name of remote host[]?11.22.33.44
Source filename []? cat3k_caa-universalk9.SPA.03.06.08.E.152-2.E8.bin
Destination filename [cat3k_caa-universalk9.SPA.03.06.08.E.152-2.E8.bin]
!
I've found that the passive option varies with some platforms and stepping through it has always worked best.
Hope this helps
05-03-2018 10:45 AM
05-03-2018 11:03 AM
Thanks for the replies all.
@DarylBrooks Our FTP server doesn't provide verbose logging, so we're stuck with basically "Connection made, User name received, Connection closed". We ran a pcap and see the user name received, then the server sends a RST message for whatever reason. Seems like a server side security thing is dropping the connection but it's strange that no other hosts are having the issue, just these 3850s, and we have other traffic coming from the same public IP address. We should probably just make the switch to FileZilla, I've heard a lot of good things about it.
@chrihussey Same symptoms unfortunately.
@rasmus.elmholt We did try with ip ftp username (etc.) (see note 3. in the main post). It's really silly, the 3850 supports SCP but not SFTP, and our server supports SFTP but not SCP. We're looking into transferring over HTTP now.
05-04-2018 03:30 AM
05-09-2018 07:14 AM - edited 05-09-2018 07:16 AM
We ran a packet capture on the ftp server and tcp debugs on the switch. Both sides were saying the other one sent a tcp reset packet.
The issue turned out to be an IPS appliance sending (spoofing) RST packets to both the server and the client.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide