We're running RME 4.2.0 on Solaris 10.
I have the following protocol order setup:
Protocol Order for Image Transfer: TFTP, SCP
Protocol Order for Config-Operations: TELNET, TFTP, SSH, SCP
We have devices which only support SSH and SCP. We tried pushing code to them and the job failed because RME couldn't connect to the device via Telnet. RME never tried the next protocol. It should have tried TFTP next followed by SSH.
Why does this happen?
Go to RME > Admin > Software Mgmt > View/Edit Preferences, and make sure the "Use SSH for software image upgrade and software image import through CLI(with fallback to TELNET)." box is checked. SWIM will then use SSH first when it needs to directly connect to the device.
I made the change and RME was able to SSH to the device.
Since my protocol order for Image Transfer is TFTP followed by SCP, RME tried to TFTP and next tried to SCP but did not execute any scp commands on the device. For testing purposes I changed the image or to only SCP, ran my job again with debug and the job failed but RME didn't execute any SCP commands.
I've attached all files from my job
Nor would it. LMS server-side SCP is not supported until LMS 3.2. In LMS 3.1, the device must be running the SCP server.
I'm not understanding.
Are you saying that RME can't issue the "copy scp" command to devices in LMS 3.1?
RME does run "copy tftp" no devices so why can't it run "copy scp"?
Did you take a look at the info I attached?
That's exactly what I'm saying. For SCP, RME will actually act as a client, and the device as the server. In LMS 3.2, we started shipping an SCP server with LMS so the devices can do "copy scp". Yes, I looked at the attachment, and the problem appears to be you don't have "ip scp server enable" configured on the device.
So for TFTP, RME acts as both a client and a server?
From the UNIX command line I can scp so I'm still not understanding why RME 4.2.0 can't issue the command.
For TFTP, RME acts as the server. For SCP in RME 4.2, RME acts as the client, and the device is expected to be the server. The log indicates there was a broken pipe trying to do the SCP transfer which seems to indicate the device is not configured as an SCP server.
No, it should try SSH. Check RME > Admin > Config Mgmt > Transport Settings, and make sure SSH is in the Archive Mgmt Config Fetch protocol order. RME will then SSH to the switch, and perform a copy flash:vlan.dat tftp: to transfer the file to the RME server.
Yes, it tried SSH. The command to copy the file failed. These logs are not helpful for seeing why it failed. You'll need to post the dcmaservice.log.