[c-nsp] Syslog Patterns

[Peter Rathlev]

On Wed, 2012-01-18 at 16:37 +0200, Nikolay Abromov wrote:
> On Wed, Jan 18, 2012 at 4:26 PM, Peter Rathlev <peter at rathlev.dk> 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