Re: Managing IOS Configuration Snippets

[Ryan Shea <ryanshea () google com>]

Very cool, thanks Erik. I can think of many ways to encode version
metadata. Probably best to be somewhere in between overly verbose (full
version $Id / date / author for every config chunk) and being unreadable
(base64 encoded gzip of unique configlet identifiers and versions).
Updating a banner feels a bit easier when you are pushing a full
device-specific configuration from a templating system. Regardless of where
it is stored, keeping the metadata in one of these fields (banner for
example) means that checking the contents of the banner configlet now
requires slightly more logic - which is fine.

Chuck, interesting use of alias.

Simon, completely agree that the network itself should not be the intent
store. The real focus here is when your intent is in a DB/templating system
thingy, how do you operationally ensure that intent matches reality. Again,
with many devices going through upgrades, disabled/unreachable devices, new
devices, pre-configured devices. The intent pusher is not blindly and
constantly pushing to all devices, and it's likely not safe to do that.


On Thu, Feb 27, 2014 at 12:04 PM, Erik Muller <erikm () buh org> wrote:

> On 2/26/14, 16:22 , Ryan Shea wrote:
>
> > Howdy network operator cognoscenti,
> >
> > I'd love to hear your creative and workable solutions for a way to track
> > in-line the configuration revisions you have on your cisco-like devices.
> ...
>
>
> > Assume that this version encoding perfectly captures what is on the router
> > and that no person is monkeying with the config... version 77 of the
> > control plane filter is the same everywhere.
>
> At a previous job, our roll-your-own solution was a template based
> system(*) generating full configs; all the version history for template
> sections, per-router local tweaks, and generated results was kept in RCS,
> and the actual last-configured version, plus any incremental changes, was
> kept in the login banner.
> So at login you'd see something like:
>
> blah blah authorized users blah blah
> $Id: routername-confg,v 1.23 2013/08/20 03:07:16 username Exp
> INCR: 1.2,1.3,1.4,1.5,1.6
>
> and that version tracking made its way through to rancid for easy offline
> auditing.  This made it nice and easy to tell when and what had been
> updated, though it still would take a couple steps to identify what exact
> subsections had been changed over time (since the incremental version tags
> were specific deltas in per-device configurations.  You could probably do
> it in a more global way too - git commit ids, maybe? - but you also don't
> want to make the version string too wordy either).
>
> -e
>
> * based on ftp://ftp.cac.washington.edu/pub/config-generator/, but
> substantially enhanced beyond the last public domain version.  I know I'd
> be really happy if the current version was ever open-sourced...