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