[169483] in North American Network Operators' Group
Re: Managing IOS Configuration Snippets
daemon@ATHENA.MIT.EDU (Christopher Morrow)
Thu Feb 27 22:04:11 2014
In-Reply-To: <73206985-A85C-4B6A-ACF9-4C997FB3FDE0@comcast.net>
Date: Thu, 27 Feb 2014 22:03:37 -0500
From: Christopher Morrow <morrowc.lists@gmail.com>
To: Keegan Holley <no.spam@comcast.net>
Cc: nanog list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Thu, Feb 27, 2014 at 8:38 PM, Keegan Holley <no.spam@comcast.net> wrote:
> Putting aside the fact that snippets aren't a good way to conceptualize d=
eployed router code, my gut still tells me to question the question here. =
The first is does this stuff change often enough to warrant a fancy version=
ing solution? I have yet to see NTP deployed in a different way than when =
I first learned to configure it. Next, when it does change how often is it=
not rolled out to every router. If NTP or CPP or SNMP or some other admin=
istrative option were configured differently across my
sure, so you're saying that a large bit (maybe) of the router config
is 'one size fits all' and 'never changes' where 'never' is really
'very infrequently'.
sure, agreed... but there are parts of the config that do change more
frequently (depending on the network perhaps)... how do you go about
seeing which version / setup is deployed EXCEPT by building a
home-grown 'config parser' and seeing that 'what is deployed matches
mostly what I have in my config store for this
router/class-of-router/network' ?
It's a shame that vendors of network equipment don't have to manage
large networks of their own equipment under constrained opex
environments (no fair comparing contracted work where you bill for
time + materials, that's the wrong incentive set)... I bet that'd get
them to fix stuff up right quick.
network I would want to audit it and fix not version control. What if
some of the configs don't match the defined versions? It may be
better to create standard templates and version them in SVN or GIT and
then use config backups to track which devices have the standard
configs. There are some for pay tools that can search for certain
statements on various boxes and either alert or remediate when
differences are found.
>
>
> On Feb 26, 2014, at 4:22 PM, Ryan Shea <ryanshea@google.com> 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 refin=
ed
>> and updated. You break these pieces of configuration into logical sectio=
ns,
>> for example a configuration file for NTP configuration, a file for contr=
ol
>> 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 updat=
e
>> 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 s=
nmp
>> location - but that is just awful and there is a much better way everyon=
e
>> is using, right? Flexible commenting on other vendors/platforms make thi=
s a
>> bit easier.
>>
>> Assume that this version encoding perfectly captures what is on the rout=
er
>> and that no person is monkeying with the config... version 77 of the
>> control plane filter is the same everywhere.
>
>
