Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Blue

deciphering NetConfig job failure

Have a job that simply runs "write memory". It recently started failing on a couple of rtrs:

Results for Device rtr1
Device Deployed
Pre Device Execution Message:
Post Device Execution Message:
Update Startup Not Attempted
Results of Deploy:
Message: Command(s) failed on the device
Insufficient no. of interactive responses(or timeout) for command: write memory. SCP: SCP and RCP protocols are supported only for conf
ig mode commands.
Couldnot copy file contents from Server to device because the device mode of the command was CONFIG.

TFTP: Tftp is supported only for config mode commands.

write memory

Results for Device rtr2
Device Deployed
Pre Device Execution Message:
Post Device Execution Message:
Update Startup Not Attempted
Results of Deploy:
Message: Command(s) failed on the device

Could not detect SSH protocols running on the device
^MSCP: SCP and RCP protocols are supported only for config mode commands.
Couldnot copy file contents from Server to device because the device mode of the command was CONFIG.

TFTP: Tftp is supported only for config mode commands.

write memory

Transport protocol order is: SSH, SCP, TFTP.

Was rtr1 running out of VTY lines at the time of the job execution?

Was rtr2 really not responding on SSH?

3 REPLIES
Cisco Employee

Re: deciphering NetConfig job failure

It could be that write mem on rtr1 was interactive (e.g. you did an upgrade recently, and you were about to overwrite NVRAM with a newer config).  Actually, rtr2 could have been out of VTY lines, or had some other issue responding to SSH (e.g. it has a bug where it returns an SSH version of 2.99 instead of 2.0 or 1.99).

Blue

Re: deciphering NetConfig job failure

Do you mean IOS on rtr1 could be throwing up an unexpected prompt that NetConfig didn't know know how to respond to?

At this point, I suspect rtr1's "write mem" took so long that LMS mistook it as a timed out session. Should I simply bump up the timeout under RME - Admin - Config Mgmt - Archive Mgmt - Fetch Settings, or would that not impact NetConfig jobs at all?

Are there process debugs that could be turned on in order to capture the full interactions between NetConfig and the devices in a more readable output, or would I be better off getting a sniffer trace for both rtr1 and rtr2?

Cisco Employee

Re: deciphering NetConfig job failure

Yes, I mean "write mem" on rtr1 could be throwing up a prompt.  No, a timeout would have produced a different error.  With SSH, a sniffer trace would be useless.  You could increase Config Job debugging, then look at the Netconfig job log to find out what the device is saying during the job.

409
Views
0
Helpful
3
Replies
CreatePlease to create content