i opened a TAC to resolve the problem. however yesterday after a crash, my 6500 config mgmt is not working. i.e. it is not taking configs of the same. it provides an error for the same as ....
1. PRIMARY RUNNING Aug 11 2009 15:57:55 CM0056 Config fetch failed for RIMS-1 Cause: CM0204 Could not create DeviceContext for 1758 Cause: CM0206 Could not get the config transport implementation for 10.4.22.254 Cause: CM0202 Could not access 10.4.22.254 via SNMP. Action: Check the Read Community string Action: Check if required device packages are available in RME. Action: Check if protocol is supported by device and required device package is installed.
i even checked all the credentials. all are fine. I checked the ACS but i could not find any administration record for that.
As I said on the other thread, this looks like a package problem. It does not have anything to do with the inventory patch. When you say the server crashed, exactly what happened? Did you have to reinstall LMS?
As I said in the other thread, I need the list of contents under NMSROOT/MDC/tomcat/webapps/rme/WEB-INF/lib/pkgs and NMSROOT/www/classpath/com/cisco/nm/xms/psu/pkgs/rme along with the sysObjectID from this switch.
I read ur previous thread, where you suggested copying all the pkg's from NMSROOT/www/classpath/com/cisco/nm/xms/psu/pkgs/rme to NMSROOT/MDC/tomcat/webapps/rme/WEB-INF/lib/pkgs and check for the issue. Copied but the problem survived. even all the device updates are done for RME. The list i can provide tomorrow morning.
The OID probably is .126.96.36.199.188.8.131.52.283
There is another one which i cant remember at the moment and it ends with a .22 but the attachment might help.
any idea on what the problem may be.
The sysObjectID should be supported by the Cat6000IOS package. Verify all the permissions on the packages in NMSROOT/MDC/tomcat/webapps/rme/WEB-INF/lib/pkgs directory so that casuser has access. When you post the list of contents, also post the NMSROOT/MDC/tomcat/logs/stdout.log and stderr.log.
Compress the stdout.log, then post it. As for packages, I see one potential problem. Where did you get the patch for CSCta02155? What are the permissions of the files in the MDC directory. Post the output of the DOS command "CACLS *" within that directory.
There is certainly a problem with your packages. You're missing the SharedSwimGSS.zip package, and there is a problem with your SharedSwimIOS.zip package.
Since you don't know where you go the Netconfig patch, back that out by copying SharedNetconfigIOS.zip-CSCta02155-0 to SharedNetconfigIOS.zip. Then, go to Common Services > Software Center > Device Update, and download and install all available RME and Common Services device updates. If that fails, your package repos may be damaged to the extent you will need to talk to TAC to get the recovery procedure.
Essentially, TAC will provide you will a zip file containing all of the up-to-date RME 4.2 device packages, and instructions on how to restore your two RME package repositories. After that, you should be able to archive configs from your 6500.
I checked both the files and found the size and dara contents of both the files to be same.
even checked with another server and found the contents and size to be the same.
but how come i got the bug patch, i dont know.
Even with that patch sorted out, you still have the issue of the other two packages I mentioned. You will still need to either update your package repository from Cisco.com; or, failing that, get a good up-to-date package set from TAC.
Once your package repositories are fixed, config archive will start to work again.
I already updated all the packages as suggested. but then after the restart of the service, it didn't work. I noticed that the in the failure description the protocol shows as unrecognised/ not applicable but the protocol order to be SSH, telnet. I also did a packet capture and found that it is telnetting / SSH to the 6500 switch but is running commands in an unprivileged mode not in enable mode. even i could not find an enable command.
After these i added TFTP and it didn't work out at first. but somehow after 3 to 4 hours it suddenly started working giving protocol as TFTP, and protocol order as SSH, Telnet, TFTP. config archives for 6500 started flowing in.
Not without seeing debug logs. It would also be helpful to see your sniffer traces. But, if TFTP works, then the package problem must have been resolved.
no the error that i posted earlier was resolved somehow autometically. i did not do anything except restarting the daemon.
the error which i was getting was
*** Device Details for 10.4.25.254 ***
Protocol ==> Unknown / Not Applicable
Selected Protocols with order ==> Telnet
CM0151 PRIMARY STARTUP Config fetch failed for 10.4.25.254 Cause: Failed to fetch the configuration. Check the dcmaservice.log for details. Action: Check if protocol is supported by device and required device package is installed. Check device credentials. Increase timeout value, if required.
CM0151 PRIMARY RUNNING Config fetch failed for 10.4.25.254 Cause: Failed to fetch the configuration. Check the dcmaservice.log for details. Action: Check if protocol is supported by device and required device package is installed. Check device credentials. Increase timeout value, if required.
This looks to be the same problem. If you cannot post the sniffer trace you took from this device, I recommend you open a TAC service request so additional analysis can be done. Ideally, I would want to see the new stdout.log, sniffer trace, and dcmaservice.log with ArchiveMgmt Service debugging enabled after reproducing this error.
This does help. It points to a package problem persisting. Instead of using the RMEIOS code, your switch is causing RME to invoke the generic device code. At this point, I think contacting TAC will allow you to fix this problem quickly. As I said, I have written up the procedure for them on how to recover this kind of package problem. Once you contact them, you should be able to get back up and running quite quickly.
Contacted TAC already. She has been provided the logs but could not come to a conclusion as to what is going on. The case is open and we will keep monitoring this as well. She also informed us that the logs, pkt capture output and debugs will be forwarded to the developers for more investigation on this.