What does this error mean? I'm on Solaris 9 and RME 4.0.6. If devices is not reachable as this error says then why it was able to fetch the config? Can someone explain the error and possible fix?
CM0057 PRIMARY RUNNING Config fetch SUCCESS, archival failed for 10.1.15.5 Cause: CM0002: Could not archive config Cause: Device may not be reachable, may be in suspended state or credentials may be incorrect. Action: Verify that device is managed, credentials are correct and file system has correct permissions. Increase timeout value, if required. Action: Verify that archive exists for device.
This typically indicates some kind of archive damage. For example, a file was deleted from the file system without a corresponding database update. The solution is usually to remove the device from RME, then re-add it.
I would think so too, but what kind of archive damage would that be? is it fixable?
It is very painful to delete/add devices, any workaround or any patch that can fix the archive damage problem? Can I prevent it from occuring in the future. Lates changes were made that I installed RME care package and ever since I have seen the issue. Any help to this would be great.
The only workaround is to restore a known good backup. Beyond that, if a file is deleted, it's deleted.
Very rarely, the error in this case is correct, and the file system either has the wrong permissions, or the job took longer than the job results timeout. You should check these things before resigning to deleting a re-adding the device.
The best preventative for archive deletions is regular backups.
I have checked device credentials and all the credential are correct but archive still fails. I even increased the time out but that didn't help. Latest archive is seen from the date when I originally installed the RME care package. Only WO I find is to delete/add devices. Will RME4.0.7 help fix this issue?
There will most likely not be an RME 4.0.7. And my RME care package has nothing to do with this. We have not been able to reproduce this locally without someone physically deleting one of the archive files, so there is no bug that describes this. You can scan the dcamservice.log for any past errors which may have contributed to this problem, but if something happened to the archive outside of RME, it would not be documented there.
so you are saying that files under /var/adm/CSCOpx/files/rme/dcma/shadow may have been deleted? when I go under this directory I see the archive file for the devices that are giving me errors and they date a month old again, the date when I installed care package. I have logroation enabled but it only rotates the logfiles. No one has access to CiscoWOrks files system but me so I doubt if someone deleted the archive file. When I check the dcmaservice.log file I see some errors that says "Version does not exist in archive $1 Cause: Version may have been deleted" Could this be that system is just not recognizing the existing file in the folder?
The shadow directory has nothing to do with this. The files in question are found under /var/adm/CSCOpx/files/rme/dcma/devfiles. The directories there are indexed by RME device ID. One of those files must have been deleted.
Hi everyone, I would like to thank you in advance for any help you can provide a newcomer like myself!
Im studying the 100-105 book by Odom and am currently on the topic of Port security. I purchased a used 2960 and I'm trying to follow a...
While deploying a number of 18xx/2802/3802 model access points (APs), which run AP-COS as their operating platform. It can be observed on some occasions that while many of their access points were able to join the fabric WLC withou...
I am going to design and build an LAN network under a tunnel underground with long distance between the switches.
I will have 2 Catalyst switches and 8 Industrial IE3000, and they will be connected with fiber.
For now I am planning on use Layer-2 s...