Network configuration archiving

Fri Oct 25 08:43:43 UTC 2013

On Fri, 25 Oct 2013 10:07:49 +0300
Saku Ytti <saku at ytti.fi> wrote:

> On (2013-10-24 23:05 -0400), Erik Muller wrote:
> 
> > Rancid certainly has its warts, but other than needing to test, pull
> > hair, and patch things for new OS/platform deployments, it still
> > generally Just Works once you have it installed, IME... and
> > references like
> 
> For us problem with rancid is that we're quite married to configuration
> backups, provisioning depends on them. And we have good number of devices in
> rancid and rancid runs take several hours.
> Now we may need refreshed configuration backup to satisfy some dependencies to
> complete some work, but if rancid is running we cannot, in worst case, we may
> need to postpone some work to next working day.
> 
> We have 'one off' hack script for rancid, which fetches just one device right
> now, but we cannot run it if rancid proper is currently running.

Have you tried running multiple rancid instances in parallel? (each talking to a
different batch of devices)

> Other than that, rancid works very reliably and is highly robust. For style
> rancid does not get points as there is terrible amount of code duplication for
> different platforms.

The main reason we're all stuck with rancid is that there is no standardized
way to securely pull configurations and other information from devices built by
all major vendors. Rancid, as horribly written as it may be, has over the years
incorporated ways to deal with the quirks of pretty much every CLI out there.
This is hard to duplicate.

> Philosophically speaking, configuration backups should be completely useless,
> full configuration to network should be generated from central place in
> fully automated manner.

The diff-ed backups that rancid provides serve another purpose: verifying that
what your NMS says should be configured matches the actual device
configurations.

Regards,
Martin