Ignoring regular differential updates
afort at choqolat.org
Mon Sep 2 12:16:20 UTC 2002
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
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
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-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.
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).
More information about the Rancid-discuss