Re: [c-nsp] IOS archive in addition to RANCID
Il 10/10/2012 2.52, Ian Henderson wrote: * Having two methods ensures that if one method breaks, we still have useful logs/archives. This is particularly nice in our environment I particularly appreciate this design principle. Please consider doing a periodic SCP of important files which are otherwise not backed up: - nvram:ifIndex-table, if you use ifindex persistency - flash:env_vars, for switches (as Matt pointed out) - flash:vlan.dat, if for some unlikely reason you use VTP Rancid does a dir, so you can see (grep, etc) there if these files exist on your switches. Also please take the time to try to restore a device from the backup you have: everybody can do a backup, but only the brave can actually restore. Regards, Bergonz -- Ing. Michele Bergonzoni - Laboratori Guglielmo Marconi S.p.a. Phone:+39-051-6781926 e-mail: berg...@labs.it alt.advanced.networks.design.configure.operate ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] IOS archive in addition to RANCID
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? ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] IOS archive in addition to RANCID
On 10/10/2012, at 8:16 PM, Phil Mayers p.may...@imperial.ac.uk wrote: TBH I'm not really sure what you're asking. Yep, sorry was a bit of a brain dump. :) Thanks for your comments. This basically tells me that archive doesn't have any super awesome features that we don't already get from RANCID, and that its not completely solid yet (re 6500). Syslog command logging though is 100 times more convenient than TACACS for short term requirements, while TACACS+gzip+disk storage sorts out the long term/compliance requirements. Really? We use a home-grown system for this, and back up 1200 devices every hour. At the moment, ~rancid/var lives on NFS, and the machine does a bunch of other things that chew resources. I've got plans on improving this, but one disaster at a time. :) Rgds, - I. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] IOS archive in addition to RANCID
Wed, Oct 10, 2012 at 10:16:09AM +0100, Phil Mayers: * 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? at one time we polled 700+ devices hourly on an 450mhz*2 ultrasparc2. clearly, he has configuration issues. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] IOS archive in addition to RANCID
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? Syslog command logging in addition to/in place of TACACS? Thoughts on pros/cons? Are you using EEM to catch config changes that aren't followed by a 'wr mem'? Any other neat tricks? archive log config record rc logging enable logging size 200 notify syslog contenttype plaintext hidekeys path tftp://tftp/Config-Archive/$h-$t write-memory 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. * RANCID does automated diff, having a directory full of router-datetime files isn't as easy to manipulate. * TACACS command logging catches commands performed outside config mode. * Having two methods ensures that if one method breaks, we still have useful logs/archives. This is particularly nice in our environment - if someone deploys hardware without following procedure of adding it to the database that runs RANCID, it still gets config collection (plus they get a bonus larting, but thats another story…). Any additional insight? Rgds, - I. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
