Managing IOS Configuration Snippets

Wed Feb 26 22:37:41 UTC 2014

On 2/26/2014 4:22 PM, 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.
> Let me clearify/frame:
>
> You have a set of tested/approved configurations for your routers which use
> IOS style configuration. These configurations of course are always refined
> and updated. You break these pieces of configuration into logical sections,
> for example a configuration file for NTP configuration, a file for control
> plane filter and store these in some revision control system. Put aside for
> the moment whether this is a reasonable way to comprehend deployed
> configurations. What methods do some of you use to know which version of a
> configuration you have deployed to a given router for auditing and update
> purposes? Remarks are a convenient way to do this for ACLs - but I don't
> have similar mechanics for top level configurations. About a decade ago I
> thought I'd be super clever and encode versioning information into the snmp
> location - but that is just awful and there is a much better way everyone
> is using, right? Flexible commenting on other vendors/platforms make this a
> bit easier.
>
> 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.
>
I started a long email that really should just be a blog post.  I need 
to get a blog or something.

Short story is this:

NETCONF is probably the future of change management on all types of 
routers and switches.  It's not supported everywhere yet and is missing 
lots of features but they're working on it.  Look at the talk given at 
NANOG60 for more information.

There is a puppet module that is also incomplete.  I'm not sure this is 
the right way to go 
(http://puppetlabs.com/blog/puppet-network-device-management)

Most people roll their own solution.  If you're looking to do that 
consider using augeas for parsing the configuration files.  It can be 
really useful for documenting changes, and probably to diff parts of the 
config.  You might also consider rabbitmq or another message queue to 
handle scheduling and deploying the changes.  It can retry failed 
updates.  You should work towards all or nothing commits (not all cisco 
gear supports this, but you can fake it in a couple of ways.  Ultimately 
you want to rollback to a known good configuration if things go wrong)

If you have money and want this right now:

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. :)

Cheers,
Robert