Robert,
>> sgrep can dump out a "stanza" of ios-like config, then you can rcsdiff
>> that to your master, per 'chunk' of config.
>> Dale
>>
>
> I'm digging the idea of your command. Along the same lines I've got this
> awk snippet that I made and then forgot about. It functions like the cisco
>
On 2/28/2014 9:19 PM, Dale W. Carder wrote:
If I'm understanding what you're trying to do, you could script around
our rather unsophisticated 'sgrep' (stanza grep) tool combined with
scripting around rancid & rcs to do what I think you are looking for.
http://net.doit.wisc.edu/~dwcarder/scripts
On Feb 28, 2014, at 9:35 PM, Dale W. Carder wrote:
> Thus spake Keegan Holley (no.s...@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.
Thus spake Keegan Holley (no.s...@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 revisi
Thus spake Ryan Shea (ryans...@google.com) on Thu, Feb 27, 2014 at 09:38:33AM
-0500:
>
> Now, I hand you the 'show run' output and ask you if version 77 of the vty
> config is on this device. Can you answer the question? Now I hand you the
> 'show run' from 10,000 more device configs - and 100 mo
On 2/28/14, 10:24 , Leo Bicknell wrote:
What I have always wanted is a way to group configuration, in particular by
customer. Ideally with the ability to see it both as a unified view, and also
as a per-customer view.
For instance:
customer A
interface GigabitEthernet1/2/3.10
des
On Feb 27, 2014, at 7:38 PM, Keegan Holley 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.
What I have always wanted is a way to group configuration, in particular by
customer. Ideal
On Feb 28, 2014, at 9:11 AM, Ryan Shea 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'
On Thu, Feb 27, 2014 at 8:38 PM, Keegan Holley 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 soluti
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 whe
Definitely. Depends what form the database takes - I don't think SQL
is the right answer here. Sticking with flat files and perl scripts as
much as possible is good guidance.
I'm biased, but I'd go with Python: http://www.youtube.com/watch?v=EGK5jjyUBCQ
--Simon
On 27 February 2014 13:05, Erik Mu
On 2/27/14, 15:52 , Joe Abley wrote:
This is not any kind of sensible answer to the original question, but
the general approach “give ops people a shell on a box with a rancid
repository, encourage them to write scripts that do stuff” has the
potential to cause all kinds of good things to happen
On 27 Feb 2014, at 12:46, Erik Muller wrote:
> On 2/27/14, 12:21 , Suresh Ramasubramanian wrote:
>> This has been around for several years now -
>> http://sourceforge.net/projects/cisco-conf-rep/
>
> But that's just archiving, like rancid, right?
This is not any kind of sensible answer to the
On 27 February 2014 10:39, Ryan Shea wrote:
> Very cool, thanks Erik. I can think of many ways to encode version
> metadata. Probably best to be somewhere in between overly verbose (full
> version $Id / date / author for every config chunk) and being unreadable
> (base64 encoded gzip of unique con
A lot of template management discussion focusses on using the network
configs as the canonical model of the network.
Storing the network model in the DB (whatever form that takes) is much
more sane.
There is the brownfields issue of populating that database and then
building device state from ther
On 2/27/14, 12:21 , Suresh Ramasubramanian wrote:
This has been around for several years now -
http://sourceforge.net/projects/cisco-conf-rep/
But that's just archiving, like rancid, right? Still doesn't have any
correlation to the template-management side of things. While having the
backup
Shea
Cc: nanog@nanog.org
Subject: Re: Managing IOS Configuration Snippets
On Thu, Feb 27, 2014 at 9:50 AM, Ryan Shea wrote:
> A couple more thoughts, regarding
>
> Network => DB
>
> I completely agree that trying to use the network config itself as the
> authority for what w
On Thu, Feb 27, 2014 at 10:34 PM, Erik Muller wrote:
> At a previous job, our roll-your-own solution was a template based system(*)
> generating full configs; all the version history for template sections,
> per-router local tweaks, and generated results was kept in RCS, and the
> actual last-conf
On 2/26/14, 16:22 , Ryan Shea 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.
...
Assume that this version encoding perfectly captures what is on the ro
On (2014-02-27 09:50 -0500), Ryan Shea wrote:
> Regarding the MD5 approach, let's also think that configlets could have
> "no" commands in them. In the NTP example I had before, if we wanted to
For DB => Template => Network it's to me very easy, but yes, each template you
make must have anti-temp
On Thu, Feb 27, 2014 at 9:50 AM, Ryan Shea wrote:
> A couple more thoughts, regarding
>
> Network => DB
>
> I completely agree that trying to use the network config itself as the
> authority for what we intend to be on a device is not the right long-term
> approach. There is still a problem with
On Thu, Feb 27, 2014 at 8:58 AM, Saku Ytti wrote:
> On (2014-02-26 17:37 -0500), Robert Drake wrote:
>
> > Consider looking at Tail-F's NCS, which according to marketing
> > presentations appears to do everything I want right now. I'd like
> > to believe them but I don't have any money so I can'
On (2014-02-26 17:37 -0500), Robert Drake wrote:
> Consider looking at Tail-F's NCS, which according to marketing
> presentations appears to do everything I want right now. I'd like
> to believe them but I don't have any money so I can't test it out.
> :)
Tail-F is probably least bad option out
Rancid with the git plugin can be used to attain pretty much the exact
same thing a lot more easily, if you're after an existing implementation
of it.
Cheers,
Paul
On 2/27/2014 午後 09:44, Harry Hoffman wrote:
Wow, this sounds fantastic! Have any code you can share?
Cheers,
Harry
On Feb 27,
Wow, this sounds fantastic! Have any code you can share?
Cheers,
Harry
On Feb 27, 2014 6:52 AM, Andrew Latham wrote:
>
> For a large install I set up a solution that might help. I utilized a
> Mediawiki install and its API to create, update and pull the
> configuration on many IOS devices. A w
For a large install I set up a solution that might help. I utilized a
Mediawiki install and its API to create, update and pull the
configuration on many IOS devices. A wiki page for the host name was
dynamically created and the configuration was placed there daily or
hourly. This allowed support to
We are evaluating a piece of software called Skybox:
http://www.skyboxsecurity.com/
It's geared to security analytics, but it does allow you to
define configurations that are expected on a device, what
software version it is running, whether commands that aren't
there are, and those th
On Wed, Feb 26, 2014 at 6:27 PM, Ryan Shea wrote:
> Robert - all great suggestions. Big cross-vendor configuration generation
> and deployment is outside the scope of what I was hoping for here. The goal
> is to have the version information somehow encoded into the configuration,
> and I'm not sur
On 2/26/2014 5:37 PM, Robert Drake wrote:
Most people roll their own solution. If you're looking to do that
consider using augeas for parsing the configuration files. It can be
really useful for documenting changes, and probably to diff parts of
the config. You might also consider rabbitm
On 2/26/2014 4:22 PM, Ryan Shea 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 f
30 matches
Mail list logo
