06-05-2008 06:05 AM
Hi,
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,
Elisabeth
06-05-2008 08:11 AM
06-05-2008 11:01 AM
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,
Elisabeth
06-05-2008 12:07 PM
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?
06-11-2008 05:34 AM
Hi,
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
Password:
adv_c02_1_2018>ena
Password:
adv_c02_1_2018#copy flash:vlan.dat tftp:
Address or name of remote host []? 141.1.1.28
Destination filename [vlan.dat]?
!!
1424 bytes copied in 0.028 secs (50857 bytes/sec)
adv_c02_1_2018#
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.
06-11-2008 05:52 AM
The only file I can think of where LMS defines its IP addr is /opt/CSCOpx/lib/vbroker/gatekeeper.cfg, specifically
#vbroker.gatekeeper.backcompat.callback.host=
vbroker.gatekeeper.backcompat.callback.host=xx.xx.xx.xx
#vbroker.se.exterior.host=
vbroker.se.exterior.host=xx.xx.xx.xx
#vbroker.se.iiop_tp.host=
vbroker.se.iiop_tp.host=xx.xx.xx.xx
#vbroker.se.interior.host=
vbroker.se.interior.host=xx.xx.xx.xx
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.
06-20-2008 02:24 AM
Hi,
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,
[ fr jun 20 12:18:44 CEST 2008 ],FATAL,[Thread-291],com.cisco.nm.xms.xdi.pkgs.LibDcma.persistor.CliOperator,
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.
at com.cisco.nm.xms.xdi.pkgs.SharedDcmaIOS.transport.IOSCliOperator.
at com.cisco.nm.xms.xdi.pkgs.SharedDcmaIOS.transport.CatIOSSwitchCliOperator.
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.
06-20-2008 10:04 AM
"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.
07-01-2008 05:36 AM
Hi,
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)
adv_p2_1_1024#}
????
07-09-2008 01:55 AM
Hi,
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.
Regards,
Elisabeth
07-09-2008 05:58 AM
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.
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: