Managing IOS Configuration Snippets

Saku Ytti saku at
Thu Feb 27 13:58:58 UTC 2014

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


More information about the NANOG mailing list