Mailing List Archive

On Mon, Mar 29, 2004 at 05:58:07PM +0200, Otto, Axel wrote:
> And here is my problem: I would like to see who have done configuration
> changes on our routers, this information is usually shown if you do a "show
> running-config" on a router. Unfortunately this information gets filtered
> out by the rancid process and I have no clue how to keep it.
> Is there somebody out there who can help?

Assuming you're talking about this output:

!
! Last configuration change at 07:02:04 UTC Sat Mar 27 2004 by jaitken
! NVRAM config last updated at 07:02:06 UTC Sat Mar 27 2004 by jaitken
!

rancid could probably be tweaked to save it. I've never done this
personally but it shouldn't be hard. However, the problem is that
this only tells you the *last* person who changed the config and
who saved it to NVRAM. If you want to know the complete set of
people who made changes (and what specific changes they made) you
really want command logging of some kind. How you configure this
depends on a number of factors including the protocol you use
(RADIUS, TACACS), the level of detail you want, and so on. For
more info, look on CCO for the 'aaa accounting' hierarchy of commands
and go from there.

router(config)#aaa accounting ?
commands For exec (shell) commands.
connection For outbound connections. (telnet, rlogin)
exec For starting an exec (shell).
nested When starting PPP from EXEC, generate NETWORK records before
EXEC-STOP record.
network For network services. (PPP, SLIP, ARAP)
send Send records to accounting server.
suppress Do not generate accounting records for a specific type of user
system For System events.
update Enable accounting update records.


HTH,


--Jeff

On Mon, Mar 29, 2004 at 05:58:07PM +0200, Otto, Axel wrote:
> for me. At the moment I use it to monitor 350 different Cisco routers.
> And here is my problem: I would like to see who have done configuration
> changes on our routers, this information is usually shown if you do a "show
> running-config" on a router. Unfortunately this information gets filtered
> out by the rancid process and I have no clue how to keep it.

You really need to watch the syslog output from the routers for that.
The 'show running' info only mentions the last change, not all of
the ones before that.
--asp

-----Original Message-----
From: Andrew Partan [mailto:asp@partan.com]
Sent: Montag, 29. M?rz 2004 06:25 PM
To: Otto, Axel
Cc: rancid-discuss at shrubbery.net
Subject: Re: Newbie question


On Mon, Mar 29, 2004 at 05:58:07PM +0200, Otto, Axel wrote:
> for me. At the moment I use it to monitor 350 different Cisco routers.
> And here is my problem: I would like to see who have done configuration
> changes on our routers, this information is usually shown if you do a
"show
> running-config" on a router. Unfortunately this information gets filtered
> out by the rancid process and I have no clue how to keep it.

You really need to watch the syslog output from the routers for that.
The 'show running' info only mentions the last change, not all of
the ones before that.
--asp


Thanks a lot for your quick response, but this is exactly what I'm looking
for. I know that only the last "changer" will be saved that way but, based
on the fact that this would be stored at CVS, it would work for me. A simple
Diff would show the config changes and, at least, the one who did the
"latest" change since the last run of Rancid.

Axel Otto

**********************
** LEGAL DISCLAIMER **
**********************

This E-mail message and any attachments may contain
legally privileged, confidential or proprietary
information. If you are not the intended recipient(s),
or the employee or agent responsible for delivery of
this message to the intended recipient(s), you are
hereby notified that any dissemination, distribution
or copying of this E-mail message is strictly
prohibited. If you have received this message in
error, please immediately notify the sender and
delete this E-mail message from your computer.

On Mon, Mar 29, 2004 at 06:37:14PM +0200, Otto, Axel wrote:
> Thanks a lot for your quick response, but this is exactly what I'm looking
> for. I know that only the last "changer" will be saved that way but, based
> on the fact that this would be stored at CVS, it would work for me.

I think this might do what you want:

% diff -c rancid rancid.new
*** rancid Mon Mar 29 08:38:19 2004
--- rancid.new Mon Mar 29 08:40:59 2004
***************
*** 1130,1139 ****
}
tr/\015//d;
}
- # some versions have other crap mixed in with the bits in the
- # block above
- /^! (Last configuration|NVRAM config last)/ && next;
-
# skip consecutive comment lines to avoid oscillating extra comment
# line on some access servers. grrr.
if (/^!/) {
--- 1130,1135 ----



--Jeff

Jeff Aitken wrote:

>On Mon, Mar 29, 2004 at 06:37:14PM +0200, Otto, Axel wrote:
>
>
>>Thanks a lot for your quick response, but this is exactly what I'm looking
>>for. I know that only the last "changer" will be saved that way but, based
>>on the fact that this would be stored at CVS, it would work for me.
>>
>>
>
>I think this might do what you want:
>
>% diff -c rancid rancid.new
>*** rancid Mon Mar 29 08:38:19 2004
>--- rancid.new Mon Mar 29 08:40:59 2004
>***************
>*** 1130,1139 ****
> }
> tr/\015//d;
> }
>- # some versions have other crap mixed in with the bits in the
>- # block above
>- /^! (Last configuration|NVRAM config last)/ && next;
>-
> # skip consecutive comment lines to avoid oscillating extra comment
> # line on some access servers. grrr.
> if (/^!/) {
>--- 1130,1135 ----
>
>
>
>--Jeff
>
>
>

Yep, that'll do what he Axel wants. Axel - you should look for
'unexpected' diffs from the routers if you do apply the diff suggested
above. I suspect in newer IOSes the problem allured to there may have
been cleared up, but you never know ;-).

If you run log-analysis software (such as the very powerful and
recommended SEC (simple event correlator)), you can setup a rule to
trigger RANCID (just for that device) when the log line coming from your
router indicating that a particular device has had its configuration
modified is seen. SEC can auto-dampen the triggering of these events to
avoid over-eager spawning of rancid collections. I'd recommend this if
you have the time - it's a good thing(tm). It tends to encourage
engineers not to idly jump in and out of config mode, too, if they know
rancid is being triggered. :-)

-afort