Ignoring regular differential updates

[john heasley]

Mon, Sep 02, 2002 at 10:16:20PM +1000, Andrew Fort:
> An architectural question has come up in a relatively large deployment of 
> RANCID I'm working on..
> 
> brief: You operate an SP network, and you have software (RtConfig in our case) 
> pushing out regular configuration changes to your routers, primarily 
> consisting of prefix lists/ACL and route-map/policy-statement changes for 
> your BGP routers.
> 
> 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.
> 
> The thoughts which come to mind for me are:
> 
> 1. (messy) munge the rancid output for the filter changes when you do a 
> nightly RANCID run after the RtConfig changes, grepping out ACLs and prefix 
> lists.  you still get a diff with a whole bunch of 'empty' diff section 
> headers, however.
> 
> 2. run RANCID 'quietly', immediately before and after each router's successful 
> run.  using 2.2.2, you could create a mail alias that goes to /dev/null and 
> do
> 
> do-diffs -r box -m nullmail
> 
> for each box.
> 
> 3. hack up your own version of do-diffs/control_rancid to perform 2. without 
> mailing anyone/creating diffs in the first place.
> 
> Other approaches?

when someone bitched about nvram changes, i cooked up the following procmail
recipe for them.  perhaps you can adapt it for your needs.

:0 H
* ^Subject: .* config diffs
* !^X-RLOOP: rancid
#| egrep -v '\!Flash: nvram:' | formail -A "X-RLOOP: rancid" -s procmail
| sed -e '/private-config/n' -e '/\!Flash: nvram:/d' | formail -A "X-RLOOP: rancid" -s procmail

# /dev/null rancid msgs which have no diffs other than nvram:
:0 HWi b
* Subject: .* router config diffs$
| awk 'BEGIN{n=0;}{if(/...Flash: nvram:/)next; if(/^[-+]/){n++;}next;}END{exit n;}'

i like things like these; it allows an individual see what they wish and
preserves the whole of what rancid collects.

> Also, how many devices do people have RANCID scaling to?  I'm looking at a 
> daily run of around 350 devices, with about 40 BGP routers that need to be 
> treated using one of the methods above.  Sofar it's scaling very well and the 
> overall runtime (~ 1 hour) beats our existing config collection system by 
> about 80% (snmp triggered tftp dumps).

i've seen ~750 devices in < 1 hour, almost all bgp speakers.