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 -----Original Message----- From: Chuck Church [mailto:chuckchurch@gmail.com] Sent: Tuesday, December 11, 2012 7:23 AM To: nanog@nanog.org Subject: RADB entry 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
On Tue, Dec 11, 2012 at 8:31 AM, Eric Krichbaum <eric@telic.us> wrote:
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.
'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 -----Original Message----- From: christopher.morrow@gmail.com [mailto:christopher.morrow@gmail.com] On Behalf Of Christopher Morrow Sent: Tuesday, December 11, 2012 8:51 AM To: Eric Krichbaum Cc: Chuck Church; nanog@nanog.org Subject: Re: RADB entry On Tue, Dec 11, 2012 at 8:31 AM, Eric Krichbaum <eric@telic.us> wrote:
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.
'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.
On Tue, Dec 11, 2012 at 10:00 AM, Eric Krichbaum <eric@telic.us> wrote:
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
-----Original Message----- From: christopher.morrow@gmail.com [mailto:christopher.morrow@gmail.com] On Behalf Of Christopher Morrow Sent: Tuesday, December 11, 2012 8:51 AM To: Eric Krichbaum Cc: Chuck Church; nanog@nanog.org Subject: Re: RADB entry
On Tue, Dec 11, 2012 at 8:31 AM, Eric Krichbaum <eric@telic.us> wrote:
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.
'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.
On Tue, Dec 11, 2012 at 10:17 AM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Tue, Dec 11, 2012 at 10:00 AM, Eric Krichbaum <eric@telic.us> wrote:
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.
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
-----Original Message-----
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
On Tue, Dec 11, 2012 at 10:11 AM, Chuck Church <chuckchurch@gmail.com> wrote:
-----Original Message-----
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?
http://www.merit.edu/mail.archives/nanog/2000-06/msg00414.html that thread is likely of interest...
Thanks,
Chuck
participants (4)
-
Christopher Morrow -
Chuck Church -
Eric Krichbaum -
Matt Addison