On Wed, 2012-01-18 at 16:37 +0200, Nikolay Abromov wrote: > On Wed, Jan 18, 2012 at 4:26 PM, Peter Rathlev <[email protected]> wrote: > > My own experience is that there is no easy way of detecting a real > > configuration change. You can only compare two copies of the > > configuration, and since some things (e.g. "ntp clock-period" and > > timestamps) change more or less by themselves, you cannot even rely on a > > simple diff. > > I've been looking for a lot of ways to do that too - even tricky stuff > like tracking the size of the running-config file which doesn't work > too because if you change for exampe IP from 1.1.1.1 to 2.2.2.2 the > size of the config stays the same. Probably you can write a TCL script > for a text parser but this want be simple task.
The TCL solution sounds like what OP actually wants, but since most major shops (who would have the skills to develop something like that) use a seperate configuration repository server it's probably not easy to come by. The links Andriy Bilous posted in the "Event Manager" thread is a good start and possibly adequate if one can tolerate the noise. We use a combination of trapping CONFIG_I and regularly (every 30 minutes) looking at ccmHistoryRunningLastChanged to see if something could have changed. If that's the case then we download a copy and use a small perl script to find out if there has been a real configuration change. It creates a nice diff-like output, e.g.: --- Switch last change 11:47:26 CET Fri Nov 4 2011 +++ Switch last change 13:42:48 CET Wed Jan 18 2012 by XXX (bug N) ! interface GigabitEthernet1/0/1 - shutdown + switchport access vlan 181 + switchport mode access ! This is posted to our Bugzilla and assigned to the person why was tagged as configuring the device, i.e. "by XXX" in the timestamp line. The solution means that we download configurations more often than strictly necessary but OTOH does mean that we probably don't miss things. One caveat is that two people change the configuration of a device in rapid succession, too fast for the system to download a copy between the two changes, will result in the configuration change being assigned to just the last person to configure. When this happens we correlate with TACACS+-logs to see who did what if needed. I'd love for Cisco to improve IOS by making available a variable (e.g. pollable by SNMP or a trap) that actually describes if something changed. And the fact that composing the running-config takes a long time and stresses the CPU with large-ish configurations on e.g. the Sup720 would also be a nice thing have mitigated. Maybe the different processes responsible for composing their part of running-config could cache their results and just send the cached version if nothing actually changed. -- Peter _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
