RME 4.3.1 (windows); unable to archive config of Nexus 5020 with ssh

Answered Question
Sep 6th, 2010

this seems to be the same issue as describe in this thread:

https://supportforums.cisco.com/message/3174490#3174490

- but that one is marked as resolved ... but I cannot find a solution -

So here we go again  ... :-)

RME 4.3.1; windows platform

with one customer I have the same issue with a Nexus 5020. Software version is :
Software
  BIOS:      version 1.3.0 [last: ]
  loader:    version N/A
  kickstart: version 4.2(1)N2(1)
  system:    version 4.2(1)N2(1)
  power-seq: version v1.2
  BIOS compile time:       09/08/09 [last: ]
  kickstart image file is: bootflash:///n5000-uk9-kickstart.4.2.1.N2.1.bin
  kickstart compile time:  7/28/2010 18:00:00 [07/29/2010 03:10:19]
  system image file is:    bootflash:/n5000-uk9.4.2.1.N2.1.bin
  system compile time:     7/28/2010 18:00:00 [07/29/2010 07:18:12]


Hardware
  cisco Nexus5020 Chassis ("40x10GE/Supervisor")
  Intel(R) Celeron(R) M CPU    with 2074284 kB of memory.

===============

following RME packages are installed:
    SharedNetshowSS      1.1.2      SharedNetshowSS device package
    SharedSwimMDS9000    1.6.3      SharedSwimMDS9000 device package
    SharedInventoryMDS   1.5.1      SharedInventoryMDS device package
    SharedDcmaSS         2.2.2      SharedDcmaSS device package
    Nexus                2.4        Nexus device package

===============

>>> I see the following problems with instrumentation of the Nexus Platform when looking into the debug file. The file I got is more or less the same then the one Marc posted.
The customer does not have a banner configured so the standard login procedure shows the following when login is done manually. RME automatically interpretes the first line after "Login as: " as a banner...

#######
login as: Nexus
Nexus 5000 Switch
Using keyboard-interactive authentication.
Password:
Cisco Nexus Operating System (NX-OS) Software
TAC support: http://www.cisco.com/tac
Copyright (c) 2002-2010, Cisco Systems, Inc. All rights reserved.
The copyrights to certain works contained in this software are
owned by other third parties and used and distributed under
license. Certain components of this software are licensed under
the GNU General Public License (GPL) version 2.0 or the GNU
Lesser General Public License (LGPL) Version 2.1. A copy of each
such license is available at
http://www.opensource.org/licenses/gpl-2.0.php and
http://www.opensource.org/licenses/lgpl-2.1.php

devicename#
#######

>>> and RME wants to take the last line as the prompt, resulting in a non-fatal java exception:
[line 1471 ff.]
[ Mon Aug 30  08:58:01 CEST 2010 ],DEBUG,[Thread-38],com.cisco.nm.xms.xdi.transport.cmdsvc.LogAdapter,debug,31,Learning prompt: sA[0] == 'http://www.opensource.org/licenses/lgpl-2.1.php'
[ Mon Aug 30  08:58:01 CEST 2010 ],DEBUG,[Thread-38],com.cisco.nm.xms.xdi.transport.cmdsvc.LogAdapter,debug,31,Learning prompt: sA[1] == ''
[ Mon Aug 30  08:58:01 CEST 2010 ],DEBUG,[Thread-38],com.cisco.nm.xms.xdi.transport.cmdsvc.LogAdapter,printStackTrace,51,stacktracecom.cisco.nm.lib.cmdsvc.CmdSvcException: Prompt learning failed: 'http://www.opensource.org/licenses/lgpl-2.1.php' && '' do not match.
    at com.cisco.nm.lib.cmdsvc.Session.tune(Session.java:904)
    at com.cisco.nm.lib.cmdsvc.Session.tune(Session.java:833)
    at com.cisco.nm.lib.cmdsvc.AuthHandler.connect(AuthHandler.java:267)
    at com.cisco.nm.lib.cmdsvc.OpConnect.invoke(OpConnect.java:56)
    at com.cisco.nm.lib.cmdsvc.SessionContext.invoke(SessionContext.java:299)
