cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
763
Views
0
Helpful
5
Replies

RME 4.1.1 Not getting full startup configurations

e-bartlett
Level 1
Level 1

Hello,

I have an issue with RME 4.1.1 getting the complete startup configurations for 4 of my devices. Two of them are 3845's and two are 4506's.

I have enabled ArchiveMgmt debugs and have observed that:-

with the 3845's when RME gets the startup configuration, it sees the configuration line “boot-end-marker” , truncates this to “boot-end” and does not get the rest of the configuration. It does not have an issue with this configuration line when getting or parsing the running configuration.

with the 4506's when RME gets the startup configuration, it sees the configuration line “vlan internal allocation policy ascending”, truncates this to “vlan internal allocation policy ascend” and does not get the rest of the configuration. It does not have an issue with this configuration line when getting or parsing the running configuration.

We have several other 3800's and 4500's deployed with the same IOS versions (startup contains the same configuration lines) which RME successfully gets the full startup configurations. I have deleted and re-added the affected devices but this has not resolved the issue.

This problem occurred after I applied the LMS 3.0 Dec 2007 Updates. The OS is Solaris 10.

Any assistance in resolving this issue would be appreciated.

1 Accepted Solution

Accepted Solutions

Joe Clarke
Cisco Employee
Cisco Employee

This COULD be my bug, CSCsm71678, but I typically see an error fetching the config, and not a truncated config. In some cases I did see zero-byte files in the shadow directory, so I suppose this problem could be a result of that bug.

The catalyzing factor is the size of the config in combination with its contents, and the delay in the network. If the config is too big, or the network has a lot of delay, this problem will occur. It only affects interactive config fetches (i.e. telnet or SSH). TFTP should not be affected.

If you are using telnet or SSH to fetch the configs, I recommend you open a TAC service request to get the patch for this bug. At the very least, TAC can get the configs and dcmaservice.log for further analysis.

View solution in original post

5 Replies 5

Joe Clarke
Cisco Employee
Cisco Employee

This COULD be my bug, CSCsm71678, but I typically see an error fetching the config, and not a truncated config. In some cases I did see zero-byte files in the shadow directory, so I suppose this problem could be a result of that bug.

The catalyzing factor is the size of the config in combination with its contents, and the delay in the network. If the config is too big, or the network has a lot of delay, this problem will occur. It only affects interactive config fetches (i.e. telnet or SSH). TFTP should not be affected.

If you are using telnet or SSH to fetch the configs, I recommend you open a TAC service request to get the patch for this bug. At the very least, TAC can get the configs and dcmaservice.log for further analysis.

Thank you for the information.

A TAC case is being raised and I will let you know how we get on.

Hi,

Received the patch from TAC, applied it and all is now looking okay.

Thank You for your help

Hi e-bartlett,

I have the same problem as you, but with another device (3750 stack and Cat 4000).

You received the patch from TAC. Could you send me this patch ?

Thank you for your help

Bests Regards

Sam

You really need to contact the TAC. We need to track this internally, and we need to be the ones to provide you with the code.

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: