Anyone,
Hopefully this is a simple question about RADB. I'm
supporting a small wireless ISP, they just recently added a second upstream
connection - Charter (AS 20115). The IP space was originally issued by the
other upstream Windstream (AS 7029). Looking at a few resources such as the
bgp.he.net to see who peers with who and looking glasses, it seems that not
all of AS 20115 peers are accepting our prefix. AT&T is an example -
AS7018. In one case, it's an upstream 2 levels up - Century Link accepts
from Charter, but Level 3 doesn't accept it from Century Link. Charter uses
RADB. The entry for the prefix looks like this:
route: 75.77.38.0/23
descr: Vybrent_Communications AS26296
origin: AS20115
mnt-by: MAINT-CHTR-WD
changed: x@chartercom.com 20121207 #18:55:23Z
source: RADB
route: 75.77.38.0/23
descr: Community Connect LLC
remarks: Proxy Registered Customer Route
remarks: SWIP from NUVOX
origin: AS26296
member-of: RS-NUVOX-CUSTOMERS-NONRIR
mnt-by: MAINT-AS11456
changed: x@nuvox.com 20080519
source: RADB
75.77.38.0/23 is our prefix. Our AS is 26296. Does that entry look right?
I'm wondering if the 'origin' AS in the Charter entry is correct, since that
is Charter's AS, not ours. To avoid confusion, Nuvox is the ISP that
Windstream bought out, hence the name change. Vybrent and Community Connect
are the same company by the way as well. Other than RADB, are there any
other database registries that should be checked to make sure the info is
right?
Thanks,
Chuck
While not 100% accurate, it is very common. The origin being entered by a
provider as their own allows them to add the prefix (and have it accepted by
anyone who filters them by prefix generated) without being forced to add a
downstream (and downstream's downstreams) AS to their AS-SET. In general,
if an entity does their own IRR somewhere, I'd guess that the correct
AS-SET/etc. should be accepted easily and used. This is just a shortcut for
providers when a customer says "Add this prefix for me please".
Eric
'proxy registration'... so nice... now you can't control your prefix
data in radb, how quaint!
'proxy registration' - never a good idea... not ever... adding cruft
that's not connected to the data owner to the database? recipe for
stale/old-n-busted data... hurray.
Absolutely. I'd rather see it done responsibly. It's hard to get rid of
bad data/incorrect data/stale data and it shouldn't be. If done properly,
it would be much friendlier. There is incentive for people to put data in
but not to remove the other.
Eric
From: Eric Krichbaum [mailto:eric@telic.us]
Sent: Tuesday, December 11, 2012 8:31 AM
To: 'Chuck Church'; nanog@nanog.org
Subject: RE: RADB entry
While not 100% accurate, it is very common. The origin being entered by a
provider as their own allows them to add the prefix (and have it accepted by
anyone who filters them >by prefix generated) without being forced to add a
downstream (and downstream's downstreams) AS to their AS-SET. In general,
if an entity does their own IRR somewhere, I'd >guess that the correct
AS-SET/etc. should be accepted easily and used. This is just a shortcut for
providers when a customer says "Add this prefix for me please".
Eric
So if I understand how RADB works, ISPs can poll it frequently and update
their filters automatically (or semi-automatically). Is there risk of a
polling ISP's system seeing this data, and being confused by one ISP listing
the origin as the correct one, and the other ISP listing the origin as their
own? Can an upstream create a registration for us in RADB the correct way,
or does that require us having our own account on RADB? I'm guessing I'm
wondering what is the 'most correct' way?
Thanks,
Chuck
Absolutely. I'd rather see it done responsibly. It's hard to get rid of
bad data/incorrect data/stale data and it shouldn't be. If done properly,
it would be much friendlier. There is incentive for people to put data in
but not to remove the other.
and in the name of expediency providers proxy-register for their downstreams...
route: 209.85.252.79/32
descr: GOOGLE/GOO/611
origin: AS15412
notify: notify@flagtelecom.com
mnt-by: MAINT-FLAG-CUSTOMER
changed: hostmaster@flagtelecom.com 20100524
source: RADB
thanks flag, I needed that... could you remove it pls? (note I've
attempted a few times to get flag to remove this, so far no joy.
(one example of many...)
-chris
From: Eric Krichbaum [mailto:eric@telic.us]
Sent: Tuesday, December 11, 2012 8:31 AM
To: 'Chuck Church'; nanog@nanog.org
Subject: RE: RADB entry
While not 100% accurate, it is very common. The origin being entered by a
provider as their own allows them to add the prefix (and have it accepted by
anyone who filters them >by prefix generated) without being forced to add a
downstream (and downstream's downstreams) AS to their AS-SET. In general,
if an entity does their own IRR somewhere, I'd >guess that the correct
AS-SET/etc. should be accepted easily and used. This is just a shortcut for
providers when a customer says "Add this prefix for me please".
Eric
So if I understand how RADB works, ISPs can poll it frequently and update
their filters automatically (or semi-automatically). Is there risk of a
polling ISP's system seeing this data, and being confused by one ISP listing
the origin as the correct one, and the other ISP listing the origin as their
own? Can an upstream create a registration for us in RADB the correct way,
or does that require us having our own account on RADB? I'm guessing I'm
wondering what is the 'most correct' way?
that thread is likely of interest...
When I had stale entries on RADB I emailed db-admin over there and
they removed them. Was back in '09 so don't know if policy may have
changed in the meantime. Also had entries pulled from SAVVIS and
LEVEL3 registries by emailing their respective admins. List of
contacts for the respective IRR instances can be found at:
http://www.irr.net/docs/list.html
~Matt