[rancid] Reverse RANCID

[Alan McKinnon]

On 11/02/2015 18:54, Hagen, Skye (skyeh at uidaho.edu) wrote:
> I have been asked to do something similar where I work. The problem that I
> ran into was the verification process for certain kinds of jobs. For a
> simple change, that only affected the device itself, and if there was a
> problem, wouldn't cause a major outage, I could hack together some scripts
> to use clogin and do the job. But, when identical changes had to be made
> to several devices in coordination, no way. The number of ways things
> could go wrong, and the varieties of backout procedures, it just got too
> complex. And for something as potentially disruptive as making changes to
> a routing protocol, I always wanted to be hands on.
> 
> On the other side of RANCID, you have a repository that contains a near
> real-time copy of your device configurations. I have written a number of
> auditing scripts that will determine all routed networks, and compare them
> against our network management system to make sure all routed networks are
> defined. I also use this list of routed networks to audit ACL's, to make
> sure that we clean up related ACL's when we delete networks. I audit the
> VLAN's to make sure they are all contiguous across all our switches. I
> also have a configuration auditing system that will compare a
> configuration file against a set of rules, and check for compliance.
> 
> As I learned from an auditor, there are two ways to approach controlling
> something. Control it up front, or audit after the fact. In my case,
> auditing after the fact was a lot easier and quicker.


I have some experience in this area. My last job was at a large ISP and
my team dealt with deployment, auditing and tracking of the entire
network (2,000 PE and 30,000+ CE routers).

We ended up having to control up front *and* audit after the fact, and
it's the latter that was the horrible problem to solve. The basic
problem is that every tool out there seemed to work like rancid - it
records a diff but has no knowledge of what the diff might mean. It only
sees that a line changed, it can't tell that a VLAN was dropped for example.

So we ended up building a huge Cisco config parser that could read in a
config and turn it into a sane data structure with meaning (also
accounting for all the tiny variations in layout that Cisco have ever
published).

I could go on, but it was one of those truly horrible coding problems
that drives you bonkers and always requires human eyes. Definitely not a
"quick script" problem and not something I'd recommend trying to
shoehorn into rancid's codebase.


> 
> Skye.
> 
> 
> On 2/11/15, 7:31 AM, "Alan McKinnon" <alan.mckinnon at gmail.com> wrote:
> 
>> On 11/02/2015 14:02, James Bensley wrote:
>>> Hi All,
>>>
>>> I am think about writing a web interface that uses RANCID in the
>>> background to make configuration changes on devices. Since RANCID has
>>> a bunch of scripts for various device types my thinking is a
>>> simple-ish web interface in which I can paste in some config and then
>>> use RANCID to log into the device and input the config, also though I
>>> can specify some commands and RANCID will run though them and capture
>>> output which can be passed to Bash/PERL/Python scripts to interogate
>>> the output and check that the BGP sessions have come back up or that
>>> the number of routes in a VRF is still the same etc.
>>>
>>> The goal is: Anything I do on the CLI when making changes to devices
>>> can be automated.
>>>
>>> I know I can push config using the RANCID CLI wrapper scripts but I'm
>>> wondering if anyone has done this before to extend RANCID to also run
>>> "show" style commands and interogated the output to make checks to
>>> valid the success of the change, and also if anyone has made a web
>>> interface already (other than the CVS types for RANCID's normal
>>> purpose of backing up rather than pushing config) ?
>>
>>
>>
>> It doesn't make sense to extend rancid in this way.
>>
>> Consider rancid's purpose: it logs in, captures the config, diffs it and
>> stores the result. Then tells you what the diff is.
>>
>> None of that involves in any way changing the device in question and it
>> is highly recommended that you lock down the rancid user to only the
>> specific commands listed in @commands.
>>
>>
>> There is one part of rancid that enables you to do config changes
>> however: clogin
>>
>> Rather do something like this:
>> Get the changes you want to make from the user, apply them using clogin
>> and then write a framework that will do the double-checking you
>> describe. Rancid itself has no code you can leverage to do any of that.
>> It's best done in an entirely separate system, with the added benefit
>> that rancid will come along in an hour and record the fact of a change
>> made.
>>
>> All this depends however on your Risk department being OK with the idea.
>> I know mine would shoot me at the very thought :-)
>>
>>
>>
>>
>>
>>
>> -- 
>> Alan McKinnon
>> alan.mckinnon at gmail.com
>>
>> _______________________________________________
>> Rancid-discuss mailing list
>> Rancid-discuss at shrubbery.net
>> http://www.shrubbery.net/mailman/listinfo/rancid-discuss
> 
> _______________________________________________
> Rancid-discuss mailing list
> Rancid-discuss at shrubbery.net
> http://www.shrubbery.net/mailman/listinfo/rancid-discuss
> 
> 


-- 
Alan McKinnon
alan.mckinnon at gmail.com