Scheduled Downloads : Timeout issue

I have seen a few posts where folks have reported that they receive timeout errors on the scheduled config downloads from seemingly random set of devices. When downloading manually from these devices the same devices that failed in the scheduled download work just fine.

One of the theories we have is that this may be related to a scalability issues with TACACS server. So what I am wondering is for the folks that are seeing this issue how many have TACACS based authentication?

For internal folks I opened TT#3367

Find more posts tagged with

scheduled_job

tacacs+

tacacs

config_downloads

timeout

ncm_5.1.1

simultaneous_downloads

Accepted answers

All comments

rsprim

Sham,

We have this problem and are using TACACS. We are trying to download 20 devices at a time and the error we receive is:

ERROR: Cannot download Running config : Unable to Log into Router : Timeout.

Robert

Junyoure

I too have the same issue adn use TACACS for authentication. I have problems even attempting to download interactively if the number of target nodes exceeds the maximum number of simultaneous downloads. The greater the difference between these two variables (targets v maximum) the more devices timeout.

I am currently set to 5 simultaneous uploads/downloads. 98% of devices use SSH as transfer, and last night 15% of all devices logged this error.

All you solarwinds Guru's...what have you been able to do to fix this. Fort he NCM website to display accurate data we need to be able to rely on the data gathered and not have to work an exception report of this size everyday.

thanks

Junyoure

Follow-up:

I have an active case open with Support. The proposed workaround is to lower the simultaneous upload/download to "1". i tried this last night and was sucessfull in backing up all configs in the database (excpet the three devices offline for maintenence.) so This effectively eliminated the timeouts I've been seeing on backups.

My support technician indicated this was a bug and they hope to have it repaired in the next service-pack.

a 422 node job took two hours to complete, and is an acceptable workaround for me at the present time.

Has anyone else experienced this? If so, could you try lowering your up/download limit to "1" and let us know if you're successful also?

thanks,