iljitsch.com

topics: network · BGP / IPv6 / more · settings · b&w · my business: inet⁶ consult · Twitter · Mastodon · LinkedIn · email · 🇺🇸 🇳🇱

Hi, I'm Iljitsch van Beijnum. These are general neworking-related posts.

112-storing: hoe voorkomen we zulke problemen op het internet?

Afgelopen maandagmiddag was er een grote storing in het telefonienetwerk van KPN, waarbij ondermeer het alarmnummer 112 zo'n drie uur niet bereikbaar was. Hoe kan het dat een telefoontje op een vaste lijn van KPN naar een meldkamer in de veiligheidsregio Groningen last heeft van dezelfde storing als een telefoontje van een Vodafone-gebruiker naar een meldkamer in de veiligheidsregio Limburg-Zuid? Dinsdag kwam het antwoord: een softwarefout. Het mocht niet baten dat het betreffende systeem viervoudig uitgevoerd was.

Intelligent network

In de telefonie is al vele jaren geleden het zogenaamde intelligent network ingevoerd. Voor die tijd waren vaste nummers gekoppeld aan wijkcentrales en mobiele nummers aan de mobiele operator. Als je dus van de ene kant van de stad naar de andere verhuisde, of van de ene mobiele operator naar de andere, dan kreeg je een nieuw nummer. Met IN was dat niet meer nodig: de telefooncentrale vraag aan een centrale database waar telefoontjes naartoe gerouteerd moeten worden. Probleem is wel dat het telefoonnetwerk nu afhankelijk is van een klein aantal centrale systemen. (En Voice over IP (VoIP) heeft dat versterkt.) Voorheen kon je nog binnen je eigen stadsdeel bellen zolang de wijkcentrale het deed, ook al lag de rest van het telefoonnetwerk plat.

Internetrouters worden afhankelijk van centrale systemen

We zien nu dezelfde ontwikkeling op ons af komen in de internetwereld. (...)

Volledig artikel / permalink - geplaatst 2019-06-25

Be gone, AS_SETs!

As I was writing my RPKI path validation draft last week, I considered the issue of filtering BGP AS paths with AS_SETs in them.

Turns out that I'm not the only one who feels AS_SETs are unnecessary: there's an RFC saying the exact same thing: RFC 6472.

Full article / permalink - posted 2019-06-24

Path validation with RPKI draft

Last week, I suggested it's time fix those BGP route leaks. I live by the words everybody complains about the weather, but nobody does anything about it, so as such I wrote an Internet-Draft with the protocol changes necessary:

draft-van-beijnum-sidrops-pathrpki-00

I think we can stop these route leaks with a relatively modest change to RPKI: by combining the ASes the origin trusts and the ASes the operator of an RPKI relying party server trusts, we have a list of all the ASes that may legitimately appear in the AS path as seen from this particular vantage point.

Full article / permalink - posted 2019-06-20

Let's fix those BGP route leaks

Last week, there was a large route leak that involved Swiss hosting company Safe Host and China Telecom. The route leak made internet traffic for European telecoms operators KPN, Swisscom and Bouygues Telecom, among others, flow through Safe Host and China Telecom against the wishes of the telecom operators involved. See this Ars Technica story for more details.

In this post, I'm going to explain how the interaction between the technical and business aspects of internet routing have made this issue so difficult to fix. At the end I'll briefly describe a proposal that I think can actually make that happen.

Read the article - posted 2019-06-13

→ Happy Birthday BGP

Geoff Huston has written a post on the APNIC blog congratulating BGP with its 30th birthday. BGP version 1 was published as RFC 1105 in June of 1989. Five years later, the BGP version 4 was published as RFC 1654. And we're still using BGP-4 today, 25 years later! Lots of things, including IPv6 support, were added later in backward compatible ways.

As usual, Geoff's story is comprehensive with lots of interesting details. For instance:

From time to time we see proposals to use geo-based addressing schemes and gain aggregation efficiencies through routing these geo-summaries rather than fine-grained prefixes.

Sorry about that. 😀 I still think it could work, though.

Well worth a read.

Permalink - posted 2019-06-10

How elastic is your network traffic?

How much bandwidth do I need? Always a hard question. It gets harder as you use more network links, and have to start considering what happens when one or more links fail, leaving you with reduced bandwidth.

The simple way to determine how much total bandwidth you need is to make a guess, and then adjust until the peaks in your bandwidth graphs stay below the 100% line. The more complex answer is that it depends on the bandwidth elasticity of the applications that generate your network traffic.

Applications are bandwidth elastic (sometimes known as "TCP friendly") when they adapt how much data they send to available bandwidth. They're inelastic when they keep sending the same amount of data even though the network can't handle that amount of data. Let's look at a few examples in more detail.

I'm assuming the bandwidth need throughout the day shown in this graph:

Between 21:00 and 22:00, normal bandwidth use reaches a peak of just over 80% of available capacity. But now we lose 25% of our bandwidth, so we have a higher bandwidth need than we can accommodate between 18:00 - 19:00 and 20:00 - 22:00, shown in red below:

Let's look at the behavior of applications with different bandwidth elasticity.

Full article / permalink - posted 2019-03-18

older posts - newer posts

Search for:
RSS feed

Archives: 2001, 2002, 2003, 2004, 2005, 2007, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2018, 2019, 2020, 2021, 2022, 2023, 2024