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