[169494] in North American Network Operators' Group
Re: Managing IOS Configuration Snippets
daemon@ATHENA.MIT.EDU (Keegan Holley)
Fri Feb 28 09:49:49 2014
From: Keegan Holley <no.spam@comcast.net>
In-Reply-To: <CAGWL9Q1sDFeU5Qq2bWvDQf_5BJ=S8egg6XoYYZEJ5xnXSwD7mQ@mail.gmail.com>
Date: Fri, 28 Feb 2014 09:49:19 -0500
To: Ryan Shea <ryanshea@google.com>
Cc: nanog list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Feb 28, 2014, at 9:11 AM, Ryan Shea <ryanshea@google.com> wrote:
> Keegan, don't get me wrong, I am not suggesting that even if version =
numbers were happily encoded in robust comments that this would be the =
same as actually digesting the configuration. If the function of =
checking using 'fancy versioning' is not an operational best practice, =
what do you suggest (all-knowing/singing/dancing tool which understands =
the configuration and your intent aside)? You say IF NTP or CPP were =
configured differently - with a large enough network there will always =
be configurations which have differences. With that as an operational =
constant, how do you determine which devices have the latest iteration =
of your line vty configuration.
That=92s what I mean. The things that lend well to to version tracking =
don=92t tend to change much. How many ways are there to configure VTY =
lines, or NTP, or CPP, or even OSPF and if we=92re talking about an =
access ACL why not just audit the configs to make sure that all the =
entries are there. Am I really going to care that one router has =
version 1.0 versus another router that has version 2.2.12 build9? It=92s =
not source code.. =20
>=20
> How often will a change not be rolled out to every router. This is =
again related to the size and churn of the network, but my practical =
estimation is that once you get into thousands of routers there will =
almost always be some that get missed.
Again, a router that was missed is a reason for audit and remediation =
not versioning. If you find a router with config missing does it really =
matter what version it=92s on and when that version was valid? Not in =
my experience.
> Comprehensive auditing is very important, and arguably more useful =
than version checking - but it requires that you make knowledgeable and =
complete assertions. I assert the my snmp config should look like the =
snmp snippet version 77 is easier to grok than "make sure our community =
string is not set to public" (and repeat hand-crafted audit logic for =
every segment of the config).
There may be some differences, but those are normally due to equipment =
lifecycle, mergers/consolidations and such. It=92s easy to refer to =
something as the config for a particular platform or company than a =
version number. This can be tracked in GIT or SVN. Even then there =
will not be constant changes. I=92d lean towards standardization. So =
the equipment that cannot adhere to the defined standards probably won=92t=
evolve much on it=92s own.
>=20
> What if some of the configs don't match the defined versions? This is =
why it may make sense to break snippets into functional areas. "Just fix =
it" might be sane for a banner, but squashing an interface mtu change =
that was put there for a reason could end in tears. I consider this bit =
out of the scope of the question, but yes it is another important =
problem.
I wasn=92t saying just fix it. I was saying that router configs don=92t =
lend well to versioning. With software for example, if something is =
different it might be a different version of that application with =
compatibility issues, dependencies, library issues, etc. When it=92s a =
router config chances are someone fat-fingered something. Most of the =
time the best thing to do is to fix or at least alert on the error, not =
to record it as a valid config version. Again, this is for things that =
lend themselves to snippets. ACL=92s, NTP, SNMP, CPP, even =
Spanning-tree. Not for things like interface IP=92s or static routes =
that may be different across different boxes or location. If you=92re =
referring to the latter I may have misunderstood your question..
>=20
>=20
> On Thu, Feb 27, 2014 at 10:03 PM, Christopher Morrow =
<morrowc.lists@gmail.com> wrote:
> 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 deployed 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 versioning 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 administrative option were configured =
differently across my
>=20
> 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'.
>=20
> 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' ?
>=20
> 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.
>=20
> 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 =
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.
> >
> >
>=20
