cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1728
Views
35
Helpful
12
Replies

CiscoWorks RME Config Archive questions

wilson_1234_2
Level 3
Level 3

J,

A couple of questions:

This shows up on the RME home page, under Recently Completed Jobs:

I have a Archive poll job configured along with an Archive update job.

The archive poll runs before the update job.

The Archive update completes successfully on 27 items, but the update job fails with one item being only partially successful.

The reason on the item is:

Error polling for change on Primary Startup Config, not fetching the config.

It is using telnet as the protocol.

Whay would RME not be able to get the startup config if it can get everything else?

This shows up under Collection Status:

Inventory 27 Items

Config Archive:

27 success

0 failed

0 partially successful

4 out of sync

On the out of sync items, if you check them you can select "Sync on Device"

Is this recommended to do?

Also, where do I check the config archive to make sure they are actually getting archived?

In addition, if I have a router fail, is there a procedure to restore the existing config to the new router with CiscoWorks?

12 Replies 12

Joe Clarke
Cisco Employee
Cisco Employee

There could be a few reasons for not being able to poll for changes on the startup config. The best bet is to enable ArchiveMgmt debugging under RME > Admin > System Preferences > Loglevel Settings, then reproduce the problem, and check the dcmaservice.log for errors. A sniffer trace filtering on the problem device may also be helpful.

Syncing the configs is always a good thing to do to make sure you have the latest archived config from every device.

The best way to check if the config s being archived is to search your archive by device, and verify the date of the config matches the date of the config on the device (i.e. seen when you do a show run).

If you need to replace a router, you can either use Config Editor in Merge mode to push the entire archived config back to the new device (once it is managed in RME), or manually push the latest config from the shadow directory. The shadow directory will always store the latest config on the device that RME has archived, and is intended for use outside of RME. As such, all of the files under the shadow directory are indexed by device display name. The shadow directory can be found under NMSROOT\files\rme\dcma\shadow on Windows and /var/adm/CSCOpx/files/rme/dcma/shadow on Solaris.

As always thanks for the great answers.

J,

When looking at the actual devices that show out of sync in RME, the device shows the startup and run being the same.

It is in RME that the startup config is different than the run config.

Is there an old startup config cached somewhere?

Right, you need to sync whichever is different on the device to RME. If one of the configs is failing to sync, then you need to troubleshoot that using the dcmaservice.log.

So, yes, RME has an old startup config archived for the device.

So the "Sync to Device" is not actually syncing the configs on the device, just the configs in the Archive Manager?

Correct. Sync in this case means, "sync the config on the device with the RME archive."

Hi,

You also need to be aware that if you are running port security in "sticky" mode, the mac address learned on the switch port will be added to the running configuration, which is now different to the start-up configuration, so RME does a poll and see's the configs are out of sync, now these sort of dynamic running config changes can be excluded, another example is the ntp clock period changes periodically which is also a difference between the running and start-up configs.....RME can exclude these sort of dynamic changes.

Cheers

J,

I have notice that in DFM, there are a total of 27 devices,

24 are questionable and 3 are known.

Does this have to do with the fact that they were manually put in rather than allowing them to be Discovered?

And how do I correct it?

Questioned means that DFM could not communicate with the devices via either ICMP or SNMP. Check that the SNMP credentials are correct for the devices in DCR, and make sure the address by which DFM knows the device is ICMP reachable from the DFM server.

J,

All of that is correct, I am getting successful config archives and software report jobs, I can see everything in campus manager and Cisco view.

Everything is showing up everywhere.

How often does the DFM check for communication?

It depends on how you've configured DFM. If the device goes into a question state, never again. You will have to rediscover the device in DFM. Else, it depends on the various polling parameters in DFM.

If you are going to go deep into DFM, you should start a new thread for that.

Ok,

I will start another thread, thanks.

Getting Started

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: