Re: Managing IOS Configuration Snippets

[Ryan Shea <ryanshea () google com>]

We've gone off the rails a bit here. The 'in-line' bit was really at the
heart of my question. With the number of responses so far it's starting to
sound like there is not an answer other than kludge.

"workable solutions for a way to track *in-line* the configuration
revisions you have on your cisco-like devices"

This could be on brocade/hp/arista/ios, so "ask the vendor to..." is not a
(short term) solution. Assume we've got rancid-git, super awesome network
engineers who write configuration bits and test and review them, and a
super dooper tempating config pushy tool with retries and a blinky
dashboard.

Now, I hand you the 'show run' output and ask you if version 77 of the vty
config is on this device. Can you answer the question? Now I hand you the
'show run' from 10,000 more device configs - and 100 more configuration
chunks from revision control. Can you still answer the question? Assume a
magical revision-history-aware configuration cross reference parser (while
a noble and lovely goal) is not available.




On Thu, Feb 27, 2014 at 8:58 AM, Saku Ytti <saku () ytti fi> wrote:

> On (2014-02-26 17:37 -0500), Robert Drake wrote:
>
> > Consider looking at Tail-F's NCS, which according to marketing
> > presentations appears to do everything I want right now.  I'd like
> > to believe them but I don't have any money so I can't test it out.
> > :)
>
> Tail-F is probably least bad option out there.
>
> In configuration management, this is super easy:
>
> DB => Template => Network
>
> This is super hard:
>
> Network => DB
>
>
> The first one keeps all platform specific logic in flat ascii files filled
> with variables from template.
> When you introduce new product, feature, vendor to network, you only add
> new
> ascii templates, extremely easy, no platform-specific logic in DB.
>
> The second one every little change in network, requires parser changes
> trying
> to model it back to DB. This is not sustainable. We can kid ourselves that
> NetCONF/YANG will solve this, but they won't. SNMP is old technology, when
> new
> feature comes to vendor, it may take _years_ before MIB comes. There is no
> reason to suspect you will be able to get feature out via NetCONF just
> because
> it is there. And if you can't do it 100% then you have to write parser
> which
> can understand it.
>
> You only need the second one, in case 100% is not from DB. But it is
> actually
> trivial to produce 100% from DB. You don't want DB to model base
> configuration, that's lot of work for no gain, that'll come from template
> or
> at most DB vendor-specific-blob.
> Then after you push configuration from DB to network, you immediately
> collect
> configuration and create relation of DB-config 2 network-config, now you
> can
> keep ensuring network has correct config. If it does not have, you don't
> know
> why not, you can't fix the error itself, but you can repovision whole box,
> so
> you do get configuration conformance check, it's just very crude.
>
> But the alternative, trying to understand network config, is just never
> ending
> path to to pain. If someone is going to do it, model it to python or ruby
> ORM
> and put it in github so others can contribute and we don't need to do it
> alone.
>
> --
>   ++ytti