On Wed, Jan 18, 2012 at 4:26 PM, Peter Rathlev <[email protected]> wrote: > On Wed, 2012-01-18 at 16:05 +0200, Nikolay Abromov wrote: >> On Tue, Jan 17, 2012 at 11:18 PM, Peter Rathlev <[email protected]> >> wrote: >> > On Tue, 2012-01-17 at 20:50 +0200, Nikolay Abromov wrote: >> > > I haven't read what the rest of the guys suggested about this >> > > topic but this is pretty easy. >> > >> > A bit ironic... >> >> I read your question and answered. I don't see anything ironic in >> that. > > The ironic part is that your suggestion on using CONFIG_I has been > discussed at length and it has been pointed out (also by OP) that the > method is not adequate. Though OP could probably spend more time reading > up on the topic himself, it does seem like a waste of time simply > repeating what everyone else have said. :-) > > Keep in mind that only one person spends time writing a reply, but > thousands spend time reading it. Common sense dictates that placing a > burden on the one is more efficient than placing it on the many, even > when the latter burden is much smaller. You are right. Sorry about it. > >> > > Cisco is generating CONFIG_I syslog message when running config >> > > has been changed. >> > >> > Nope. It's generated when you exit config mode, no matter if you >> > configured anything or not. >> >> Yes, it's generating the message when you exit from the configuration >> mode but cisco are also using it to track the changes and I gave you a >> way to verify it. > > Then I may have misunderstood. You wrote: > >> 1. configure NTP master (on the local router or if you have remote >> NTP) >> 2. wait to sync (verify with show ntp status) >> 3. do show run and you will see >> >> lab-rack1#sh run >> Building configuration... >> >> Current configuration : 1480 bytes >> ! >> ! Last configuration change at 18:53:13 UTC Tue Jan 17 2012 >> ! NVRAM config last updated at 18:52:53 UTC Tue Jan 17 2012 > > I'm terribly sorry, but I cannot reconcile this description with the > statement "I gave you a way to verify it". The timestamp is updated > every time you exit config mode, just like when CONFIG_I is logged. And > this is true even though no configuration change was made. > >> Archieve is not reliable because it is logging only the commands and >> SNMP too. The change configuration mib is sending everytime when you >> enter in config mode and exit. > > I'd love to hear more about this, so if you can elaborate I'm all ears. > > 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. > > Everyone else: Please excuse me if I'm feeding a troll here. > -- > Peter > >
-- Nikolay Abromov Mobile +359 (0) 886 613 413 _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
