nusenu / ripestat-wishlist Goto Github PK

example:
https://stat.ripe.net/widget/prefix-overview#w.resource=147.171.0.0%2F16

and

https://stat.ripe.net/widget/routing-history#w.resource=147.171.0.0%2F16
say the source is AS1942:

but prefix-routing-consistency disagrees. It says the only source is AS2200:

https://stat.ripe.net/widget/prefix-routing-consistency#w.resource=147.171.0.0%2F16

Rene Wilhelm wrote on the routing-wg (2018-09-27):
https://www.ripe.net/ripe/mail/archives/routing-wg/2018-September/003630.html

prefix-routing-consistency widget appears to indeed have problems;
at least in this case. It only shows a result for the route observed
by the lowest amount of peers.

suggestion for a new data call for the content of https://ftp.ripe.net/ripe/stats/membership/alloclist.txt

1. IP -> member lookup:

example:
input: 194.158.64.0 -> returns: ad.andorpac

2. member -> IP lookup:

input: ad.andorpac -> returns:
19960627 194.158.64.0/19 ALLOCATED PA
20050104 85.94.160.0/19 ALLOCATED PA
20050330 80.80.84.0/22 ALLOCATED PA
20050330 80.80.92.0/22 ALLOCATED PA
20060224 89.150.2.0/23 ALLOCATED PA
[...]

example:
https://stat.ripe.net/widget/as-routing-consistency#w.resource=AS62744

compare that with HE's overview where conflicting entries are explicitly flagged in red:
https://bgp.he.net/AS62744#_prefixes

would be great if RIPEstat would do the same instead of saying that there are no IRR records matching that origin AS with that prefix.

https://stat.ripe.net/docs/data_api#AsRoutingConsistency
https://stat.ripe.net/docs/data_api#PrefixRoutingConsistency

the biggest performance issue for me is latency.

As far as I have seen there is no bulk or batch mode for
the RIPEstat API.

If I need something for several hundred prefixes
I have to do several hundred requests instead of sending
them in batches of 10, 20 or 50.

This would be a nice feature for the future.

The routing history widget shows the routing state over time for prefixes:

would be nice to have the same for RPKI route validity state over time.

It would have 3 states and colors:

• green ("VALID")
• red ("INVALID")
• yellow for NotFound?

https://twitter.com/nusenu_/status/1001915426614534144

• include invalid reason
• max length
• expiry

https://twitter.com/nusenu_/status/1027579221911199744

an additional RPKI related use-case for the prefix-routing-consistency

What do you think about adding indicators for:

• prefix is covered by a ROA and valid (green) - (mouseover could show the root CA)
• prefix is not covered by a ROA (grey)
• prefix is covered by a ROA, but invalid (red) - (mousover could show the invalid reason and ROA info)
• an indicator for "is this prefix reachable?" in a ROV environment (yes = green, no = red)

that would to some extend be possibly covered with the rpki-validation data call already available
https://stat.ripe.net/docs/data_api#RPKI

I think this would be very helpful when contacting network operators about their broken ROAs
because most trust what they see on RIPEstat

Ideally that would also work on an AS level as has been suggested before [2] but either is fine.

[1] https://stat.ripe.net/widget/prefix-routing-consistency
[2] https://www.ripe.net/ripe/mail/archives/routing-wg/2018-May/003513.html

https://twitter.com/nusenu_/status/1009543205665345536

I'm observing this issue with prefix 36.55.0.0/16 but it might not
limited to this specific prefix.

When asked about 36.55.0.0/16 RIPEstat says there is no IRR entry matching it:

https://stat.ripe.net/data/prefix-routing-consistency/data.json?resource=36.55.0.0/16

    "data": {
        "routes": [
            {
                "origin": 10013, 
                "irr_sources": [], <<<<-------------------
                "in_whois": false, <<<<-------------------
                "asn_name": "FBDC - FreeBit Co.,Ltd.", 
                "prefix": "36.55.0.0/16", <<<<-------------------
                "in_bgp": true
            }, 
            {
                "origin": 10013, 
                "irr_sources": [
                    "NTTCOM"
                ], 
                "in_whois": true, 
                "asn_name": "FBDC - FreeBit Co.,Ltd.", 
                "prefix": "36.55.252.0/22", 
                "in_bgp": true
            }
        ], 
        "query_starttime": "2018-08-17T16:00:00", 
        "query_endtime": "2018-08-17T16:00:00", 
        "resource": "36.55.0.0/16" <<<<-------------------
    }

but if you ask it with a longer prefix it answers differently (correctly stating that 36.55.0.0/16
exists in NTTCOM's IRR):

https://stat.ripe.net/data/prefix-routing-consistency/data.json?resource=36.55.0.0/17

 "query_id": "20180817193337-ce6c4970-1938-4b19-ad84-886effd882b3", 
    "data": {
        "routes": [
            {
                "origin": 10013, 
                "irr_sources": [
                    "NTTCOM"    <<<<-------------------
                ], 
                "in_whois": true,  <<<<-------------------
                "asn_name": "FBDC - FreeBit Co.,Ltd.", 
                "prefix": "36.55.0.0/16", <<<<-------------------
                "in_bgp": true
            }
        ], 
        "query_starttime": "2018-08-17T16:00:00", 
        "query_endtime": "2018-08-17T16:00:00", 
        "resource": "36.55.0.0/17" <<<<-------------------
    }

Is this a bug or am I misunderstanding the way this API works?
(there are numerous other /16 where it appears to work as expected)