International routing detours are paths that originate in one country, visit another country and return to the original country. Such circuitous routes could occur due to intentional traffic engineering, lack of local peering, BGP misconfigurations, or even attacks. Detecting such events helps network engineers to diagnose problems.
It has become either a tradition or a habit for me that, each January, I report on the experience with the inter-domain routing system over the past year; looking in some detail at metrics from the routing system that can show the essential shape and behaviour of the underlying interconnection fabric of the Internet.
Please read this guest post by Marcus Keane from Microsoft in which he describes why the organisation is moving to IPv6-only and away from dual-stack.
The RIPE NCC's fifth hackathon event will happen in Amsterdam, in April 2017. We would like to invite operators, designers, researchers and developers to take on the challenge and join us in developing new tools and visualisations for DNS measurements.
It is now easier to embed a RIPEstat widget into your RIPE Labs articles. You can use RIPEstat widgets to show visualisations about IP address space, Autonomous System Numbers (ASNs), and related information for hostnames and countries.
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!
The RIPE NCC is operating K-root, one of the 13 DNS root servers. In this article we shed some light on the operational policies of K-root to clarify possible misunderstandings about how it is operated.
This article describes the BGP Large Communities Playground, and encourages people to utilise automated regression testing and compliance checking when developing new protocol features.
In this article, we give one example of the possible communities that are now easier to build around RIPE Atlas probes. With the tagging of similar probes, existing communities can use additional tools for creating and analysing RIPE Atlas measurements, such as "IXP Country Jedi", to create their own interpretation of the available data. We are hoping this is going to be an inspiration to the reader, and an invitation to play with the results and improve on the code.
On 28 December 2016, about 90 days before its 25th anniversary, the RIPE NCC reached the milestone of serving 15,000 active Local Internet Registries (LIRs). In this article we look at trends observed in the membership in the last few years. We also assess the remaining lifetime of the last bit of IPv4 in our available pool.
Over the past five years, all Regional Internet Registries (RIRs), with the exception of AFRNIC, have exhausted their pool of available IPv4 addresses. The Internet community anticipated this almost two decades ago and standardised IPv6 as a long-term solution. IPv6 uptake is, however, still lagging. Hence, affected businesses have actively started seeking stop-gap measures to prolong the lifetime of IPv4 addresses.
Four years have passed since the RIPE NCC announced its plans to put RIPE Atlas anchors into production. Since the first anchors went online in 2013, we’ve been working hard to both maintain and expand the network. As a result, we currently have 238 anchors deployed across 66 countries!
Please read this guest post by Samir Jafferali from LinkedIn in which he explains which steps he followed when setting up an anycast network: from acquiring address space to setting up routing and announcing the prefix from multiple PoPs.
As a friend once told me, “there's a fine line between pleasure and pain.”* There's a vast body of literature to corroborate that story, not including the 100+ million copies of the book referred to in the title of this piece. But what does that have to do with Network Address Translation (NAT)? Could the reason we all love our NATs be that they're the network engineer’s guilty pleasure? How long before we permanently cross the threshold and are confronted with the painful reality of NAT's dark downsides?
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 assumptions that system time always runs in one direction. It's useful to be aware of how your infrastructure handles leap seconds and how NTP servers handle them, so you can plan around the event. Here, we look at some of the NTP measurements the RIPE Atlas platform took around the last leap second, and approaches for handling them.
I am taking a second look at the DNS root servers, this time focusing on the ability to handle large UDP responses over IPv6.
The process of rolling the DNS Root’s Key Signing Key of the DNS has now started. During this process, there will be a period where the root zone servers’ response to a DNS query for the DNSKEY resource record of the root zone will grow from the current value of 864 octets to 1,425 octets. Does this present a problem?
Here is an example of how cross-pollination between two or more communities can create success. An overlap between IETF participants, RIPE Atlas users and listeners of a popular German podcast has led to growth in the deployment of RIPE Atlas probes (hardware devices that measure Internet infrastructure). We are still interested in expanding this platform in areas and networks that need more coverage.
As RIPE Atlas is expanding, it is approaching the magical milestone of 10,000 probes. However, as our public graphs also illustrate, the expansion has slowed down recently.
We had a look at various RIPE NCC data sets to see what we can learn from yet another country-wide Internet outage in 2016.