Is it unusual to remove defunct rr objects?

Ca By cb.list6 at gmail.com
Sat Nov 1 16:16:31 UTC 2014


On Friday, October 31, 2014, Jared Mauch <jared at puck.nether.net> wrote:

> On Fri, Oct 31, 2014 at 10:34:23AM -0700, Tim Howe wrote:
> >       I've since found a disturbing number of defunct objects that
> > relate to my customers (and me) in a similar way, and I have mostly
> > had success in getting them cleared up.  If my relatively small
> > customer base is any indication, there are more incorrect objects out
> > there than correct ones.  I feel this is something I should have been
> > looking into sooner.
>
>         People tend to treat things like IRR (eg: RADB, etc) as a
> garbage pit you toss things into and never remove from.


+1, it is a garbage pit

Do whatever it takes to deploy today

move on, dont look back or update,

 failover between isps fails, emergency update.

Back to sleep

If its not systematicly automated for grandma, it is broken and will only
be patched by exception / interrupt



> >       Is this a non-issue that I shouldn't worry about?  Doesn't the
> > quality of this data effect Origin Validation efforts?
>
>         Yes it does.  This has a fairly severe impact for those that build
> off the IRR data for filters.  We have seen customers end up including
> AS7018 in their AS-SET or as you noticed have other legacy routes appear.
>
> >
> >       Sorry that this turned out so long; I wanted to give some
> > context.
>
>         No worries.  I've got a transient routing leak detector
> that does find/fuzz these issues which has been running for a few
> years now.  I'm guessing you may see some of the related prefixes
> there as a result.  It's in need of a U/I redesign (code welcome)
> but is located here:
>
>         http://puck.nether.net/bgp/leakinfo.cgi
>
>         - Jared
>
> --
> Jared Mauch  | pgp key available via finger from jared at puck.nether.net
> <javascript:;>
> clue++;      | http://puck.nether.net/~jared/  My statements are only
> mine.
>


More information about the NANOG mailing list