Re: Managing IOS Configuration Snippets

[Ryan Shea <ryanshea () google com>]

A couple more thoughts, regarding

Network => DB

I completely agree that trying to use the network config itself as the
authority for what we intend to be on a device is not the right long-term
approach. There is still a problem with Network => DB that I see. Assuming
you have *many* devices, that may or may not be up at a given time, or may
be in various stages of turn-up / burn-in / decom it is expected that a
config change will not successfully make it to all devices. There are other
timing issues, like a config built for a device being turned up, followed
by a push of an update to all devices that "succeeds", followed by the
final turn-up of this device. Even if you have a fancy config pushing
engine, let's just take as a given that you'll need to scrub through your
rancid-git backups to determine what needs to be updated.

Regarding the MD5 approach, let's also think that configlets could have
"no" commands in them. In the NTP example I had before, if we wanted to
remove an NTP server the configlet would need the "no" version, but the
rancid backup obviously would not have this. I'm not trying to work a unit
test assertion framework here either. Some vendors have more robust
commenting, and this can be quite convenient for explicitly stating what
was pushed to the device. What are you using in your network... banner,
snmp-location, hope, prayer?


On Thu, Feb 27, 2014 at 9:36 AM, Tim Durack <tdurack () gmail com> wrote:

> 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
> Agree with this.
>
> We started out with rancid, quickly moved to a homebrew scp and git backed
> system with webgit/cgit as the user interface. If you are lucky your
> network equipment supports "advanced features" like ssh keys. If not, you
> might be stuck using sshpass to ease config collection.
>
> Built a config parsing system that would decompose monolithic configs into
> configlet files. Md5sum the file and use as part of the filename. You can
> then see "version" information for parts of the config tree. Quickly
> realized that maintaining this system is a full time job, due to the
> advanced status of network equipment software...
>
> Now looking at Tail-F NCS. Demo is impressive. I'm hopeful.
>
> Stating the obvious: the software running on most network equipment is of
> poor quality. The tools to manage this are a combination of high quality
> engineers and homebrew tools. Vendor tools are of a similar quality to the
> equipment software. I'd like to think "SDN" is an attempt to improve this,
> but I have my doubts.
>
> --
> Tim:>