[c-nsp] IOS archive in addition to RANCID

[Phil Mayers]

On 10/10/2012 01:52 AM, Ian Henderson wrote:
> Hi folks,
>
> I'm working on updating our base templates using some more modern
> features and am considering if IOS' built in configuration
> archiver/change logger have a place in our network.
>
> Is anybody using the config archiver in addition to/in place of
> RANCID?

No, because it's slow on 6500 sup720, which are our primary platform. Of 
course, that's because NVGEN is slow, but when I tested it, the archive 
stuff had a few niggles that would occasionally trigger a background 
NVGEN. Ditto the incremental config stuff - slightly buggy when I tested 
it, would occasionally pull a full NVGEN for no obvious reason.

> Syslog command logging in addition to/in place of TACACS?

Yes, instead of, because TACACS is mostly inappropriate for our needs.

That said - I don't see any reason to ever disable this. syslogging the
commands is, at worse, redundant. And it gets you logging if someone has
to use the emergency non-TACACS user.

> Thoughts on pros/cons? Are you using EEM to catch config changes that
> aren't followed by a 'wr mem'?

Nagios check against the "config operation" MIB to check that the last
config operation was a "wr mem", with some time delay to allow people 10
minutes to commit. Works on all Cisco platforms AFAIK including NX-OS,
but does false-positive immediately after a reload b/c the last
operation was a "read".

> Any other neat tricks?

"sec" to tail the router logs at your syslog server and trigger 
operations only when needed e.g. backups - don't cron them, run one 
immediately after someone exits config mode, possibly even annotating 
the SVN checkin with their username.

More generally - "sec" to tail all your router logs. Write a whitelist 
of "don't care" syslog messages, and watch the rest like a hawk. It's 
invaluable.

>
> My thoughts so far:
>
> * RANCID is a single solution that works for all vendors and all
> versions of IOS, no need for separate dirty hacks per vendor, but new
> vendor/device type maintenance can be tricky.
>
> * With a sizeable RANCID installation, collection interval needs to
> be pushed out to 4 hours plus, which means we could miss changes
> within the interval.

Really? We use a home-grown system for this, and back up >1200 devices 
every hour. I'm confident we could go faster. How sizeable does an 
install have to be for RANCID to be this slow? Does it do devices in 
series or something?

>
> * RANCID does automated diff, having a directory full of
> router-datetime files isn't as easy to manipulate.

Well, no. Just letting the files accumulate isn't very useful IMO.

For what it's worth - in our home-grown config backup system, JunOS 
devices "ftp" each config write to a spool directory. The config backup 
system pulls each write in date order, and commits them to version 
control individually. Thus, we feed the VC system from the archive spool.

> * TACACS command logging catches commands performed outside config
> mode.

Yes. It might also be moderately useful to disable really dangerous 
commands e.g. the "switchport trunk allowed vlan X" variant, without 
"add" or "remove".

> Any additional insight?

TBH I'm not really sure what you're asking.

"Should I use 'archive' instead of RANCID?" - erm, no. They serve 
different purposes. Maybe feed RANCID from the archive spool, but 
replace - not a chance.

"Should I use 'archive' instead of TACACS?" - I doubt it, for much the 
same reason.

The archive stuff is nice - turn it all on, if you're happy with it - 
but it's very raw and low level, and doesn't replace mature systems. 
IIRC RANCID does loads more than just the configs - doesn't it back up 
inventory and such like via "show" commands?