[AusNOG] Route filter update management advice.

[Andreux Fort]

On Wed, May 26, 2010 at 11:21 AM, Sean K. Finn
<sean.finn at ozservers.com.au> wrote:
>
> G’day all.
>
> Just curious to see if there are any easy ways or generally accepted methods of notifying upstream providers of AS path additions and IP range additions when downstream customers make changes?

Other than picking up the phone or using your email cilent, you mean? :)

>
> We’re at the point where we’re adding more AS’s behind our transit AS, and path’s are constantly changing and being added to.
>
>
> I know each of our upstream providers and peers generally does it manually (adds as path’s and ip ranges) at this stage, but I am looking for a better way of doing it.
>

As you should....

> I’ve checked RADB and thought about pulling info from there or publicly available sources, but nothing seems reliable.

The public RADB is mostly incomplete or inaccurate information,
unfortunately.  There are many autonomous systems that manage their
own routing databases (based on IRRd or RIPE WHOIS) using RtConfig
(part of the IRRToolset), however.


> Is it really just a case of needing to do this stuff manually forever more?

No, but as far as I still know, you'll need to build a system out of
tools like RtConfig.  If you are or know of some capable software
engineers, encourage them to build something open source that
satisfies the need without being written in (pretty nasty) C++ ;).
I'd certainly contribute.

Many years ago in a galaxy far away (well, in south melbourne), Mark
Prior wrote the 'Connect Routing System' at AS2764 which built
Connect's BGP router configs from RADB entries, using RtConfig (and a
lot of Perl, since RtConfig itself doesn't do everything that was
required, despite RPSL being able to express everything that was
necessary).  Note that the AS2764 aut-num policy object was somewhat
actually used by RtConfig to generate the configurations was more
complicated than the one visible on RADB.  Some of us maintained this
system and added hacks here and there.  The lessons I learned from
that were;

  * Doing both AS and prefix filtering (which was the original goal)
doesn't scale (mostly an issue of configuration), but if you don't
trust your customers, you'll need to do prefix filtering at least.
Some basic AS path filtering is a good idea (if you were able to leak,
say, youtube.com's prefix, that'd be really bad, but if you leaked
their AS, that's less bad, though you still look like a goose).

  * Trusting your customers to update RADB was pointless at best
(perhaps this is better now?  I really don't know).  Hence rolling
your own...

  * AS2764's public aut-num object was at the time the most complex
public aut-num object.  Not that they had the most complex routing
policy in the world (which tells you something about people's lack of
use of the tools)...

Also, RtConfig suffered from C++ creep over the years and ended up in
a largely uncompilable state, but this has recently been fixed (a
'cruft cleanup' version is available which compiles on many modern
systems).

There was a light-weight access-list generator for IOS/JunOS that used
a whois-server I quite liked that I used some years back, but I cannot
find it now :/.  I believe it was authored by someone in Russia and
was written in C, but that's all I remember.

> Cheers,
>
> Sean.

Cheers,
Andrew