[Enhancement] Caching IP information based on subnets

[racheesingh]

As of now, IPInfoCache.py keeps track of ASN information per IP (self.ips['asn']). Due to this, when I use MeasurementEnhance.py:aslinksplus to get IP->ASN conversion for a large number of traceroutes, I see many requests going out to IPs within the same /24. Is is advisable to cache AS info for the subnets that get announced by them? For instance, querying stat.ripe.net for 49.255.240.218 fetches this response:

{
    "status": "ok", 
    "server_id": "stat-app1", 
    "status_code": 200, 
    "version": "1.3", 
    "cached": false, 
    "see_also": [], 
    "time": "2015-12-21T22:46:08.559023", 
    "messages": [
        [
            "info", 
            "1 routes were filtered due to low visibility (min peers:3)."
        ], 
        [
            "warning", 
            "Given resource is not announced but result has been aligned to first-level less-specific (49.255.0.0/16)."
        ]
    ], 
    "data_call_status": "supported - connecting to ursa", 
    "process_time": 10948, 
    "query_id": "99c2afee-a834-11e5-9234-782bcb34677e", 
    "data": {
        "query_time": "2015-12-21T16:00:00", 
        "is_less_specific": true, 
        "resource": "49.255.0.0/16", 
        "actual_num_related": 0, 
        "num_filtered_out": 1, 
        "asns": [
            {
                "holder": "VOCUS-BACKBONE-AS Vocus Connect International Backbone,AU", 
                "asn": 4826
            }
        ], 
        "block": {
            "resource": "49.0.0.0/8", 
            "name": "IANA IPv4 Address Space Registry", 
            "desc": "APNIC (Status: ALLOCATED)"
        }, 
        "related_prefixes": [], 
        "type": "prefix", 
        "announced": true
    }
}

We could cache { "49.255.0.0/16": 4826 } and it would take care of queries for many IPs in that subnet. Does this sound conceptually correct?

[emileaben]

On Tue, Dec 22, 2015 at 12:15 AM, Rachee Singh notifications@github.com
wrote:

As of now, IPInfoCache.py keeps track of ASN information per IP
(self.ips['asn']). Due to this, when I use
MeasurementEnhance.py:aslinksplus to get IP->ASN conversion for a large
number of traceroutes, I see many requests going out to IPs within the same
/24. Is is advisable to cache AS info for the subnets that get announced by
them? For instance, querying stat.ripe.net for 49.255.240.218 fetches
this response:

{
"status": "ok",
"server_id": "stat-app1",
"status_code": 200,
"version": "1.3",
"cached": false,
"see_also": [],
"time": "2015-12-21T22:46:08.559023",
"messages": [
[
"info",
"1 routes were filtered due to low visibility (min peers:3)."
],
[
"warning",
"Given resource is not announced but result has been aligned to first-level less-specific (49.255.0.0/16)."
]
],
"data_call_status": "supported - connecting to ursa",
"process_time": 10948,
"query_id": "99c2afee-a834-11e5-9234-782bcb34677e",
"data": {
"query_time": "2015-12-21T16:00:00",
"is_less_specific": true,
"resource": "49.255.0.0/16",
"actual_num_related": 0,
"num_filtered_out": 1,
"asns": [
{
"holder": "VOCUS-BACKBONE-AS Vocus Connect International Backbone,AU",
"asn": 4826
}
],
"block": {
"resource": "49.0.0.0/8",
"name": "IANA IPv4 Address Space Registry",
"desc": "APNIC (Status: ALLOCATED)"
},
"related_prefixes": [],
"type": "prefix",
"announced": true
}
}

We could cache { "49.255.0.0/16": 4826 } and it would take care of
queries for many IPs in that subnet. Does this sound conceptually correct?

i've had similar thoughts before, but i've put of actually doing things
like this because of situations like this:

BGP:
1.1.0.0/16 AS123
1.1.100.0/24 AS321

traceroute with 2 results
1.1.1.1
1.1.100.1

if i look up 1.1.1.1 before 1.1.100.1 i'd first get a cached result of
1.1.0.0/16, which would cover 1.1.100.1 , so i'd either always need to do
the 2nd lookup anyways, or also cache all more specifics of 1.1.0.0/16.

at that point i thought it may not be worth it.

emile

—
Reply to this email directly or view it on GitHub
#10.