cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2439
Views
0
Helpful
19
Replies

LMS 3.1: deploy config using telnet/ssh failed when changing hostname

ebezombes
Level 1
Level 1

Hi,

I have a config file for a switch named switch, I want to send this file to an other switch called testswitch.

E:\CSCOpx\bin>cwcli config import -u admin -p xxxxx -ipaddress 10.32.71.121
-f  E:\CSCOpx\files\rme\dcma\shadow\Switches_and_Hubs\PRIMARY\switch.cfg

It failed first time, it works second time.

I had already this bug with LMS 2.6 when using deploy from gui. Tac gave me a fix.

I think that this bug is present on LMS 3.1.

Many thanks, Elisabeth

19 Replies 19

Joe Clarke
Cisco Employee
Cisco Employee

What was the 2.6 bug ID?  If you're deploying via TFTP or telnet, post a sniffer trace of the job filtering on all traffic to the switch when performing the deployment operation.

I didn't get a bugid from the tac. They send me a 2 fix which didn't correct the issue, then they have given an other one which correct this issue. I can give you the SR:608050863 - RME 4.0.5 - config deploy fail for 1st, but success for 2nd time.

I will give you traces as soon as possible.

Many thanks, Elisabeth

I can say that the bug mentioned here, CSCsg84569, is certainly fixed in LMS 3.1.  And if you're using telnet/TFTP to deploy the config, you should not be seeing any of the various SSHv2 bugs which can cause failures.  There could be a conflict in the commands being sent from the old switch to the new switch, and this is triggering a parser error on the device.  This would be visible in the sniffer trace.

You can find job folder : job 1053 has worked partially, job 1054 has worked successfully.

I took telnet protocol.

I still need to see the sniffer trace.  Since you did not enable ConfigJob debugging, it is not clear from these logs why the problem is occurring.

Customer has made test with ssh.

Even if he makes twice import, it doesn't work.

What debug I need to enable and what files do you need ?

When we make twice import with telnet, it works the second time.

With SSH, you are most likely seeing one of the known SSH bugs in LMS 3.1 (probably CSCsx24218).  The recommended solution is to upgrade to LMS 3.2, but a patch for 3.1 is available from TAC.

For the telnet failures, I need to see the sniffer traces of a failing and a working job.

First test : I want put test.cfg (Switch) on 10.32.71.122 (NewSwitch)

1. job 1097 : change hostname + clock command + change @IP, job failed partially (change hostname OK + clock command 0K, BUT IP@ NOK) :

E:\CSCOpx\bin>cwcli config import -u admin -p telindus -ipaddress 10.32.71.122

f E:\CSCOpx\files\rme\dcma\shadow\Switches_and_Hubs\PRIMARY\test.cfg

* Warning * The -p option is highly insecure and *not* recommended.

* Warning * See -u option for more details.

INFO - Devices to be attempted in the job:

10.32.71.122

INFO - The job 1097 is created

Waiting for the job results ...

..........!

- Job Status: Job Failed

Partially Failed Devices:

10.32.71.122

ERROR - CM0107 Import the config file to PRIMARY Running Config on dev

e partially successful CM0091 Check if the device prompt is available.

CM0089 Config archival successful for 10.32.71.122

SUMMARY

========

Partially Successful: import

2. job 1098 : same file now @IP change, job failed partially

E:\CSCOpx\bin>cwcli config import -u admin -p telindus -ipaddress 10.32.71.122

f E:\CSCOpx\files\rme\dcma\shadow\Switches_and_Hubs\PRIMARY\test.cfg

* Warning * The -p option is highly insecure and *not* recommended.

* Warning * See -u option for more details.

INFO - Devices to be attempted in the job:

10.32.71.122

INFO - The job 1098 is created

Waiting for the job results ...

.............!

- Job Status: Job Failed

Partially Failed Devices:

10.32.71.122

ERROR - CM0107 Import the config file to PRIMARY Running Config on dev

e partially successful CM0091 Check if the device prompt is available.

CM0056 Config fetch failed for NewSwitch Cause: TELNET: Failed to establish TE

Cause: connect timed out.122 -

Could not detect SSH protocols running on the device

Action: Check if protocol is supported by device and required device package

