Re: Network configuration archiving

[chip <chip.gwyn () gmail com>]

I've been intrigued by the stuff going on with NetKit and Autonetkit (
http://www.autonetkit.org).  See the preso from Pycon 2013 in Australia:
http://www.youtube.com/watch?v=EGK5jjyUBCQ

It seems like all the bits are available between the various efforts of
applications but nothing that really ties everything together.  I'll agree
with Phil that the most comprehensive I've seen is from Tail-F, as far as
off the shelf packages go.  The problem with this space is one of agility
and scale.  If you have only a handful of pieces of gear, all different
platforms, it's tough to get a system going that implements policy the way
you want or need.  It's also difficult to be agile and implement new
platforms or capabilities without lots of work.  If you have hundreds of
routers it makes sense to put forth the effort but then becomes difficult
to keep up with moves/add/changes with individual elements.  A strict and
rigorous change management process can help keep running config in sync
with offline systems but can be difficult to manage in the heat of the
moment while troubleshooting.  I think this is some of the hope of "SDN",
build standard ways of implementing config and policy that are consistent,
easy to manage, yet agile, and comprehensive.  However, I think it will be
difficult to find a One Size Fits All application.  Perhaps there can be
some common enough ground where network kit implementation becomes as
ubiquitous as system implementations.

--chip


On Fri, Oct 25, 2013 at 10:22 AM, Phil Bedard <bedard.phil () gmail com> wrote:

> There are companies like Tail-F who are trying to use things like YANG
> definitions to dynamically build a standardized CLI which is sort of
> cross-platform compatible.  The CLI you connect to is external to any
> network equipment which records changes, does checking ahead of time, and
> records atomic changes to the network.  The plugins underneath are there
> to translate the common CLI to Junos/NETCONF/XR CLI etc.   This isn't a
> new idea, tools like Opsware tried to do this in the past and at least one
> provider I've worked for had their own common config language then
> translated to real device configurations.
>
> The idea is no one ever logs into a router to make a change, all changes
> are recorded by the system making the change for you.  The same system
> generally takes care of committing the config to device, handling errors
> during provisioning, making sure configurations are synchronized between
> it and the device, etc.
>
> I'Ve been a couple places who had good home-grown RCS-based config
> management systems I wish they would have open sourced.
>
>
> -Phil
>
>
>
>
>
>
> On 10/25/13 8:32 AM, "Saku Ytti" <saku () ytti fi> wrote:
>
> > On (2013-10-25 10:43 +0200), Martin Pels wrote:
> >
> > > The diff-ed backups that rancid provides serve another purpose:
> > > verifying that
> > > what your NMS says should be configured matches the actual device
> > > configurations.
> >
> > Diffing one rancid config to another rancid config would not help with
> > this at
> > all.
> > You'd need to diff provisiong system config to rancid config which is
> > extremely complex problem, as your provisioning system is not creating
> > 'post
> > parser' config, it's creating config in completely different way than
> > what it
> > will be after parser.
> >
> > The hard/wrong solution the problem is to have per-platform parsing
> > intelligence reimplemented in your provisioning system.
> >
> > The two easy solutions are
> >
> > a) when your provisioning system pushes change out, it saves the config it
> > sends, and then it views what route stored and makes note of them being
> > the
> > same. If it has this logic, then rancid is not needed.
> >
> > b) before your provisioning system pushes change out, it checks timestamp
> > on
> > config, if timestamp is newer than its latest config push, it regenerates
> > full
> > configuration. In this scenario also, rancid is not needed.
> >
> >
> >
> > However going 100% of config is in systems is not really something many
> > target, nor have I seen good products for it. It's not actually hard
> > problem,
> > not even when targeting multiple platforms. As platform specific
> > intelligence
> > can be kept very low with some design choices.
> >
> > --
> >  ++ytti


-- 
Just my $.02, your mileage may vary,  batteries not included, etc....