Ignoring regular differential updates

[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?

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

cheers
-amf