Re: Managing IOS Configuration Snippets

[Keegan Holley <no.spam () comcast net>]

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’s what I mean.  The things that lend well to to version tracking don’t tend to change much.  How many ways are 
there to configure VTY lines, or NTP, or CPP, or even OSPF and if we’re 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’s not source code..  
> 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’s 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’s 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’d lean towards standardization.  So the 
equipment that cannot adhere to the defined standards probably won’t evolve much on it’s own.
> 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’t saying just fix it.  I was saying that router configs don’t 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’s 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’s, NTP, SNMP, CPP, even Spanning-tree.  Not for things like 
interface IP’s or static routes that may be different across different boxes or location.  If you’re referring to the 
latter I may have misunderstood your question..

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