Re: Managing IOS Configuration Snippets

[Ryan Shea <ryanshea () google com>]

Robert - all great suggestions. Big cross-vendor configuration generation
and deployment is outside the scope of what I was hoping for here. The goal
is to have the version information somehow encoded into the configuration,
and I'm not sure that NETCONF has anything to say about that matter.
Certainly the same problem of which-versions-are-where exists in the
puppet/chef world and there are platform specific ways to answer those
questions. Deep analysis of the router configuration itself can give pretty
strong hints about which version are deployed, but lets assume full config
digestion and comparison is out of the question. From some off-list
responses I am hearing that some folks do similar kludges with other text
fields, wether they be remark/banner/snmp-foo/interface descriptions.


On Wed, Feb 26, 2014 at 5:59 PM, Robert Drake <rdrake () direcpath com> wrote:

> On 2/26/2014 5:37 PM, Robert Drake wrote:
>
> > 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)
>
> I should amend that even though I recommend all this I haven't used any of
> it for networking.  I guess those are more shiny ball ideas than actual
> things I've used.  We have perl scripts that wrap an in-house API to access
> our IPAM which generates initial configuration.  The template files are a
> mix of m4 and Template::Toolkit.
>
> We use basically one-off perl scripts for auditing sections of the configs
> to find discrepancies.  We use rancid to collect configs. We just started
> using netdot which is nice for topology discovery. TACACS and DHCP logs are
> parsed and stored in logstash.  All of those tools provide the who, what,
> where and when but not the why. The why would require a bit more custom
> stuff and forcing people to use a frontend interface instead of directly
> touching the routers. We aren't ready for that yet.