Managing IOS Configuration Snippets

Thu Feb 27 18:47:09 UTC 2014

On 27 February 2014 10:39, Ryan Shea <ryanshea at google.com> wrote:
> 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.

Absolutely. Expect/SNMP/config scraping is a solution here. It's
tedious and boring to write the hooks, but it's not impossible.
A solution like tail-f is a much better solution here. My personal
preference would be to just push/pull JSON off the devices.

I think there are two separate components here (which are often
conflated): the mechanics to push/pull from devices into a data
structure, and the network database to work with those data
structures. There's a place for both device level models and network
level models.

--Simon

>
>
> On Thu, Feb 27, 2014 at 12:04 PM, Erik Muller <erikm at 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...
>>
>>