LMS 2.6 / RME : VLAN Config fetch is not supported using TFTP

Unanswered Question
Jun 5th, 2008


Customer has an issue with vlan config archive for several devices.

I ask him to take a sniffer trace between the LMS server and a device.

We can see that LMS can telnet correctly to device, but when lms give the tftp server IP address, he fails he gives 12 rather the good IP address.

Is it a bug ?

Many thaks for your help,


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
ebezombes Thu, 06/05/2008 - 11:01

I am not sure that this thread is similar to my issue.

With the sniffer trace, I can see that:

LMS telnet to the device but the tftp server ip is wrong so the transfert cannot be done.

Here, you can find the telnet connexion.

Before this issue, vlan config archive was ok for all devices.

Many thanks,


yjdabear Thu, 06/05/2008 - 12:07

Not sure what to make of this invalid tftp host address, since it's obviously not running PIX OS where one could typo when configuring a default tftp server.

You may want to enable ArchiveMgmt Service debugging under RME => Admin => System Preferences => Loglevel Settings, and run a config fetch job against one or more of these failing devices, so that debug info can be captured in /var/adm/CSCOpx/log/dcmaservice.log.

Were the failing devices working fine before? Any changes on the devices or the LMS side?

ebezombes Wed, 06/11/2008 - 05:34


I can see on debug file that tftp IP is wrong : 12.

Customer tries to download vlan.dat from device to lms server :

User Access Verification




adv_c02_1_2018#copy flash:vlan.dat tftp:

Address or name of remote host []?

Destination filename [vlan.dat]?


1424 bytes copied in 0.028 secs (50857 bytes/sec)


Is there a file where lms defines his IP address ? May be the file is corrupt ?

Customer told me that there was not modification on devices, but they have patch lms.

Before, it uses to be work fine.

yjdabear Wed, 06/11/2008 - 05:52

The only file I can think of where LMS defines its IP addr is /opt/CSCOpx/lib/vbroker/gatekeeper.cfg, specifically









You'd need to restart dmgtd after editing this file.

That being said, I've never encountered getting the IP addr there screwed up just by patching LMS.


I have a similar problem, but when I look at the debug information in the dcmaservice.log file there is some Java problems:

[ fr jun 20 12:18:44 CEST 2008 ],FATAL,[Thread-291],com.cisco.nm.xms.xdi.pkgs.LibDcma.persistor.CliOperator,,148,Failed to get CmdSvc from DeviceContext....

[ fr jun 20 12:18:44 CEST 2008 ],FATAL,[Thread-291],com.cisco.nm.xms.xdi.pkgs.LibDcma.persistor.CliOperator,,149,Could not detect protocols running on the devicejava.lang.Exception: Could not detect protocols running on the device

at com.cisco.nm.rmeng.util.rmedaa.RMEDeviceContext.getSshProtocols(RMEDeviceContext.java:1939)

at com.cisco.nm.rmeng.util.rmedaa.RMEDeviceContext.getSshCmdSvc(RMEDeviceContext.java:1827)

at com.cisco.nm.rmeng.util.rmedaa.RMEDeviceContext.getCmdSvc(RMEDeviceContext.java:1593)

at com.cisco.nm.xms.xdi.pkgs.LibDcma.persistor.CliOperator.(CliOperator.java:145)

at com.cisco.nm.xms.xdi.pkgs.SharedDcmaIOS.transport.IOSCliOperator.(IOSCliOperator.java:100)

at com.cisco.nm.xms.xdi.pkgs.SharedDcmaIOS.transport.CatIOSSwitchCliOperator.(CatIOSSwitchCliOperator.java:55)

at com.cisco.nm.xms.xdi.pkgs.SharedDcmaIOS.transport.CatIOSSwitchConfigOperator.getOperator(CatIOSSwitchConfigOperator.java:38)

at com.cisco.nm.xms.xdi.pkgs.LibDcma.persistor.OperatorCacheManager.getOperatorForDevice(OperatorCacheManager.java:50)

at com.cisco.nm.xms.xdi.pkgs.LibDcma.persistor.ConfigOperation.doConfigOperation(ConfigOperation.java:99)

at com.cisco.nm.xms.xdi.pkgs.SharedDcmaIOS.transport.IOSConfigOperator.fetchConfig(IOSConfigOperator.java:71)

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

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

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

[ fr jun 20 12:18:44 CEST 2008 ],DEBUG,[Thread-291],com.cisco.nm.xms.xdi.pkgs.LibDcma.persistor.ConfigOperation,doConfigOperation,101,Failed to get ConfigOperator for Protocol:SSH for device .........

Any advice would be most helpful.

yjdabear Fri, 06/20/2008 - 10:04

"Could not detect protocols running on the device" is a pretty commonly seen error, which is mostly associated with devices either refusing SSH connection or being unreachable.

ebezombes Tue, 07/01/2008 - 05:36


File /opt/CSCOpx/lib/vbroker/gatekeeper.cfg is ok.

I don't understand RME archives runing and startup config but no vlan config.

In dcmaservice.log, I can see that tftp ip address is bad:

],DEBUG,[Thread-1461],com.cisco.nm.xms.xdi.transport.cmdsvc.LogAdapter,debug,31,Returning from interact('copy flash:vlan.dat tftp:'):


Address or name of remote host []? 12

?Invalid host address or name

%Error parsing filename (Invalid IP address or hostname)



ebezombes Wed, 07/09/2008 - 01:55


I have resolved the issue. In fact customer had a wrong value for RME device attribut : Natted RME IP Address value was 12 that is why the sniffer trace shows this value. I ask him to change the value to RME server IP and now it works.

There is a similar bug CSCsg42069 : vlan.dat fetch fails due to bad RME ID.



yjdabear Wed, 07/09/2008 - 05:58

Thanks for bringing a closure to this issue. I take it that the customer is not running RME 4.0.6 then, since Bug Tool says CSCsg42069 is fixed in that version? I had never noticed Natted RME IP Address was tucked away there.


This Discussion