[169529] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: Managing IOS Configuration Snippets

daemon@ATHENA.MIT.EDU (Dale W. Carder)
Fri Feb 28 21:35:54 2014

Date: Fri, 28 Feb 2014 20:35:21 -0600
From: "Dale W. Carder" <dwcarder@wisc.edu>
To: Keegan Holley <no.spam@comcast.net>
In-reply-to: <B5857EAB-52EC-4A97-95A6-6A9D7A952F28@comcast.net>
Cc: nanog list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org

Thus spake Keegan Holley (no.spam@comcast.net) on Fri, Feb 28, 2014 at 09:49:19AM -0500:
> I wasn’t saying just fix it.  I was saying that router configs don’t lend well to versioning.  

Um, what?

$> rlog r-cssc-b280c-1-core.conf | grep 'total revision'
total revisions: 2009;	selected revisions: 2009

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

We have our operators manually check in revisions (think in rcs terms:
co -l router, go do work, verify it, ci -u router) rather than
unsolicited / cron-triggered checkins.  Then the check-in message
contains the operator's description text of the change and often a
ticket number.  So there slightly fewer fat-finger configs checked in.

Dale


home help back first fref pref prev next nref lref last post