Ignoring regular differential updates

[jnull]

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
> config.

        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.
--
> -amf

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. 

-- 
sig=$header