In the recent past, we've had another provider in our same market
erroneously advertising prefixes for some of our customers.
After we got it cleared up, I noticed that there were some old
route objects in RADB that were entered for that provider years ago by
360. These route objects, in a sense, legitimized, the erroneous
advertisements by matching the prefixes to that providers ASN. As that
provider no longer uses 360/Zayo, I asked Zayo if they could remove the
objects. Once the request made it to someone who understood what I was
asking, they spent some time and effort over the next few weeks (much
appreciated by me, I might add) in hunting down the info they needed to
(I assume) manage the old 360 maintnr object. They then removed the
offending objects (again, my thanks).
One of the Zayo support folks mentioned to me, somewhat
apologetically, that it took some time as nobody had ever made such a
request before. So this got me wondering: is it really such a rare
thing to manage ones route objects such that old defunct data is
removed? I'm not under the impression that the issue I had would have
been alleviated any by the related route objects having been removed
beforehand, but their existence wasn't helping me any either.
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.
Is this a non-issue that I shouldn't worry about? Doesn't the
quality of this data effect Origin Validation efforts?
Sorry that this turned out so long; I wanted to give some
context.
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.
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:
People tend to treat things like IRR (eg: RADB, etc) as a
garbage pit you toss things into and never remove from.
So who do we ask about making IRRs expire defunct objects and/or
changing their system design to ensure that the legitimate resource holder
can remove references to their prefix from ASes they no longer
authorize to carry them,
without requiring all sorts of assistance, cooperation, and
willingness from the AS maintainer?
I have my own ideas on this topic, including routes that have
not been seen for over 1 year. You may always miss the routes that
are not 'seen' on the public internet though. I'm still reminded of
the question on the internic forms in early 90s about "will you be
connecting to the internet" when asking for address space.
> So who do we ask about making IRRs expire defunct objects
you might start with a rigorous definition of defunct
I have my own ideas on this topic, including routes that have
not been seen for over 1 year. You may always miss the routes that
are not 'seen' on the public internet though. I'm still reminded of
the question on the internic forms in early 90s about "will you be
connecting to the internet" when asking for address space.
Do the internet route registries exist to track routes that are not
to appear on the public internet? I think not.
There should probably be an attribute provided for such objects,
however, that would indicate "This route does not appear on the
public internet".
If not tagged like that in some manner, and a matching route does has
not appeared on the public internet at any time during the past 6 to
12 months, then I would consider the registry object to be defunct.
> 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
I can come up with a number of examples, but the ones that
concern me the most are route objects where the route should not (or
should no longer) originate from the origin AS.
Some of these that I found were probably never correct. I can
detail what I think were the chain of events that led to their
creation, but I'm not sure it would be On Topic.
I have been asking the folks who manage the maintnr object
in question. I have so far been mostly successful. I spend varying
amounts of time explaining myself... /Sometimes/ simply pasting the
object in an email to the right person is all that is needed.
Do the internet route registries exist to track routes that are not
to appear on the public internet? I think not.
What's "the public Internet"? Does it mean "the DFZ as seen at Jimmy
Hess' router, with his set of upstreams"? If so, I can assure you
that there are plenty of routes that need to pass filters that are (or
optimally would be) built off of IRR data that would not pass this
test.
There should probably be an attribute provided for such objects,
however, that would indicate "This route does not appear on the
public internet".
see above.
If not tagged like that in some manner, and a matching route does has
not appeared on the public internet at any time during the past 6 to
12 months, then I would consider the registry object to be defunct.
Where on the public Internet?
Do networks run by organizations such as SITA, ARINC, BT Radianz, UK
MOD, and US DOD that use globally unique space and may interconnect
with each other in some way (and could hypothetically be using
IRR-type structures to describe that routing policy though I don't
think the military does that) get their objects unceremoniously booted?
Why would I want routes from US DOD in my filters, if this stuff is not
supposed to be on the public internet? That is a waste of everyones
ressources.
