Ignoring regular differential updates
rancid at jnull.rackspace.com
Mon Sep 2 13:46:59 UTC 2002
Andrew Fort(afort at choqolat.org)@2002.09.02 22:16:20 +0000:
> How do you cope with these regular changes operationally with RANCID?
> Architectural staff would like to avoid seeing the ACL/pfx.list changes that
> occur when customer registers a route with your IRR, but you'd still like to
> know when ops folk accidentally smoke some important part of the router
I've the same issue, save it is with static route entries for secondary IPs. Also,
I don't care about saved configs. I asked a similar question, but was basically told that
the current release doesn't support it.
> 1. (messy) munge the rancid output for the filter changes when you do a
Yes, messy should be the first and last word for this method.
> 2. run RANCID 'quietly', immediately before and after each router's successful
I think there is too much risk here, defeating a prime benefit of RANCID.
> 3. hack up your own version of do-diffs/control_rancid to perform 2. without
I've got this on my tuit list. As soon as I'm done hacking on a DoS det. app.
> Other approaches?
One could stay off "do-diffs" and just use clogin with your own commands and some
easy shell scripts to parse the data--basically a shortcut to 3.
> Also, how many devices do people have RANCID scaling to? I'm looking at a
Yours it about equal to the largest I've heard of for a full implementation. Personally,
I only use it for a subset of our devices for monitoring changes, mainly due to the
issues you described above. However, for changing snmp strings or local passwords
I'll use it across the board.
Let me know if you opt on number 3, possibly we could QA each others work or swap some ideas.
My time schedule puts it a few weeks out yet.
More information about the Rancid-discuss