[116676] in North American Network Operators' Group
Re: Follow up to previous post regarding SAAVIS
daemon@ATHENA.MIT.EDU (Joe Maimon)
Thu Aug 13 10:07:51 2009
Date: Thu, 13 Aug 2009 10:07:29 -0400
From: Joe Maimon <jmaimon@ttec.com>
To: Richard A Steenbergen <ras@e-gerbil.net>
In-Reply-To: <20090812212305.GN51443@gerbil.cluepon.net>
Cc: "nanog@nanog.org" <nanog@nanog.org>, nanog-post@rsuc.gweep.net
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Richard A Steenbergen wrote:
> On Wed, Aug 12, 2009 at 04:57:07PM -0400, Jared Mauch wrote:
>> I've come to the conclusion that if someone put a nice web2.0+
>> interface on creating and managing these objects it would be a lot
>> easier.
>
> Agreed, this is one of the projects I've been working on just haven't
> had the time to finish it. But please allow me to put in a shameless
> plug for IRR PowerTools, which many networks (including a couple tier
> 1s) use to do their IRR:
>
> http://sourceforge.net/projects/irrpt/
>
> The highlights are:
>
> * Automated retrieval of prefixes registered behind an IRR Object.
> * Automatic exclusion of bogon or other configured undesirable routes.
> * Tracking and long-term recording of prefix changes over time.
> * Automatic aggregation to optimize data and reduce unnecessary changes.
> * E-mail updates, letting users know that their change was processed.
> * E-mail alerts to the ISP, letting them know of new routing changes.
> * E-mail alerts to non-IRR using networks, with plain text changes.
> * Router config generation, for easy automated config deployment.
>
> I'm also in the process of beta testing a new 2.0 version which will be
> significantly rewritten for easier more scalable use, have a lot fewer
> dependencies, integrate better with db backend systems to customer
> prefix-list management, and fully support IPv6. Oh and there might just
> be a web gui for managing and using it too, if I can find a decent web
> developer who will do it for free. :) I'm hoping to have this out in the
> next couple of months.
>
The longer a network develops without using or maintaining IRR data, the
more difficult the transition becomes. A truly awesome capability would
be to have some way to slurp in current configuration and output IRR
objects that can then generate a functionally identical configuration.
Even without that, I would happily settle for any improvements to irr
tools, powertools or toolsets. I am sort of disappointed that there
seemed to be far less then deserved support from those with a stake in
this, the registries and vendors.
Joe
