Re: Managing IOS Configuration Snippets

[Ryan Shea <ryanshea () google com>]

It sounds like your suggestion is to not check version numbers, write smart
audits and react. Thinking of ACLs for example, version checking from a
remark is a limted shortcut (but still very useful way) to validate
distribution of an ACL. These things may change ~continuously. Grabbing a
config and jamming that into some rancid rcs thing is different than intent
version tracking. Our friends at Juniper (or the IOS-XR folks) seem to
think the version control paradigm lends itself well to router configs,
albeit at the whole-config level.

Oh, and I think we're crossing streams here regarding versioning. I am not
suggesting to take the configured state of the network, consider that
proper intent, record it in a revision and then check for it in the future.
I am assuming that the intent versions represent reviewed and tested
configuration states by ops/neteng. Different across the fleet does not
necessarily mean non-deterministic, so intent versioning can still be
useful. I'm sure (not first-hand sure) that some of the other suggested
templating systems could build parts of the expected config based on
attributes of a device.


On Fri, Feb 28, 2014 at 9:49 AM, Keegan Holley <no.spam () comcast net> wrote:

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