04-18-2008 04:29 AM
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.
Solved! Go to Solution.
04-18-2008 08:08 AM
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.
04-18-2008 08:08 AM
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.
04-21-2008 02:33 AM
Thank you for the information.
A TAC case is being raised and I will let you know how we get on.
04-21-2008 08:15 AM
Hi,
Received the patch from TAC, applied it and all is now looking okay.
Thank You for your help
04-21-2008 09:28 PM
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
04-21-2008 10:15 PM
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.
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: