RME and 6509

Unanswered Question
Aug 4th, 2009


6509 has 12.2(33)SXI and CW LMS 3.1.

I cannot capture the details of the 6500 switches in the RME. while doing snmp testing and credential testing it shows fine with no problem. it says device side problem.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Joe Clarke Wed, 08/05/2009 - 21:30

I cannot post code to the forum. This patch is only available from TAC.

Rajiv Dasmohapatra Tue, 08/11/2009 - 03:17

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 Cause: CM0202 Could not access 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.

pl help.

Joe Clarke Tue, 08/11/2009 - 09:50

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?

Rajiv Dasmohapatra Tue, 08/11/2009 - 10:17

Actually, we did a restorebackup.pl and after that the problem arised.

WE are able to get the inventory from the 6500 switches but not the configs irrespective of the IOS.

we did many things to check out.

attached is the files which you may need to see.

pl help.

Joe Clarke Tue, 08/11/2009 - 10:25

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.

Rajiv Dasmohapatra Tue, 08/11/2009 - 11:40

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 .

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.

Joe Clarke Tue, 08/11/2009 - 12:46

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.

Rajiv Dasmohapatra Tue, 08/11/2009 - 20:59

Sending you the logs. three logs are attached but the stdout.log is ...well large enough. 10 Mb to be presice. pl let me know which part to capture.

Joe Clarke Tue, 08/11/2009 - 21:06

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.

Rajiv Dasmohapatra Tue, 08/11/2009 - 22:03

i did not patch the RME except for the bug patch you suggested.

all the permissions are provided to casuser in the directory.

attached is the files.

Joe Clarke Tue, 08/11/2009 - 23:18

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.

Rajiv Dasmohapatra Wed, 08/12/2009 - 01:51

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.

Joe Clarke Wed, 08/12/2009 - 07:40

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.

Rajiv Dasmohapatra Wed, 08/12/2009 - 09:52

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.

any clue?

Joe Clarke Wed, 08/12/2009 - 10:09

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.

Rajiv Dasmohapatra Wed, 08/12/2009 - 10:20

if you say so. but then, if i remove TFTP from the transport settings. the problem revert itself back.

Rajiv Dasmohapatra Wed, 08/12/2009 - 10:30

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 ***

Protocol ==> Unknown / Not Applicable

Selected Protocols with order ==> Telnet

Execution Result:


CM0151 PRIMARY STARTUP Config fetch failed for 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 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.

Joe Clarke Wed, 08/12/2009 - 10:32

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.

Rajiv Dasmohapatra Wed, 08/12/2009 - 10:50

I cannot provide you with all the logs as its not with me now. however i can provide with the problematic part of dcmaservice logs. its attached.

Joe Clarke Wed, 08/12/2009 - 10:53

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.

Rajiv Dasmohapatra Wed, 08/12/2009 - 11:05

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.

Joe Clarke Wed, 08/12/2009 - 11:39

Have her contact me directly, and I will provide the required instructions.


This Discussion