cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
8682
Views
5
Helpful
10
Replies

DNA Center to Switch SCP File Transfer too Slow

When i try updating the OS from DNA Center to Cisco 3850 Switch, It starts well and stays alive till 1 Hour and 13 mins - till then only 40 Mb file is copied and it fails. It keeps on failing. 

 

Please suggest for any configuration changes. 

 

SCP looks working fine but fails after every one hour. 

 

DNA Center sits in my Data center and Switch is in the remote office. 

 

 

 

 

10 Replies 10

scherrav
Cisco Employee
Cisco Employee

Do you have enough space on the switch? Please show "dir"

Space is available in the flash. No issues around this. SCP file transfer goes well till 1 hour and copies file up to 50 Mb max and fails. same thing happens with other devices as well. Auto Clean also shows successful. 

Have you tried using the pre-upgrade check feature? Does any of the items fail on that?

At this point, please take packet capture via SPAN or monitor capture on the switch to see if it is losing packets.

 

 

I'm having the exact same issue

Hi, can you post any error message or screenshot of what you are seeing.

From the device you are using can you send "show ip http server secure status"

Is the device managed? What is the device HW/SW?

Doing more test and I actually had the file copy fail when using a different machine as the SCP server and doing a manual copy from the router.  It kind of seems there's a max time on the copy operation.  Seems to fail at the exact same time.  OP said they were going a copy over a long distance and so am I (CA <> PA).  Going to test a shorter run and see if there's still a problem.

Yeah, this looks like a bug in how SCP is working on the routers/switches.  If a file transfer takes too long (SCP clearly doesn't scale window size otherwise latency wouldn't be such a big issue) it just fails.  I'm opening a TAC case to see what they can make of it.

Parthiv Shah
Cisco Employee
Cisco Employee

Depending upon the RTT from your switch to DNAC, file copy time varies but it shouldn't take 100 minutes. If you have access to DNAC, could you send the RCA file or you can dump the log file using "magctl service logs -r swim > swim.log"

 

ShaunGreen
Level 1
Level 1

We have a similar issue. SCP is timing out, but from the pre-upgrade check from DNA, it's not possible to do HTTPS image upgrades to our 3850's, but it is okay for 9300's.

 

I can't copy a file from DNA using HTTPS, until I've carried out a HTTP copy, then HTTPS works.

 

pgmnlphsw01#sho ip http client all

HTTP client status: Enabled
HTTP client application session modules:
Id : 1
Application Name : HTTP CFS
Version : HTTP/1.0
Persistent : persistent
Response-timeout : 0
Retries : 0
Proxy :

Id : 2
Application Name : HTTP_CALL_HOME_AGEN
Version : HTTP/1.1
Persistent : persistent
Response-timeout : 30000
Retries : 1
Proxy :


HTTP client current connections:
Persistent connection = enabled (default)
Connection establishment timeout = 10s (default)
Connection idle timeout = 30s (default)
Maximum number of connection establishment retries = 1 (default)
Maximum http client connections per host : 2
HTTP secure client capability: Present
HTTP secure client ciphersuite: aes-128-cbc-sha aes-256-cbc-sha
dhe-aes-128-cbc-sha dhe-aes-256-cbc-sha
HTTP secure client trustpoint:

local-ipaddress:port remote-ipaddress:port in-bytes out-bytes
10.******:40936 10.******:80 12654 3504


Total client connections : 1


HTTP client cache:
Maximum Memory size for cache : 100000 bytes (default)
Maximum memory per cache entry : 2000 bytes (default)
Memory used : 0 bytes
Memory Available : 100000 bytes
Cache Ager interval : 5 minutes (default)
Total entries created : 0
Id Type Url Memory-size(Bytes) Refcnt Valid(Sec)
__________________________________________________________________________


HTTP client statistics:

HTTP client history:
GET 20:13:53 MNL Mon Jul 20 2020 10.****.15//core/img/cisco-bridge.png

Is there a standard config for the switches to allow us to do a HTTPS file transfer?

andrewohanian
Level 1
Level 1

Just want to help anyone out that was going through this as well. I spent several hours trying to solve this and I think I finally got it.

 

1. All of my devices either failed HTTPS and succeeded on SCP, or failed both. I couldn't understand why SCP worked on some switches but not others. The answer was the ip ssh version 2 was configured on the switches that worked. I added this to the switches that were failing over SCP and they started working.

 

So now I could actually deploy the images and upgrade them. The problem was then that SCP was painfully slow. So I ended up getting HTTPS to work.

 

2. For HTTPS to succeed the switches need to have the cert of DNAC installed locally. The easiest way to do this is to obtain the PEM file from DNAC itself http://<dnac>/ca/pem then open it in notepad.

Now login to the switch and remove the DNAC-CA as a trustpoint if it already exists (for some reason I had a DNAC-CA cert on some of my switches but apparently it was not the correct cert)

   no crypto pki trustpoint DNAC-CA 

 

Now re-configure the trustpoint:

crypto pki trustpoint DNAC-CA
enrollment mode ra
enrollment terminal
usage ssl-client
revocation-check none
exit

 

Now add in the certficate:

crypto pki authenticate DNAC-CA

*paste in the cert from the PEM file that you have open in notepad*

 

At this point you should be able to successfully reach the DNAC over its IP, you can test it out with this command:

copy https://<dnac-ip>//core/img/cisco-bridge.png flash:

 

Now when you do an image readiness check, you should see HTTPS succeeding. In my case, using HTTPS resulted in a 10 minute transfer, while SCP was 47 minutes.

Review Cisco Networking for a $25 gift card