Follow up to previous post regarding SAAVIS
jmaimon at ttec.com
Thu Aug 13 09:07:29 CDT 2009
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
> 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:
> 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.
More information about the NANOG