RME 4.1.1 Not getting full startup configurations

Answered Question
Apr 18th, 2008

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.

I have this problem too.
0 votes
Correct Answer by Joe Clarke about 8 years 9 months ago

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Correct Answer
Joe Clarke Fri, 04/18/2008 - 08:08

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.

e-bartlett Mon, 04/21/2008 - 02:33

Thank you for the information.

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

e-bartlett Mon, 04/21/2008 - 08:15

Hi,

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

Thank You for your help

s.fasel Mon, 04/21/2008 - 21:28

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

Joe Clarke Mon, 04/21/2008 - 22:15

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.

Actions

This Discussion