determine relationship between the operators based on import and export statements in aut-num object?
Hi, bit weird question, but is it possible to determine relationship(Internet transit, settlement-free peering, etc) between the operators based on import and export statements in aut-num object? Often aut-num objects in RIR database contain the remarks which describe such relationships. However, for example here I have following import and export attributes from an aut-num object of an ISP: import: from AS65133 action pref=100; accept ANY import: from AS65798 accept AS65798 import: from AS65084 accept AS65084 import: from AS65485 action pref=100; accept ANY import: from AS65751 accept AS65751 import: from AS65059 action pref=100; accept ANY import: from AS65128 accept AS65128 export: to AS65133 announce AS-SET export: to AS65798 announce ANY export: to AS65084 announce ANY export: to AS65485 announce AS-SET export: to AS65751 announce ANY export: to AS650835 announce AS-SET export: to AS65128 announce ANY Am I correct that it is safe to say that probably AS65133, AS65485 and AS65059 are the uplink providers and AS65798, AS65084, AS65751 and AS65128 are the customers of this ISP? Last but not least, maybe there is altogether a more reliable way to understand the relationship between the operators than aut-num objects(often not updated) in RIR database? thanks, Martin
On Tue, 25 Nov 2014 17:36:47 +0200, Martin T said:
bit weird question, but is it possible to determine relationship(Internet transit, settlement-free peering, etc) between the operators based on import and export statements in aut-num object?
You can determine who is "upstream" and "downstream" from that. You can't tell if it's paid transit or free peering, because technically they're the same on the wire. All that's different is the economic motivations that allow/cause the routing jocks from the two sites involved to connect a pipe and put it in production.
On Tue, 25 Nov 2014 17:36:47 +0200, Martin T <m4rtntns@gmail.com> said: > Last but not least, maybe there is altogether a more reliable > way to understand the relationship between the operators than > aut-num objects(often not updated) in RIR database? The first thing to do is look and see if the policy of, e.g. AS65133 is consistent with what you see there. I suspect you'll find a lot of mismatches but I don't know if that has been studied systematically, but it should be simple to do. Next, much more data intensive, is trawl through the route views data and see to what extent the actual updates seen are consistent with the RIR objects, and also see what (topological, not financial as Valdis points out) relationships they imply that are not present in the RIR database. -w
Hi, thanks! I guess one of the most exhaustive and freely-available route-views data to analyze is from RIPE Routing Information Service project? For example if I would like to analyze a certain prefix announced by a certain AS for time period from 1.11.2014 to 30.11.2014, then I should download route-views data for this period(for rrc_id in {00..14}; do for d in {01..30}; do wget http://data.ris.ripe.net/rrc"$rrc_id"/2014.11/bview.201411"$d".0800.gz; done; done) and anayze this with bgpdump(bgpdump -m bview* | grep -w 65133)? Other option would be to use one of the tools like RIPEstat BGPlay? thanks, Martin On 11/25/14, William Waites <ww@styx.org> wrote:
On Tue, 25 Nov 2014 17:36:47 +0200, Martin T <m4rtntns@gmail.com> said:
> Last but not least, maybe there is altogether a more reliable > way to understand the relationship between the operators than > aut-num objects(often not updated) in RIR database?
The first thing to do is look and see if the policy of, e.g. AS65133 is consistent with what you see there. I suspect you'll find a lot of mismatches but I don't know if that has been studied systematically, but it should be simple to do.
Next, much more data intensive, is trawl through the route views data and see to what extent the actual updates seen are consistent with the RIR objects, and also see what (topological, not financial as Valdis points out) relationships they imply that are not present in the RIR database.
-w
participants (3)
-
Martin T -
Valdis.Kletnieks＠vt.edu -
William Waites