I did a little experiment yesterday. I fetched the entire ripe.db.route file from the ripe.net FTP server and for each route specified in that file (a total of 245,890 routes) I extracted the base IPv4 address of the route and then looked that address up within the asn.routeviews.org DNS zone, which is kindly provided by the Routeviews Project at the Advanced Network Technology Center at the University of Oregon. That DNS zone allows users to quickly find the _actual_ route and ASN that is currently associated with any given IPv4 address. The results of my little experiment are simple to summarize. 10,829 of the base addresses listed in the ripe.db.route file are not actually being routed at the present time (at least they weren't, yesterday, at the time I ran this analysis). Of the remaining 235,061 route base IP addresses, fully 28,988 of those (12.3%) are being announced by some AS other than the one specified in the ripe.db.route file. My results file is available here: ftp://ftp.tristatelogic.com/pub/ripe.db.route.routecheck In that file, any line containing only one field -is- being routed and -is- being routed by the AS specified in the ripe.db.route file. Lines in the results file with contain exactly two whitspace separated fields are not currently being routed. Lines in the results file that contain exactly three whitspace separated fields are being routed by some AS other than the one called for within the ripe.db.route file. In these cases, field #1 is the route from the ripe.db.route file, field #2 is the AS number from the ripe.db.route file, and field #3 is the ASN that is _actually_ routing the base IP address at the present time (as of yesterday). Given the considerable number of routing anomalies revealed by my simple experiment, I am inclined to wonder who is actually using all of that route information in the RIPE DB, and what on earth they could be using it for. If anyone could enlighten me on this point, I would appreciate it.
Hi Ronald,
I am inclined to wonder who is actually using all of that route information in the RIPE DB, and what on earth they could be using it for.
That is a very good question. RPSL is a means of documenting an autonomous system's routing policy. It can be used in many ways. It might be used to build router configurations and filter lists, but usually only towards the 'edge' and only among a limited set of service providers (we use an internal IRR for building our customer filter lists). It might be used to model inter-domain relationships, but that way you're modelling the documentation rather than the actual relationships. It might be used to generate ASCII art. As with all forms of documentation, it accumulates cruft. I'm actually quite encouraged by your figures. I wonder if some of them might be skewed slightly by the presence of multiple route entries in the database though? An ugly pipleline of unix commands suggests that 10,098 routes in your analysis file have 2 entries, 408 routes have three entries, 15 routes have four entries, one route has six entries and five routes have over 30 entries each. 224224 1 10098 2 408 3 15 4 1 6 1 32 4 37 I've not used the DNS interface to route-views, but if it only returns a single entry per query, then for all of the routes with multiple route objects, all but one of them will be inconsistent in your analysis, even if the route is advertised (say for purposes of quick-and-easy multihoming) by multiple ASNs. To pick one at random: 91.207.202.0/23 12968 50625 91.207.202.0/23 91.207.202.0/23 12741 50625 There are three route: objects, one of which is correct, but two are either outdated, or may be there for multihoming. Looking at RIPEstat's routing history: <https://stat.ripe.net/widget/routing-history#w.resource=91.207.202.0%2F23> Shows it was announced by AS12968 from ~2008 to ~2010, and then by AS50625 since then. The other route object, AS12741, was only created on the 29th October, so could be a migration about to happen. That may not be an appreciable dent in your near-30,000 inconsistencies, but it might be some of them, and might suggest you're entering a murky world. Cheers, Rob
In message <BF4E0C89-3D99-4195-B8B1-56F8C1BD96FD@nosc.ja.net>, Rob Evans <rhe@nosc.ja.net> wrote:
I am inclined to wonder who is actually using all of that route information in the RIPE DB, and what on earth they could be using it for.
That is a very good question. ... As with all forms of documentation, it accumulates cruft. I'm actually quite encouraged by your figures. I wonder if some of them might be skewed slightly by the presence of multiple route entries in the database though? An ugly pipleline of unix commands suggests that 10,098 routes in your analysis file have 2 entries,
Correct. As I stated, all those 10,098 represent the routes that are described in the ripe.db.route file but where the _base address_ of the route is not actually being announced by anyone at present.
408 routes have three entries, 15 routes have four entries, one route has six entries and five routes have over 30 entries each.
I hope not! If you look _only_ at whitespace as field separators, then the lines in my results file should all have only one, or two or three fields. I do grant you that if you were to consider _commas_ also as field separators, then my results file would appear differently to you, for example, with respect to these lines: 83.230.32.0/20 35434 {197588,199551} 41.196.30.0/24 24863 {37193,64608,64624} The above lines... which still do only contain three whitespace separated fields... look rather funny, relative to all other lines of my results file, but that is due to an artifact of the way the TXT records within the asn.routeviews.org zone file have been constructed. That curly brace notation, when seen in one of these TXT records of that zone, indicates that there are multiple ASNs actually announcing the prefix at the present time. But as you can see in the above two lines, there are still discrepancies between what is in the RIPE DB and what ASNs are actually announcing the routes at the present time.
I've not used the DNS interface to route-views, but if it only returns a single entry per query, then for all of the routes with multiple route objects, all but one of them will be inconsistent in your analysis, even if the route is advertised (say for purposes of quick-and-easy multihoming) by multiple ASNs.
You make a good and very valid point. If I run this analysis again, I will make an effort to adjust for the exact possibility you just described.
That may not be an appreciable dent in your near-30,000 inconsistencies...
Correct. It probably would not. But I do like to be accurate. Regards, rfg
Hi, On Wed, Nov 19, 2014 at 06:31:56PM -0800, Ronald F. Guilmette wrote:
Of the remaining 235,061 route base IP addresses, fully 28,988 of those (12.3%) are being announced by some AS other than the one specified in the ripe.db.route file.
To state something that might be obvious or not - for the same prefix, you can have multiple route: entries with different origin ASes, which makes sense when a network moves (add new route: object, start new announcement, eventually remove old route: object). So, some of these might be perfectly fine, some might be forgotten (= a route: object with the proper origin AS exists as well), and some might just be legacy garbage - indeed.
Given the considerable number of routing anomalies revealed by my simple experiment, I am inclined to wonder who is actually using all of that route information in the RIPE DB, and what on earth they could be using it for.
We use it to build BGP filters for BGP customers. For those, the filter is build using the origin AS as key, so if there are additional route objects for the same prefix but with a different origin AS, our script won't see them, so it's "garbage that does not disturb anything". Of course, if the origin AS doesn't match at all, customers' BGP announcements won't go out - and they usually notice that quickly and fix their stuff. (Our upstream providers do the same thing for us, so it's used on a larger scale - unfortunately, not all large transit providers do that, some just take the money and look the other way) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Given the considerable number of routing anomalies revealed by my simple experiment, I am inclined to wonder who is actually using all of that route information in the RIPE DB, and what on earth they could be using it for.
We use it to build BGP filters for BGP customers.
Ditto, as are many others. Dave.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le 21/11/2014 10:08, Gert Doering a écrit :
Hi,
On Wed, Nov 19, 2014 at 06:31:56PM -0800, Ronald F. Guilmette wrote:
Of the remaining 235,061 route base IP addresses, fully 28,988 of those (12.3%) are being announced by some AS other than the one specified in the ripe.db.route file.
To state something that might be obvious or not - for the same prefix, you can have multiple route: entries with different origin ASes, which makes sense when a network moves (add new route: object, start new announcement, eventually remove old route: object). So, some of these might be perfectly fine, some might be forgotten (= a route: object with the proper origin AS exists as well), and some might just be legacy garbage - indeed.
Given the considerable number of routing anomalies revealed by my simple experiment, I am inclined to wonder who is actually using all of that route information in the RIPE DB, and what on earth they could be using it for.
We use it to build BGP filters for BGP customers.
So did I at previous employer's edge, for years and years.
For those, the filter is build using the origin AS as key, so if there are additional route objects for the same prefix but with a different
origin AS,
our script won't see them, so it's "garbage that does not disturb anything".
Of course, if the origin AS doesn't match at all, customers' BGP announcements won't go out - and they usually notice that quickly and fix their stuff.
Yes, voilà, same.
(Our upstream providers do the same thing for us, so it's used on a larger scale - unfortunately, not all large transit providers do that, some just take the money and look the other way)
Right, shared view. Cheers, mh
Gert Doering -- NetMaster
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlRvBMkACgkQZNZ/rrgsqafVWACgkueQOPf6h5cEdjWJy6zzBRM1 +n0An0CaPJAlnWyuD6t1Hzr7Yrp7RhrW =N+tK -----END PGP SIGNATURE-----
Same - we poll all the major RR every 24 hours. Our scripts will automatically add or remove prefixes based on matching origin key From: routing-wg-bounces@ripe.net [mailto:routing-wg-bounces@ripe.net] On Behalf Of Michael Hallgren Sent: Friday, November 21, 2014 9:25 AM To: routing-wg@ripe.net Subject: Re: [routing-wg] Who uses the RIPE IRR and for what? -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le 21/11/2014 10:08, Gert Doering a écrit :
Hi,
> > On Wed, Nov 19, 2014 at 06:31:56PM -0800, Ronald F. Guilmette wrote: >> Of the remaining 235,061 route base IP addresses, fully 28,988 of >> those (12.3%) are being announced by some AS other than the one >> specified in the ripe.db.route file. > > To state something that might be obvious or not - for the same prefix, > you can have multiple route: entries with different origin ASes, which > makes sense when a network moves (add new route: object, start new > announcement, eventually remove old route: object). So, some of these > might be perfectly fine, some might be forgotten (= a route: object with > the proper origin AS exists as well), and some might just be legacy > garbage - indeed. > >> Given the considerable number of routing anomalies revealed by my simple >> experiment, I am inclined to wonder who is actually using all of that >> route information in the RIPE DB, and what on earth they could be using >> it for. > > We use it to build BGP filters for BGP customers. So did I at previous employer's edge, for years and years.
> > For those, the filter is build using the origin AS as key, so if there are > additional route objects for the same prefix but with a different origin AS, > our script won't see them, so it's "garbage that does not disturb anything". > > Of course, if the origin AS doesn't match at all, customers' BGP announcements > won't go out - and they usually notice that quickly and fix their stuff. Yes, voilà, same.
> > (Our upstream providers do the same thing for us, so it's used on a larger > scale - unfortunately, not all large transit providers do that, some just > take the money and look the other way) Right, shared view. Cheers, mh
> Gert Doering > -- NetMaster -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlRvBMkACgkQZNZ/rrgsqafVWACgkueQOPf6h5cEdjWJy6zzBRM1 +n0An0CaPJAlnWyuD6t1Hzr7Yrp7RhrW =N+tK -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le 21/11/2014 10:08, Gert Doering a écrit :
Hi,
On Wed, Nov 19, 2014 at 06:31:56PM -0800, Ronald F. Guilmette wrote:
Of the remaining 235,061 route base IP addresses, fully 28,988 of those (12.3%) are being announced by some AS other than the one specified in the ripe.db.route file.
To state something that might be obvious or not - for the same prefix, you can have multiple route: entries with different origin ASes, which makes sense when a network moves (add new route: object, start new announcement, eventually remove old route: object). So, some of these might be perfectly fine, some might be forgotten (= a route: object with the proper origin AS exists as well), and some might just be legacy garbage - indeed.
Given the considerable number of routing anomalies revealed by my simple experiment, I am inclined to wonder who is actually using all of that route information in the RIPE DB, and what on earth they could be using it for.
We use it to build BGP filters for BGP customers.
For those, the filter is build using the origin AS as key, so if there are additional route objects for the same prefix but with a different origin AS, our script won't see them, so it's "garbage that does not disturb anything".
Of course, if the origin AS doesn't match at all, customers' BGP announcements won't go out - and they usually notice that quickly and fix their stuff.
(Our upstream providers do the same thing for us, so it's used on a larger scale - unfortunately, not all large transit providers do that, some just take the money and look the other way)
Nice thing to do is to (script) analyze received versus expected, and send report to the customer. mh
Gert Doering -- NetMaster
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlRvBdMACgkQZNZ/rrgsqac7ZwCeL8MaYF3Ey8IGUSUtlUL9Fg4p bMIAnAuoS6Ks0Ut8kG/iiEhGr7jwOKsZ =ySs8 -----END PGP SIGNATURE-----
In message <20141121090850.GP28745@Space.Net>, Gert Doering <gert@space.net> wrote:
To state something that might be obvious or not - for the same prefix, you can have multiple route: entries with different origin ASes...
Yes. Thank you. So I have now been informed. I do confess, freely, that I had not considered or anticipated such a possibility at all when I performed my simple minded analysis, and also must admit that had the small script I write to perform this analysis properly taken into account the meaning of such cases, the number I reported would have been different, probably with a lower number of "anomalies" (although, I suspect, not too much lower). Regarding the _use_ of the RIPE data base odf route objects, you wrote:
We use it to build BGP filters for BGP customers. ... (Our upstream providers do the same thing for us, so it's used on a larger scale...
It is, at once, both comforting to know that some folks, at least, are indeed making use of this data (RIPE IRR) to try to prevent bogus route announcements from leaking out, but also a bit worrying that the data seems to contain so many anomalies. Regards, rfg
On 11/21/14, 10:07 PM, Ronald F. Guilmette wrote:
In message <20141121090850.GP28745@Space.Net>, Gert Doering <gert@space.net> wrote:
To state something that might be obvious or not - for the same prefix, you can have multiple route: entries with different origin ASes... Yes. Thank you. So I have now been informed.
I do confess, freely, that I had not considered or anticipated such a possibility at all when I performed my simple minded analysis, and also must admit that had the small script I write to perform this analysis properly taken into account the meaning of such cases, the number I reported would have been different, probably with a lower number of "anomalies" (although, I suspect, not too much lower).
another thing I noted is that the list of anomalies includes entries like 193.110.139.0/24 as24637 24637 In these cases the origin field in the RIPE IRR has "AS" in lower case. Although not large enough in number to change the order of magnitude of the anomalies, it does translate to 1750 additional route objects with a correct origin. -- Rene
In message <546FB1A6.1020609@ripe.net>, Rene Wilhelm <wilhelm@ripe.net> wrote:
another thing I noted is that the list of anomalies includes entries like
193.110.139.0/24 as24637 24637
In these cases the origin field in the RIPE IRR has "AS" in lower case.
Although not large enough in number to change the order of magnitude of the anomalies, it does translate to 1750 additional route objects with a correct origin.
Yes, another programatic faux pas on my part. Sorry.
participants (7)
-
David Freedman -
Gert Doering -
Hindley, Martin -
Michael Hallgren -
Rene Wilhelm -
Rob Evans -
Ronald F. Guilmette