installed.

SUMMARY

========

Partially Successful: import

3. If I had made a new job with same config it will be ok like:

E:\CSCOpx\bin>cwcli config import -u admin -p telindus -ipaddress 10.32.71.121

f E:\CSCOpx\files\rme\dcma\shadow\Switches_and_Hubs\PRIMARY\test.cfg

Second test : I want put test.cfg (NewSwitch) on 10.32.71.121 (Switch)

1. job 1105 / change hostname + clock command + change @IP, job failed partially (change hostname OK + clock command 0K, change P@ OK but after commands are bad) :

E:\CSCOpx\bin>cwcli config import -u admin -p telindus -ipaddress 10.32.71.121 -

f E:\CSCOpx\files\rme\dcma\shadow\Switches_and_Hubs\PRIMARY\test.cfg

* Warning * The -p option is highly insecure and *not* recommended.

* Warning * See -u option for more details.

INFO - Devices to be attempted in the job:

10.32.71.121

INFO - The job 1105 is created

Waiting for the job results ...

.............!

- Job Status: Job Failed

Partially Failed Devices:

10.32.71.121

ERROR - CM0107 Import the config file to PRIMARY Running Config on devic

e partially successful CM0091 Check if the device prompt is available.

CM0056 Config fetch failed for switch Cause: TELNET: Failed to establish TELNET

Cause: connect timed out. -

Could not detect SSH protocols running on the device

Action: Check if protocol is supported by device and required device package is

installed.

SUMMARY

========

Partially Successful: import

2. job 1106: OK, but I need to change _ipaddress to 10.32.71.122 because during last import @IP was changed.

E:\CSCOpx\bin>cwcli config import -u admin -p telindus -ipaddress 10.32.71.122 -

f E:\CSCOpx\files\rme\dcma\shadow\Switches_and_Hubs\PRIMARY\test.cfg

* Warning * The -p option is highly insecure and *not* recommended.

* Warning * See -u option for more details.

INFO - Devices to be attempted in the job:

10.32.71.122

INFO - The job 1106 is created

Waiting for the job results ...

..........!

- Job Status: Job Succeeded

Successful Devices:

10.32.71.122

INFO - CM0107 Import the config file to PRIMARY Running Config on device

successful (Primary Login Succeeded

/ Primary Enable Succeeded

)

CM0089 Config archival successful for 10.32.71.122

INFO - The transport mode used is Telnet

SUMMARY

========

Successful: import

E:\CSCOpx\bin>

Many thanks, Elisabeth

The prompt is changing after you enter the hostname command.  This triggers a new session within RME so that it can relearn the new prompt.  This new session appears to be tripping up some kind of security appliance in your network which then terminates the new session, and suppresses future sessions.  The reason the job works the second time is that the prompt has already changed, and thus no new reestablishment is required.

See if the restrictions can be loosened to allow the hostname changes to work.

I don't think that we have security appliance.

For the first test, I' am sorry I think that I give you bad sniffer traces which comes from jobs1097, 1098 and others jobs.

But on Second test, I think that traces are ok.

On sniffer trace, look at thoses frames:

- frame 27033 at 13:22:27.

- frame 46468 at 13.25:50.

Thanks, Elisabeth

My diagnosis has not changed.  Look at frame 30943.  This is the TCP SYN that is generated when RME tries to reestablish the new session.  Something is blocking this connection from happening.  This is why I think some kind of firewall or IPS is interfering here.

This frame and frames which are on frame.docx comes from LMS server when LMS wants to archive config after the import.

As the switch has change IP@, LMS try to telnet on the old ip@ he tries with telnet and ssh as it is configure on LMS (see frame.docx)

I forget doc file.

While the problem I described is the same, you're right about the cause.  I missed the change of IP.  RME tries to establish a connection with the old IP.  This also explains why things work when the same config is applied in a new job (the hostname and IP do not change).

To get around this problem with the deployment only, you will need to configure TFTP as your primary protocol for Archive Mgmt Config Deploy.  However, as you pointed out, this will not help the case where RME tries to fetch the config after import.  That will still fail.  Therefore, to get a fully accurate deploy and archive, you will always need to run such jobs twice.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: