Re: [db-wg] db-wg Digest, Vol 39, Issue 12
помочь 2014-11-25 13:00 GMT+02:00 <db-wg-request@ripe.net>:
Send db-wg mailing list submissions to db-wg@ripe.net
To subscribe or unsubscribe via the World Wide Web, visit https://www.ripe.net/mailman/listinfo/db-wg or, via email, send a message with subject or body 'help' to db-wg-request@ripe.net
You can reach the person managing the list at db-wg-owner@ripe.net
When replying, please edit your Subject line so it is more specific than "Re: Contents of db-wg digest..."
Today's Topics:
1. Re: source: field for non RIPE address space (Job Snijders) 2. Re: source: field for non RIPE address space (Job Snijders) 3. Re: source: field for non RIPE address space (Randy Bush) 4. Re: source: field for non RIPE address space (Randy Bush) 5. Re: source: field for non RIPE address space (Job Snijders)
----------------------------------------------------------------------
Message: 1 Date: Mon, 24 Nov 2014 19:16:54 +0100 From: Job Snijders <job@instituut.net> Subject: Re: [db-wg] source: field for non RIPE address space To: Edward Shryane <eshryane@ripe.net> Cc: Kaveh Ranjbar <kranjbar@ripe.net>, db-wg@ripe.net, Nigel Titley <nigel@titley.com> Message-ID: <20141124181654.GD44694@Vurt.local> Content-Type: text/plain; charset=us-ascii
On Thu, Nov 20, 2014 at 06:41:16PM +0100, Job Snijders wrote:
On Thu, Nov 20, 2014 at 03:03:49PM +0100, Edward Shryane wrote:
I checked all route objects in the RIPE database, against the delegated stats file for each region, and found which region the (IPv4) address space belongs in.
RIPE: 185,537 ARIN: 7,609 AFRINIC: 37,683 LACNIC: 1,930 APNIC: 2,004
Edward was kind enough to provide me with data dumps. I've run some simple seek & count code, comparing the route objects (and their real source) and the BGP table:
Correct route object, prefix-length, origin which are visible in BGP DFZ: IPv6 IPv4 AFRINIC: 72 7146 APNIC: 17 498 ARIN: 264 4030 LACNIC: 11 1448 OTHER: 2 NaN RIPE: 6430 106081
Registered route objects which are NOT visible in BGP DFZ: IPv6 IPv4 AFRINIC: 95 31018 APNIC: 9 515 ARIN: 168 2694 LACNIC: 15 448 OTHER: 0 NaN RIPE: 3038 78393
Correct route object prefix length, wrong origin & visible in BGP DFZ: IPv6 IPv4 AFRINIC: 7 582 APNIC: 3 1002 ARIN: 84 1085 LACNIC: 0 35 OTHER: 45 NaN RIPE: 357 10896
OK, so what does this mean?!
If we proceed with our plan to set 'source: RIPE-NONAUTH' for objects, the prefixes from the first category (correct length & origin & visible) might be impacted. Roughly 13k prefixes, of which ARIN & AFRINIC are the largest. The real number might be lower as it is quite possible that route objects for those 13k prefixes exist in other registries as well. Curiously enough running those 13122 prefixes through aggregate(1), the set is shrunken down to only 3941 prefixes.
So, what's next? Please share your thoughts & insights.
Kind regards,
Jobi
ps. My data and crude scripts are available here: http://instituut.net/~job/correlate-route-objects-with-bgp-ripe/
------------------------------
Message: 2 Date: Tue, 25 Nov 2014 00:34:34 +0100 From: Job Snijders <job@instituut.net> Subject: Re: [db-wg] source: field for non RIPE address space To: Randy Bush <randy@psg.com> Cc: Database WG <db-wg@ripe.net> Message-ID: <20141124233434.GG44694@Vurt.local> Content-Type: text/plain; charset=us-ascii
On Tue, Nov 25, 2014 at 08:28:55AM +0900, Randy Bush wrote:
Correct route object prefix length, wrong origin & visible in BGP DFZ:
is this not legitimate in a make before break origin transfer? of course, many will forget to clean old up afterward.
Yes, good remark.
I have not attempted to figure out why those route objects are there.
One could for instance take a wider time window for the BGP data (6 months?) and run the correlations to assess which are in transfer/mbb and which potentially are stale garbage.
Kind regards,
Job
------------------------------
Message: 3 Date: Tue, 25 Nov 2014 08:35:56 +0900 From: Randy Bush <randy@psg.com> Subject: Re: [db-wg] source: field for non RIPE address space To: Job Snijders <job@instituut.net> Cc: Database WG <db-wg@ripe.net> Message-ID: <m2r3ws6ujn.wl%randy@psg.com> Content-Type: text/plain; charset=US-ASCII
Correct route object prefix length, wrong origin & visible in BGP DFZ: is this not legitimate in a make before break origin transfer? of course, many will forget to clean old up afterward. I have not attempted to figure out why those route objects are there.
is there a second route: object for the same prefix which is correct?
randy
------------------------------
Message: 4 Date: Tue, 25 Nov 2014 08:28:55 +0900 From: Randy Bush <randy@psg.com> Subject: Re: [db-wg] source: field for non RIPE address space To: Job Snijders <job@instituut.net> Cc: Database WG <db-wg@ripe.net> Message-ID: <m2tx1o6uvc.wl%randy@psg.com> Content-Type: text/plain; charset=US-ASCII
Correct route object prefix length, wrong origin & visible in BGP DFZ:
is this not legitimate in a make before break origin transfer? of course, many will forget to clean old up afterward.
randy
------------------------------
Message: 5 Date: Tue, 25 Nov 2014 00:46:38 +0100 From: Job Snijders <job@instituut.net> Subject: Re: [db-wg] source: field for non RIPE address space To: Randy Bush <randy@psg.com> Cc: Database WG <db-wg@ripe.net> Message-ID: <20141124234638.GH44694@Vurt.local> Content-Type: text/plain; charset=us-ascii
On Tue, Nov 25, 2014 at 08:35:56AM +0900, Randy Bush wrote:
Correct route object prefix length, wrong origin & visible in BGP DFZ: is this not legitimate in a make before break origin transfer? of course, many will forget to clean old up afterward. I have not attempted to figure out why those route objects are there.
is there a second route: object for the same prefix which is correct?
Quickly ran something for IPv4:
{'AFRINIC': 99, 'APNIC': 10, 'ARIN': 112, 'LACNIC': 1, 'RIPE': 6200}
This means there are 99 objects which fall within AfriNIC administrated space which have an origin not seen in the DFZ, but a _correct_ route object already exists.
Kind regards,
Job
End of db-wg Digest, Vol 39, Issue 12 *************************************
participants (1)
-
nikolaj ilchik