Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 
New Member

LMS 3.2 - Syslog-triggered Config-Collection

Hi all,

what exactly is collected when RME detects a config-change via Syslog?

Does RME only collect the newest running-config, or is also the newest startup-config


As scenario: a user performes a config-change on a cisco-device and after that does

                   a copy running start

What after that scenario is collected and visible on CW2k-Server

- newest running and newest startup-config

- only newest running-config and a formerly collected startup-config

Thanks for any ideas



Re: LMS 3.2 - Syslog-triggered Config-Collection

RME will trigger a collection for both startup and running config based on various  criteria that is detected via syslog and if changes are made. Table 15-1 and 15-2 have a list of messages that will trigger an inventory collection and config fetch operation.

Table 15-1 and 15-2 list of messages that trigger collection and fetch of configuration:

Startup configs are only collected when selected during the archive job otherwise, its just the running config that gets archived. In the users guide for RME 4.3, there is a section called "How Running Configuration is Archived" which is a workflow how archiving works.

New Member

Re: LMS 3.2 - Syslog-triggered Config-Collection

Hi Nael,

thanks for your feedback.

As we want to use the out-of-sync feature in RME, not fetching startup-config while detecting a

config-change via syslog-messages brings up an inconsistency.

So (true) diffs between running and startup-config can only be found/displayed after a config-collection.

Are there any plans to also fetch startup-config while detecting a config-change via syslog-messages?

Thanks for any feedback


Re: LMS 3.2 - Syslog-triggered Config-Collection

Hi Lothar,

RME does fetch startup and running config when IOS triggers a config change syslog message from the device.

Re: LMS 3.2 - Syslog-triggered Config-Collection

Hi Lothar,
The out-of-sync report is a really good feature but I would say it only shows potential out-of sync devices.
As Nael said and Joe pointed out in this thread ( RME collects both running and start-up when triggerd by a syslog message.
The crucial point is the timeline of the process that detects the out-of-sync. If you leave the config modus of an IOS device, the syslog message will be generated immediately and the config will be collected usually in the next minute. But when are you typing the "wr mem" ? So it could be, that RME is faster then you and gets both running and start-up config archived before you have saved the current changes - whith results in "false" positives, i.e. the archived startup is not in sync with the latest archived running.

You have mad your changes and when you logout of the device some minutes after the change you usually issue the "wr mem". Which will sync running and startup - but RME does not see this and has yet marked the device as being out-of-sync. The problem is, that "wr mem" or "copy running start" does not generate a syslog message which could trigger the collection in RME..

Config Change Polling would be the automatic feature of RME that should delete these false positives, as it looks at both, the running and the startup-config (RME > Admin > Config Mgmt > Archive Mgmt > Collection Settings)

In the doc Nael mentioned there is also a good description of the "timestamps" assosiated with the archived configs:

CreatePlease to create content