cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
987
Views
0
Helpful
5
Replies

Question on syslog triggered config collection and OutOfSnc Report

Martin Ermel
VIP Alumni
VIP Alumni

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

1 Accepted Solution

Accepted Solutions

Joe Clarke
Cisco Employee
Cisco Employee

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.

View solution in original post

5 Replies 5

Joe Clarke
Cisco Employee
Cisco Employee

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.

oh..

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!

False positives? What do you mean exactly?

Like the devices in the attachment?

Cheers,

Michel

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

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,

Michel

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: