Question on syslog triggered config collection and OutOfSnc Report

Answered Question
Feb 14th, 2008

is it correct that the syslog triggered config collection only looks for changes in the running-config and the vlan config and NOT the startup-config ?

If this is truth this is the reason for false positives in OutofSync Report in RME > Config Mgmt > Archive Management

at least, if the process that checks if the running-config has changed recognizes a change and triggers the archive update of the running-config this could also trigger the archive update of the startup-config without the control of its need. But thus could prevent the false positives.

the amount of perhaps unnecessary network traffic because of unchanged startup-configs could be disregarded to the amount of work false positives can produce...

Correct Answer by Joe Clarke about 9 years 1 week ago

What version of RME? RME 4.0.6 and 4.1.1 attempt to fetch both running and startup configs on reception of a syslog config change message. Polling is done before fetching to prevent unnecessary traffic.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Correct Answer
Joe Clarke Thu, 02/14/2008 - 11:32

What version of RME? RME 4.0.6 and 4.1.1 attempt to fetch both running and startup configs on reception of a syslog config change message. Polling is done before fetching to prevent unnecessary traffic.

Martin Ermel Thu, 02/14/2008 - 11:47


its RME 4.0.5 - thought this server has the latest patches also - but that is oviously not the fact...

thanks for your fast response!

miheg Fri, 02/15/2008 - 06:13

False positives? What do you mean exactly?

Like the devices in the attachment?



Martin Ermel Fri, 02/15/2008 - 08:16

Hi Michael,

no that is not what I meant - whereas I had some of them too. But I didn' t put much work into it to find out the reason. I just triggered a real SyncArchive job for them with the check-box 'Fetch startup config" marked - and they were gone. - I will wait if they come back...

here is what I observed:

after a config change and a 'write mem' the config collection get triggerd by the syslog message arriving in the SyslogAnalyzer. RME updated its archive with only the running-config. The Out-of-Sync process then compared the new Running-config with the archived Startup-config (which was not updated) - and found a diff. So the device was listed in the OutOfSync Report and you could even see the differences by clicking on the diff-Icon.

But if you telnet to the device and look for the diff between running and startup config there was no diff (as I did a write mem...) - it is just that the startup did not get updated in the archive.

- that is what I call 'false positives' for this scenario - caused by the fact that only the running-config was updated and not the startup-config.

- Currently I am observing 2 AccesPoints which shows up in the OutOfSync report but actually have no diffs. It is just that the running-config shows one special line two-times. But looking at both configs (startup and running) through the 'Version Tree' GUI the line shows up only once in both configs. - So it seems to be a problem with the parser that compares running and startup config. But as RME and the dev pkgs are currently not up to date - I will first bring the system to the latest patch-level. - Deleting and readding the devices in RME did not solve the problem either. This is the configlet with the problem (in the running-config)

interface FastEthernet0.514

bridge-group 13 spanning-disabled

encapsulation dot1Q 514

no ip route-cache

bridge-group 14

no bridge-group 14 source-learning

bridge-group 14 spanning-disabled

bridge-group 14 spanning-disabled

miheg Sat, 02/16/2008 - 14:11

Hi Martin,

Thanks for explaining.

I'm not to sure about how things work for this on the SNMP side anymore, but I have a vague recollection of the existence of OID's that hold the last modified time for both start and running config.

I though that the report was actually based on the values of those OID's, not on archived stuff. Probably not then :-).

Also ciscoworks will get a syslog for the changed running config and a second one for the write, but of course these are both handled by the same automation.

I never understood the reasoning behind a lot of things in ciscoworks and it isn't getting better. I always have the impression that all the hard work, (pulling in the values form al sorts of OID's, getting the config files in), is all done. But then applying what I regards as common sense on that data to produce valuable reports is apparently hard.

TAC's answer when I complain about that is that there is some other more suitable report that I can use to filter the garbage out 8-| Yes the solution for bad reports is ..... more reports. Stuff like that really makes my day.

I guess until we get access to all the data ciscoworks has, we will have to live with lots of "false positives"

Viele Grüße,



This Discussion