Stephen Strowes
15
Articles
316
Likes on articles
Stephen is a principal engineer in the Office of the CTO at Fastly, where he spends his time trying to figure out what the Internet is. He obtained his PhD in Internet routing scalability from the University of Glasgow in 2012.
Website: https://sdstrowes.co.uk/
BGP Even-More Specifics in 2017
• 8 min read
Since October 2014, we have been advertising two IPv4 /25s and two IPv4 /28s, to better understand how far they propagate across the network. In this article, we review how things have (or have not) changed over the years.
Talking Traffic at TMA 2017
• 7 min read
Last week, the Network Traffic, Measurement and Analysis Conference (TMA) took place in Maynooth, Ireland. A full week was scheduled, featuring a PhD school across Monday and Tuesday, the Mobile Network Measurements (MNM) workshop on Tuesday, and the main conference from Wednesday to Friday. We wer…
Reviewing the 2016 Leap Second
• 9 min read
Last month we covered the 2015 leap second ahead of the insertion of a leap second at the very end of 2016. As stated previously, leap seconds can trigger poorly-tested code paths; leap second handling always unearths bugs and issues. This one was no exception!
Preparing for the 2016 Leap Second
• 8 min read
On 31 December this year, we're scheduled for another leap second. There are many stories about what leap seconds can do to infrastructure and applications, and rituals are built up around them. Such rituals stem from reality: leap seconds trigger poorly-tested code paths and run contrary to assump…
Hey! The difference is that the .bz2 is a dump of measurement results, but /api/v2/measurements/traceroute/ gives you measurement metadata. The json returned from the API call you provided includes 'result' fields, each of which refers to the measurement IDs with the actual results. If you want, you can run through those pointers and pull down the measurement results manually to get at the result data we're putting into the .bz2 archives. Note also that the output of that API call is paginated; use option "page_size=500" (the maximum) to reduce the number of pages you have to loop over. Hope that helps!
“So, historic data older than one month will be lost (or made unuvailable publically) forever?”
Hi Alexander! Measurement data -- all of it -- is always available via the API. The archives discussed here are a convenience method, offering data from recent public measurements in bulk form. In the future, we may modify this service to hold data for longer or to provide samples of older data, in the same location. If so, we'll be sure to announce it.
“Hi, all. Is there a recommendation (RFC or something) that ISPs follow for allow or not allow and propagate longer than /24 prefixes?”
Hi Alan! I'm not personally aware of a document, only the common convention that has been accepted for many years. Many documents refer to the current practice, including https://www.ripe.net/publications/docs/ripe-399 (from 2006) and https://tools.ietf.org/html/rfc4116 (from 2005). A more recent look at how far /24s propagate on the v4 Internet was published here: https://labs.ripe.net/Members/stephen_strowes/bgp-even-more-specifics-in-2017 In practice, the convention exists to avoid bumping into routing table limits too soon; even natural growth rates using the current conventions can catch networks unawares; for example, https://arstechnica.com/information-technology/2014/08/internet-routers-hitting-512k-limit-some-become-unreliable/
“Do you mean 6rd seriously? We live in year 2017 and you are using a technique for lazy people.”
Hi Thomas; we tend to take the view that reachability via an ISP-provisioned and managed transition mechanism is better than no reachability. Anything that brings more IPv6 to the internet is good.
Of course, the IPv6 world offers much finer granularity. A /32 ought to give folks 2^16 globally routable prefixes, so a maximum y-resolution of 65,536 pixels. x-resolution only relies on how patient the artist is!
Showing 5 comment(s)