[...]

>> Ok, RME proceeds, but the SSH implementation (SharedDcmaSS ?) cannot extract the config and a java exception occures which leads to "Closing the session":

[ Mon Aug 30  08:58:06 CEST 2010 ],DEBUG,[Thread-38],com.cisco.nm.xms.xdi.transport.cmdsvc.LogAdapter,debug,31,Returning from Session.send('show startup-config
')

[ Mon Aug 30  08:58:06 CEST 2010 ],DEBUG,[Thread-38],com.cisco.nm.xms.xdi.transport.cmdsvc.LogAdapter,debug,31,in trimPrompt(), prompt == ''

[ Mon Aug 30  08:58:06 CEST 2010 ],DEBUG,[Thread-38],com.cisco.nm.xms.xdi.pkgs.LibDcma.persistor.CliOperator,fetchConfig,490,Failed to get the start tag-Building Configuration ... in the configuration.com.cisco.nm.xms.xdi.ags.config.ConfigTransportException: Failed to get the start tag-Building Configuration ... in the configuration.

    at com.cisco.nm.xms.xdi.pkgs.SharedDcmaSS.transport.SSCliOperator.extractConfig2Buffer(SSCliOperator.java:176)

    at com.cisco.nm.xms.xdi.pkgs.LibDcma.persistor.CliOperator.fetchConfig(CliOperator.java:436)
    at com.cisco.nm.xms.xdi.pkgs.LibDcma.persistor.CliOperator.fetchConfig(CliOperator.java:510)
    at com.cisco.nm.xms.xdi.pkgs.LibDcma.persistor.SimpleFetchOperation.performOperation(SimpleFetchOperation.java:61)
    at com.cisco.nm.xms.xdi.pkgs.LibDcma.persistor.ConfigOperation.doConfigOperation(ConfigOperation.java:111)

    at com.cisco.nm.xms.xdi.pkgs.SharedDcmaSS.transport.SSConfigOperator.fetchConfig(SSConfigOperator.java:65)

    at com.cisco.nm.rmeng.dcma.configmanager.ConfigManager.updateArchiveForDevice(ConfigManager.java:1315)

    at com.cisco.nm.rmeng.dcma.configmanager.ConfigManager.performCollection(ConfigManager.java:3291)

    at com.cisco.nm.rmeng.dcma.configmanager.CfgUpdateThread.run(CfgUpdateThread.java:27)

[ Mon Aug 30  08:58:06 CEST 2010 ],DEBUG,[Thread-38],com.cisco.nm.xms.xdi.pkgs.LibDcma.persistor.SimpleFetchOperation,performOperation,62,FetchStatus - FAILURE for Protocol SSH for device n.n.n.n


>> As telnet and tftp are not allowed the config cannot be archived (Customer reports no problems with telnet...)
The config itself starts and ends with the following lines:

#####################
devicename# show startup-config

!Command: show startup-config
!Time: Mon Sep  6 16:41:02 2010
!Startup config saved at: Mon Aug 16 15:41:39 2010

version 4.2(1)N2(1)
no feature telnet
no telnet server enable
no feature http-server
cfs eth distribute
feature udld
feature interface-vlan
feature lacp
feature vpc
feature lldp
feature vtp
[...]

interface mgmt0
  shutdown force
  shutdown force
  no snmp trap link-status
  no snmp trap link-status
clock timezone MEZ 1 0
clock summer-time MEZS 5 sun mar 02:00 5 sun oct 03:00 60
line console
boot kickstart bootflash:/n5000-uk9-kickstart.4.2.1.N2.1.bin
boot system bootflash:/n5000-uk9.4.2.1.N2.1.bin
ip route 0.0.0.0/0 172.16.4.1
vtp mode transparent
vtp domain sap
logging server x.x.x.x 7 use-vrf default
logging server y.y.y.y 7 use-vrf default


devicename#

#############


For me it looks like as a bug in the ssh implementation in RME, but I cannot find a bug id on CCO ....

I have this problem too.
0 votes
Correct Answer by fujitsuservices about 3 years 4 months ago

Hi

I'm having this issue but my platform is Solaris - is their any corresponding "fix" for my platform?

Pulling my hair out here!!

Thanks

Correct Answer by Joseph Clarke about 3 years 7 months ago

Actually, this is a timing issue, and it's easily fixed without a patch.  In LMS 3.2, we now provide a user-editable cmdsvc.properties file under NMSROOT/objects/cmf/data.  Edit this file, and change TuneSleepMillis to 500 or 1000 (you'll need to uncomment this).  Then restart ConfigMgmtServer:

pdterm ConfigMgmtServer

pdexec ConfigMgmtServer

That should fix this problem.

  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 4.5 (5 ratings)
Correct Answer
Joseph Clarke Tue, 09/07/2010 - 21:23

Actually, this is a timing issue, and it's easily fixed without a patch.  In LMS 3.2, we now provide a user-editable cmdsvc.properties file under NMSROOT/objects/cmf/data.  Edit this file, and change TuneSleepMillis to 500 or 1000 (you'll need to uncomment this).  Then restart ConfigMgmtServer:

pdterm ConfigMgmtServer

pdexec ConfigMgmtServer

That should fix this problem.

Martin Ermel Thu, 09/09/2010 - 07:16

thanks Joe for your quick and precise help!
the customer changed the value for TuneSleepMilli from 50 to 500 and the problem has gone.

Note: one should also consider BugId CSCte98853 for Nexus configuration archive

==============================================
CSCte98853 Bug Details     
RME cannot archive configs for NEXUS 5000 and 7000 devices
Symptom:

RME 4.3 doc says NEXUS 5000/7000 are all supported, but automated actions for config archives do not work. This is because the NEXUS devices use a different form of syslog format:

"%VSHD-5-VSHD_SYSLOG_CONFIG_I:"

RME's existing Config_Fetch automated action should add this syslog in the future versions.


Conditions:

This affects all RME versions up to 4.3.1.


Workaround:

Steps to add the message format:

a) Navigate to Tools --> Syslog --> Automated Actions
b) Select the "Config Fetch" and click on edit
c) Don't change on the next screen. Click "next" to proceed to
"Define Message Type" wizard
d) Click on "Add" button then fill the following details as follows:

a. Facility - VSHD
b. Sub-facility - *
c. Severity - 5
d. Mnemonic - VSHD_SYSLOG_CONFIG_I
e. Description - *

Then restart the SyslogAnalyzer daemon
==========================================================================

Correct Answer
fujitsuservices Mon, 12/06/2010 - 07:56

Hi

I'm having this issue but my platform is Solaris - is their any corresponding "fix" for my platform?

Pulling my hair out here!!

Thanks

Martin Ermel Mon, 12/06/2010 - 08:09

the solution Joe provided above is for solaris also, i.e. if you are running RME 4.3.1 go ahead and change the settings in cmdsvc.properties file under NMSROOT/objects/cmf/data as described above and restart ConfigMgmtServer.

also be sure to have the latest device packages for Common Services and RME installed.

Sven Hruza Thu, 09/08/2011 - 09:18

Thanks Martin and Joe!

Great solution for my problem with a Nexus 4000.

Sven

Actions

Login or Register to take actions

This Discussion

Posted September 6, 2010 at 10:28 PM
Stats:
Replies:5 Avg. Rating:4.5
Views:2338 Votes:0
Shares:0
Tags: rme, nexus, config, archive
+

Related Content

Discussions Leaderboard