[AusNOG] Wiki for network ops

[Andrew Fort]

On Thu, Oct 6, 2011 at 8:13 PM, Sean K. Finn <sean.finn at ozservers.com.au> wrote:
>> I'd been using Fisheye at a few different places for source code diffing, and for RANCID (or PUNC ;-) configs obviously that is good too, but it doesn't specifically provide you any benefits over using CVSweb or whatever (it looks a little nicer, however).  Fisheye also talks to git and mercurial.  Even perforce, if > you're stuck with that brand of evil.
>
> Hi Andrew,
>
> Can you please tell me more about PUNC and your experiences with it?

I may be biased, as I wrote it ;)

PUNC is a RANCID replacement.

I needed a bunch of new devices supported by RANCID for a job I was
doing, and also needed to be able to execute CLI commands on them
arbitrarily.  I'd already written notch
(http://code.google.com/p/notch) as a way of solving that problem (as
an orchestration layer for routers), and so PUNC is just a client
which does what RANCID does, for a different array of platforms,
though fewer than RANCID itself. I'm unlikely to write an Alteon WebOS
module for it like I did for RANCID, for example ;-).

Though there's not much talk about Notch and the installation could be
far easier, there's a couple of users with big networks in the US
using it for maint and diag work (via the "Mr. CLI" multi-router CLI
that's available and some custom scripts they wrote themselves).

To that end, one can expect better sharding rules for large
deployments, e.g., geographical distribution, coming to the notch
client soon, as well as improved load balancing in general.

> Do you have a link to the one you are referring to, and;

http://code.google.com/p/punc/
http://code.google.com/p/notch/
http://code.google.com/p/mr-cli/  (use w/
http://code.google.com/p/netmunge/ to have Mr. CLI parse the router
output into structured data)

> How does it compare to RANCID etc in compatability with multiple devices and backing up configs etc, or is it used differently?

It uses mercurial (hg) for config storage.  This also means you can
run hgweb easily for the web differ, and it is compatible into other
things like fisheye, crucible, etc.

It doesn't support as many device types as RANCID.

Though you can make RANCID scale better on a single box (due to its
simple process based design), beyond the limits of a single machine,
RANCID is difficult to build into a greater system.  Notch provides a
lot of benefits at that level, but in a small network, it's more about
the type of clients one might build with it...

It's a different beast.  It's 15 years newer.  As a result, far fewer
people use it, and there's not the community that RANCID has.  I
mostly used PUNC to solve a problem I had for a customer; Notch (and
its predecessor that I wrote while at Google) was written to try to
bring some programmatic access to devices whose vendors will never
show them that love.

An alternative approach to the "I like RANCID but I want to distribute
it" problem is to rewrite *login scripts as Notch clients calling one
or more Notch agent tasks.  You could then allow configuration
collection to be done centrally (or not), while the device
communication is done in a distributed fashion.  This becomes a
problem when your network has thousands of devices and you want RANCID
runs to occur on a frequent basis.  Doing this would require nothing
but backing up the old *login scripts and replacing them with symlinks
or copies of the ones which use the Notch agent instead;  the rest of
the RANCID output parsing pipeline would remain the same.  The diffs
would end up in the same place, etc.

If someone is interested in this idea, and has a fairly limited device
set (at least at present), please get in touch.  A bonus is that if
you think it stinks, you can back out just as easily :)

The devices supported are listed below, in the code.  The VENDOR_MAP
there takes a RANCID router.db device type (where there was a device
type matching), have a look at the modules pointed to for a little
more info on the device specifics.

http://code.google.com/p/notch/source/browse/notch/agent/device_factory.py

For what it's worth, the system that led to Notch also had a RANCID
replacement written for it (which was vaguely similar to PUNC).  That
cut the collection time for a network of almost two thousand devices
by 66% (a secondary goal of producing zero code-originated diff to the
config files during the cutover was also achieved).

So with a large network, there's reasons to consider alternatives.
But at the small size, the community and history behind RANCID make it
preferable for many shops (unless they really hate Tcl and Perl ;-).

Thanks,
-a

>
> S.
>
> _______________________________________________
> AusNOG mailing list
> AusNOG at lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog
>