bswinnerton

Here's a simpler alternative with IP Guide that doesn't require a CLI:

  curl -sL ip.guide/AS19551 | jq .routes

I'd also suggest filing a correction with MaxMind, which is where most modern geolocation data is derived: https://www.maxmind.com/en/geoip-location-correction.

Great idea. This is rolling out right now.

It's not available from the API, but there is a "last updated" date when you view it in a browser. It's at most 8 hours old.

For the backend, it's written in Rust using a few key crates: axum for the api, bgpkit-parser for parsing the MRT data, and reqwest for fetching data at boot.

The site is hosted on Neptune Networks, another side project of mine for people to learn and experiment with BGP.

You'll have to follow the redirects since the site doesn't support HTTP, but just shipped pretty-printing.

No rate limits or auth for requests, but as mentioned below the api starts to load shed at 2k concurrent requests.

> Will this be open-sourced?

I don't think there's a strong reason to keep it closed-source.

> Were you already comfortable in Rust or is there a reason you selected Rust for this project?

This was a big learning opportunity for me to learn Rust. I had done two small projects in Rust before this one.

> How often are RIPE info and MaxMind data updated these days?

The MRT dumps where it gets its BGP data are updated every 8 hours, and MaxMind appears to be updated twice a week.

The country code is the last portion of the networks CSV:

  $ curl -sL ip.guide/bulk/networks.csv | head -n 2
  prefix,asn,organization,country
  1.0.0.0/24,13335,"Cloudflare, Inc.",US

IP Guide is also using MaxMind, I'm not familiar with many other data sources for that kind of data. Are you seeing discrepancies?

No rate limits or auth for requests, but as mentioned below the api starts to load shed at 2k concurrent requests.

Yeah, if you click on "bulk data" you'll see the two statically hosted CSVs for ASN and IP data. What else would you find useful in those datasets? It's quite easy to expand on them.

Oh cool! Is this a fork of ifconfig.co?

Yes! Quite easily, but it requires thinking through the right API design. I'll see if I can work this in this weekend.

Great feedback, I'll add a little more to the site to describe how it all works. Until then...

At a 30,000ft view, the site works by building an in-memory routing table at boot time that has an entry for every route on the internet and which ASN (autonomous system number) announces it. From there, it stitches together data on the organization that the ASN belongs to, and geolocation data, and then exposes it in the API/UI. Under the hood it's using a treebitmap[1] data structure, which means that it can do _very_ fast lookups when given a particular ip address or ip address range.

Zooming in a little more, the main data source is MRT dumps from the RIPE RIS project[2]. There are a number of routers that RIPE (one of the 5 regional internet registries that hand out ASNs and IPs) that rely on network operators to share their view of every route on the internet. These routers are probably some of the most well-connected routers in the world. For the purposes of this service, MRT dumps are effectively a point-in-time snapshot of the routing table of that router. IP Guide parses that file, rebuilds it in memory, and attaches other relevant data to each IP range (also known as a "prefix").

This allows the service to stay fast and stateless, which was one of the main things I was trying to optimize for when building it.

[1]: https://blog.apnic.net/2021/06/04/storing-and-retrieving-ip-... [2]: https://ris.ripe.net/docs/10_routecollectors.html

> Having a simple paragraph about RIPE, BGP and ARIN would be helpful (at least for me).

That's a great idea. I'll add a tooltip over some of the less obvious fields describing what they are.

> Is there any way at all to do this for IPv6?

Indeed! It's supported natively, so if you have an IPv6 address you should see it automatically. Here's an example <https://ip.guide/2600::>

> If the IP is associated with hostnames that would be nice to know.

I dig that idea, I'll have to think of the best way to pull that data while keeping the app stateless and fast.

I do that every. single. time.

Go for it! There's no formal rate limiting or auth, but it does start to load shed at 2k concurrent requests. It's stateless, so it's very easy to scale horizontally after that.

LoginLlama looks super helpful, what else would you like to see from IP Guide to help? Would a boolean attribute on whether or not the IP is a known tor exit node be helpful?

Repository contents aren’t “sent” to China, companies like Tencent specify the shape of tokens to GitHub and GitHub does the scanning and then notifies Tencent to revoke the token if one is found.

These are known as GitHub apps and were designed to address this problem. https://docs.github.com/en/developers/apps/getting-started-w...

It can be relatively inexpensive, depending on which RIR you’re using. There are providers like [Neptune Networks](https://neptunenetworks.org/) or [Vultr](https://www.vultr.com/) that you can peer with from a VPS so you don’t need to get “proper” IP transit in a datacenter.

Before every deploy your branch has master merged into it. There’s some clever work by Hubot while you’re in line to deploy to create a version of your branch that has the potential new master / main branch. If conflicts arise you fix them before it’s your turn to deploy.

This is known as “GitHub Flow” (https://guides.github.com/introduction/flow/). I was pretty surprised by it when I first joined GitHub but I’ve grown to love it. It makes rolling back changes much faster than having to open up a revert branch, get it approved, and deploy it. When something goes sideways, just deploy master / main, which is meant to always be in a safe state.

Not on that page, no, but you could easily fetch this information via the GraphQL API.

Oh sorry, I should have clarified it’s GraphQL “under the hood” (backend). Most of GitHub is a Rails app, and in the case of the commits page, the controller makes a GraphQL query, and then takes the results and injects it into the view, all server side. The original idea was that if GitHub was using its own GraphQL API to build its pages, our users would have the exact same access as GitHub engineers.

The move from page-based pagination to cursor based pagination on the commits page was so that the underlying queries could be moved to GraphQL, which use cursors (specifically the GraphQL Relay specification). That was one of the first pages that was moved over, and these days I think it would be relatively trivial to add a “last” page, since the Relay connection has the concept of totalCount and we have a few tricks around first/last cursors. Theoretically the ordering could also be flipped to view the first commit on the first page.

Generally speaking you request them from a regional internet registry (RIR). In North America, the RIR is ARIN https://www.arin.net/resources/guide/request. Bear in mind it’s harder and harder to get V4 addresses from an RIR these days, but it’s still possible. Once they are allocated to you, you have to find a place to announce them. Some “cloud” based solutions are Neptune Networks (https://neptunenetworks.org/) or Vultr (https://www.vultr.com/).

iperf3 to a VM is probably your best bet.

Oh, nice!

Could you also use the repository dispatch custom event? https://help.github.com/en/actions/reference/events-that-tri...